Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Best practices for open source in government

Ben Balter
February 19, 2015

Best practices for open source in government

Ben Balter

February 19, 2015
Tweet

More Decks by Ben Balter

Other Decks in Technology

Transcript

  1. !
    10 Secrets of Successful 

    Open Source Projects
    Ben Balter
    @benbalter
    [email protected]
    government.github.com

    View full-size slide

  2. !
    If you only remember two things

    View full-size slide

  3. !
    1. Open source ≠ Published source

    View full-size slide

  4. !
    Open Source (software)

    software that can be freely used, modified, and shared (in both
    modified and unmodified form) by anyone

    View full-size slide

  5. !
    Open Source

    a philosophy of collaboration in which
    working materials are made available online
    for anyone to fork, modify, discuss, and contribute to.

    View full-size slide

  6. " Version Control
    * 2d96cfe - (HEAD, tag: v3.1.1, origin/master, origin/HEAD, master) :gem: bump (43 minutes ago)
    * f4b446b - remove stray backtick (44 minutes ago)
    * 83599e3 - Merge branch 'master' of https://github.com/benbalter/g-man (46 minutes ago)
    |\
    | * 42514ea - Merge pull request #61 from devscott/laxco (50 minutes ago)
    | |\
    | | * 072d9b5 - Adding in additional entry for La Crosse County, WI (54 minutes ago)
    | |/
    * | 1e95d95 - remove unresolvable domains (46 minutes ago)
    * | 1a8645a - remove uwyo.edu/CES (86 minutes ago)
    |/
    * 70410ba - Merge pull request #60 from jpmckinney/canada (2 hours ago)
    |\
    | * a77ad43 - Use consistent comments for Canada hosts (2 hours ago)
    | * 1776e45 - Add more Canadian hosts (2 hours ago)
    * | 05211a0 - Merge pull request #58 from mitio/bulgarian-government-domains (3 hours ago)
    |\ \
    | * | fe8f862 - Add Bulgaria's government main domain (3 hours ago)
    | |/
    * | 85d0c7b - Merge pull request #59 from mitio/fix-readme-typos (3 hours ago)
    |\ \
    | |/
    |/|
    | * f558a90 - Add missing word in the readme (3 hours ago)

    View full-size slide

  7. !
    2. Optimize for developers

    View full-size slide

  8. !
    You can have open source without
    executive oversight

    View full-size slide

  9. !
    You can have open source without
    policy guidance

    View full-size slide

  10. !
    You can’t have open source
    without developers

    View full-size slide

  11. !
    You can’t have open source
    without code

    View full-size slide

  12. !
    1. Internal collaboration
    2. External engagement
    # Roadmap

    View full-size slide

  13. !
    Internal collaboration

    View full-size slide

  14. !
    Best Practice #1:
    The technology is the easy part

    View full-size slide

  15. !
    Open source as a vehicle for
    organizational change

    View full-size slide

  16. !
    You can’t be a closed source culture
    behind the firewall, and expect to
    foster an open source culture in public

    View full-size slide

  17. !
    Best Practice #2:
    Start small, go through the motions

    View full-size slide

  18. !
    You wouldn’t run a marathon
    without training

    View full-size slide

  19. !
    Organizations have muscle memory

    View full-size slide

  20. !
    Open source is scary
    (they will say “no” at first)

    View full-size slide

  21. 1. Start by experimenting with “open source” in private

    (Best lunch places near your office, the office’s favorite chocolate chip cookie recipe)
    2. Get everyone involved 

    (legal, procurement, ethics, etc.)
    3. Ship 0.1, not 1.0 

    (and manage expectation)

    View full-size slide

  22. !
    Best Practice #3:
    Minimize information imbalance

    View full-size slide

  23. !
    Open source is about 

    growing a community

    View full-size slide

  24. !
    Developers are people too

    View full-size slide

  25. !
    Work outside the firewall

    View full-size slide

  26. ‣ Procedurally

    (One issue tracker, one way to provide feedback or discuss features; minimize and memorialize
    meatspace discussions)
    ‣ Day-to-day

    (The project’s status, how to submit an issue/feature request or contribute a fix/enhancement)
    ‣ Long-term

    (Project mission statement, philosophy, and goal, features and requirements list, project roadmap)

    View full-size slide

  27. !
    Best Practice #4:
    Embrace the constraints of open source

    View full-size slide

  28. !
    $ Electronic
    High fidelity mediums expose process

    View full-size slide

  29. !
    % Transparent
    Communicate decisions in realtime, and forever

    View full-size slide

  30. !
    & Asynchronous
    Focus workflow on code, not meetings

    View full-size slide

  31. !
    ' Informal
    Adopt cultures, not polices

    View full-size slide

  32. !
    Best Practice #5:
    Open source problems, not solutions

    View full-size slide

  33. !
    Developers want to 

    contribute to a cause 

    not provide free labor

    View full-size slide

  34. !
    “Yes we can”, not “yes we did”

    View full-size slide

  35. !
    If you’re happy with your ship,
    you’ve shipped too late

    View full-size slide

  36. !
    External engagement

    View full-size slide

  37. !
    Best Practice #1:
    Expand your definition of stakeholders

    View full-size slide

  38. ‣ Non-technical, non-user
    stakeholders
    ‣ Potential users
    ‣ Veteran (or curious) users
    ‣ Subject matter experts
    (accessibility, content, i18n)
    ‣ Technical users
    ‣ Active developers
    ‣ Potential developers
    ‣ Press, thought leaders, etc.
    Potential contributors

    View full-size slide

  39. ‣ Kick the tires, does it
    work?
    ‣ Answer the question:
    “what features would
    you love to see?”
    ‣ Flesh out
    documentation, note
    where documentation
    is lacking
    ‣ Community
    evangelism, speak,
    teach, and spread your
    love for the project
    ‣ Submit new questions
    to the project’s Q&A
    forums, or take a stab
    at an answer
    ‣ Host a genius bar at
    the next local meetup
    ‣ Translate the project
    into a different
    language
    ‣ Give feedback on
    proposed bug fixes
    and features, propose
    new ones
    ‣ Recruit new
    developers
    Opportunities to contribute

    View full-size slide

  40. !
    Best Practice #2:
    Be the hub, encourage spokes

    View full-size slide

  41. !
    You are the host of the internet’s
    most boring cocktail party

    View full-size slide

  42. !
    Non-blocking is 

    better than blocking

    View full-size slide

  43. !
    Be a matchmaker
    (connect subject matter experts and technical experts in the open)

    View full-size slide

  44. 1.Minimize one-to-one interactions 

    (emailing [email protected])
    2.Every answer to every question should have a URL

    (and a human name and face)
    3.Answer questions once 

    (or never if the community can)

    View full-size slide

  45. !
    Best Practice #3:
    Minimize Friction

    View full-size slide

  46. !
    Friction (n)
    The time it takes to go from 

    “I want to contribute” to “I have contributed”

    View full-size slide

  47. ‣ What does this thing do?
    ‣ What language is this thing written in?
    ‣ Do I need a lawyer to know if I can use it?
    ‣ How do I bootstrap my local development environment
    ‣ How do I submit an improvement? How long will it take to merge?

    View full-size slide

  48. !
    Best Practice #4:
    Decentralize governance

    View full-size slide

  49. !
    You don’t need a meeting 

    to merge a pull request

    View full-size slide

  50. !
    You don’t need a suit 

    to merge a pull request

    View full-size slide

  51. !
    You need to be a member of the
    community to participate in it

    View full-size slide

  52. ‣ Responding to issues and providing support
    ‣ Code review and enforcing project style
    ‣ Accepting or rejecting pull request on behalf of the project
    ‣ Long-term planning, roadmaps, releases

    View full-size slide

  53. !
    Best Practice #5:
    Encourage contributors

    View full-size slide

  54. !
    The right to contribute is assumed 

    in the open source world

    View full-size slide

  55. !
    It’s not in government

    View full-size slide

  56. !
    Let developers know 

    you want contributions

    View full-size slide

  57. !
    Go out of your way to
    encourage them

    View full-size slide

  58. ‣ In advance

    (Document how to contribute, technical requirements, how to run the project locally in the README)
    ‣ Daily

    (Provide constructive and supportive feedback, express gratitude when merging or commenting)
    ‣ Going Forward

    (Automate testing with continuous integration, minimize friction through shared tooling)

    View full-size slide

  59. Secrets of successful open source projects
    1. The technology is the easy part
    2. Start small, go through the motions
    3. Minimize information imbalance
    4. Embrace the constraints of open
    source
    5. Open source problems, not solutions
    6. Expand your definition of
    stakeholders
    7. Be the hub, encourage spokes
    8. Minimize friction
    9. Decentralize governance
    10. Encourage contributors
    Internal collaboration External engagement

    View full-size slide

  60. !
    10 Secrets of Successful 

    Open Source Projects
    Ben Balter
    @benbalter
    [email protected]
    government.github.com

    View full-size slide