In the last few years open source has transformed the software industry. From Android to Wikipedia, open source is everywhere, but how does one succeed in it? While open source projects come in all shapes and sizes and all forms of governance, no matter what kind of project you’re a part of, there are a set of fundamentals that lead to success. I’d like to share some of the lessons I’ve learned from running two of the largest commercial open source projects, Docker and MongoDB, as well as some very successful community projects.
This presentation was delievered at sinfo.org in Feb 2015.
2. @spf13
Chief Operator @ Docker
Former Chief Developer
Advocate @ MongoDB,
Author of Hugo, spf13-
vim, Cobra, Afero, Viper
& more
3. Mainframe Era :
60s & 70s
• Computer companies sold hardware
• Software was free
• Software was colloborative
• IBM dominates
4. The Software Era:
80s - 90s
• Software as a business emerged
• Software companies sold “bits”
• Software was private and proprietary
• Microsoft dominates
5. The Internet Era:
00s
• Internet changes everything
• Open source movement gains traction
(Linux, Apache, MySQL, PHP)
• Tech selling ads, bits, hardware & services
• Google Dominates
6. The Free Source Era:
10s
• Technology companies sell Hardware & Services
• Software is becoming free ($$) (Windows 10,
OS X, Android, IOS)
• Game companies still sell bits
• Virtually all software companies are now
participating in open source
26. Users will have questions
• Need to establish a place for them to
ask questions
• Public is ideal:
• Others can respond
• Others benefit from the response
27. Forums & mailing lists
• Google groups ok, but hard to search
• Stack Overflow will happen, but not focused
• Forums work best, Discourse is pretty good
• IRC also works well, but realtime and
without integrated search.
28. README
• Your single most important file
• First thing everyone sees
• Most projects don’t spend enough time
on a readme
• Where you convey your purpose & values
41. You need users
• No matter how good a project is, it
can’t succeed without users
• Unless you tell the world about your
project, people will not come
• Unnatural behavior for most engineers
42. To: Newsgroups: comp.os.inix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: <mailto: 1991Aug25.205708.9541@klaava.Helsinki.Fi
Hello everybody out there using minix — I’m doing a (free) operating system (just a hobby,
won’t be big and professional like gnu) for 386 (486) AT clones. This has been brewing since
april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as
my OS resembles it somewhat (same physical layout of the file-system (due to practical
reasons) among other things).
I’ve currently ported bash (1.08) and gcc (1.40), and things seem to work. This implies that I’ll
get something practical within a few months, and I’d like to know what features most people
would want. Any suggestions are welcome, but I won’t promise I’ll implement them :-).
Linus (mailto: torvalds@klaava.helsinki.fi)
PS. Yes — it’s free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses
386 task switching etc), and it probably never will support anything other than AT-harddisks,
as that’s all I have :-(.
43. Focus on the User
• Success depends on a good user
experience
• Contributions come from happy
users
44. User Experience
• Starts with installation
• What are the first 10 minutes like?
• What could turn a user away?
65. Prepare
• Learn the tools of the trade
• Git & Github
• Read the Documentation
• Familiarize yourself with IRC, forums,
& the correct channels
66. Take Iniative
• Don’t be afraid to try
• Open source loves self starters
• Open source authors are usually very
approachable and open to ideas
• Communicate and collaborate as much as
possible
67. Ask
• What can I help with?
• I would like to help with X, but
would benefit from some guidance,
can someone guide me?
• If I contributed Y, would that help?
70. Most projects have very
few contributors
• You must give if you want to get
• Contributors are an investment in
the future of the project
• Contributors pay back many times
what you put in
71.
72. Make it Easy to
Contribute
• Use an “open” open source license
(Apache 2.0, MIT, BSD)
• Provide contribution guidelines
• Provide contribution instructions &
tutorials
73. Treat Contributors Well
• Happier developers will contribute
more
• The more welcome people feel the
more they will help your project
74. Be Responsive
• Respond to Pull Requests in a
timely manner
• Provide and contribute to a channel
where people can ask questions
• Respond to issues quickly
77. Empower Contributors
• When someone shows initative and
history of good contributions make them
a committer
• Resist tempation to control
• If you aren’t able to be responsive,
appoint more committers
78. Teach
• Don’t ever say no.
• Teach contributors how it can
become a yes
• Newly empowered contributors
contagiously help others