Best practices for open source in government

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