Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

! If you only remember two things

Slide 3

Slide 3 text

! 1. Open source ≠ Published source

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

! 2. Optimize for developers

Slide 8

Slide 8 text

! You can have open source without executive oversight

Slide 9

Slide 9 text

! You can have open source without policy guidance

Slide 10

Slide 10 text

! You can’t have open source without developers

Slide 11

Slide 11 text

! You can’t have open source without code

Slide 12

Slide 12 text

! 1. Internal collaboration 2. External engagement # Roadmap

Slide 13

Slide 13 text

! Internal collaboration

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

! Open source as a vehicle for organizational change

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

! You wouldn’t run a marathon without training

Slide 19

Slide 19 text

! Organizations have muscle memory

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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)

Slide 22

Slide 22 text

! Best Practice #3: Minimize information imbalance

Slide 23

Slide 23 text

! Open source is about 
 growing a community

Slide 24

Slide 24 text

! Developers are people too

Slide 25

Slide 25 text

! Work outside the firewall

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

! $ Electronic High fidelity mediums expose process

Slide 29

Slide 29 text

! % Transparent Communicate decisions in realtime, and forever

Slide 30

Slide 30 text

! & Asynchronous Focus workflow on code, not meetings

Slide 31

Slide 31 text

! ' Informal Adopt cultures, not polices

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

! External engagement

Slide 37

Slide 37 text

! Best Practice #1: Expand your definition of stakeholders

Slide 38

Slide 38 text

‣ 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

Slide 39

Slide 39 text

‣ 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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

! Non-blocking is 
 better than blocking

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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)

Slide 45

Slide 45 text

! Best Practice #3: Minimize Friction

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

! Best Practice #4: Decentralize governance

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

‣ 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

Slide 53

Slide 53 text

! Best Practice #5: Encourage contributors

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

! It’s not in government

Slide 56

Slide 56 text

! Let developers know 
 you want contributions

Slide 57

Slide 57 text

! Go out of your way to encourage them

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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