! 10 Secrets of Successful 
 Open Source Projects Ben Balter @benbalter government@github.com government.github.com

! If you only remember two things

! 1. Open source ≠ Published source

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

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

" 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)

! 2. Optimize for developers

! You can have open source without executive oversight

! You can have open source without policy guidance

! You can’t have open source without developers

! You can’t have open source without code

! 1. Internal collaboration 2. External engagement # Roadmap

! Internal collaboration

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

! Open source as a vehicle for organizational change

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

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

! You wouldn’t run a marathon without training

! Organizations have muscle memory

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

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)

! Best Practice #3: Minimize information imbalance

! Open source is about 
 growing a community

! Developers are people too

! Work outside the firewall

‣ 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)

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

! $ Electronic High fidelity mediums expose process

! % Transparent Communicate decisions in realtime, and forever

! & Asynchronous Focus workflow on code, not meetings

! ' Informal Adopt cultures, not polices

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

! Developers want to 
 contribute to a cause 
 not provide free labor

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

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

! External engagement

! Best Practice #1: Expand your definition of stakeholders

‣ 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

‣ 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

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

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

! Non-blocking is 
 better than blocking

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

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)

! Best Practice #3: Minimize Friction

! Friction (n) The time it takes to go from 
 “I want to contribute” to “I have contributed”

‣ 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?

! Best Practice #4: Decentralize governance

! You don’t need a meeting 
 to merge a pull request

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

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

‣ 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

! Best Practice #5: Encourage contributors

! The right to contribute is assumed 
 in the open source world

! It’s not in government

! Let developers know 
 you want contributions

! Go out of your way to encourage them

‣ 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)

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

! 10 Secrets of Successful 
 Open Source Projects Ben Balter @benbalter government@github.com government.github.com