$30 off During Our Annual Pro Sale. View Details »

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. ! Open Source (software)
 software that can be freely used,

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

    materials are made available online for anyone to fork, modify, discuss, and contribute to.
  3. " 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>
  4. ! You can’t be a closed source culture behind the

    firewall, and expect to foster an open source culture in public
  5. 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)
  6. ‣ 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)
  7. ‣ 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
  8. ‣ 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
  9. 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)
  10. ! Friction (n) The time it takes to go from

    
 “I want to contribute” to “I have contributed”
  11. ‣ 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?
  12. ‣ 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
  13. ‣ 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)
  14. 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