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