Best practices for open source in government

19d03ecc1ff5da1a5e63a3ddaa2d84c2?s=47 Ben Balter
February 19, 2015

Best practices for open source in government

19d03ecc1ff5da1a5e63a3ddaa2d84c2?s=128

Ben Balter

February 19, 2015
Tweet

Transcript

  1. ! 10 Secrets of Successful 
 Open Source Projects Ben

    Balter @benbalter government@github.com government.github.com
  2. ! If you only remember two things

  3. ! 1. Open source ≠ Published source

  4. ! Open Source (software)
 software that can be freely used,

    modified, and shared (in both modified and unmodified form) by anyone
  5. ! Open Source
 a philosophy of collaboration in which working

    materials are made available online for anyone to fork, modify, discuss, and contribute to.
  6. " Version Control * 2d96cfe - (HEAD, tag: v3.1.1, origin/master,

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

  8. ! You can have open source without executive oversight

  9. ! You can have open source without policy guidance

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

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

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

  13. ! Internal collaboration

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

  15. ! Open source as a vehicle for organizational change

  16. ! You can’t be a closed source culture behind the

    firewall, and expect to foster an open source culture in public
  17. ! Best Practice #2: Start small, go through the motions

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

  19. ! Organizations have muscle memory

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

    first)
  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)
  22. ! Best Practice #3: Minimize information imbalance

  23. ! Open source is about 
 growing a community

  24. ! Developers are people too

  25. ! Work outside the firewall

  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)
  27. ! Best Practice #4: Embrace the constraints of open source

  28. ! $ Electronic High fidelity mediums expose process

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

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

  31. ! ' Informal Adopt cultures, not polices

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

  33. ! Developers want to 
 contribute to a cause 


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

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

    late
  36. ! External engagement

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

  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
  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
  40. ! Best Practice #2: Be the hub, encourage spokes

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

    cocktail party
  42. ! Non-blocking is 
 better than blocking

  43. ! Be a matchmaker (connect subject matter experts and technical

    experts in the open)
  44. 1.Minimize one-to-one interactions 
 (emailing anonymous-inbox@agency.gov) 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)
  45. ! Best Practice #3: Minimize Friction

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

    
 “I want to contribute” to “I have contributed”
  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?
  48. ! Best Practice #4: Decentralize governance

  49. ! You don’t need a meeting 
 to merge a

    pull request
  50. ! You don’t need a suit 
 to merge a

    pull request
  51. ! You need to be a member of the community

    to participate in it
  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
  53. ! Best Practice #5: Encourage contributors

  54. ! The right to contribute is assumed 
 in the

    open source world
  55. ! It’s not in government

  56. ! Let developers know 
 you want contributions

  57. ! Go out of your way to encourage them

  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)
  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
  60. ! 10 Secrets of Successful 
 Open Source Projects Ben

    Balter @benbalter government@github.com government.github.com