I found this talk by Kenneth Reitz one of the most interesting at Pycon. There was a comprehensive breakdown of the different strategies people take to create and nurture (or not) open source projects, and tales from maintaining them. You’re probably better to just read Kenneth’s notes, but for what it is worth – here are mine!
Started with the story of the Facebook SDK which allowed developers to access Facebook APIs from Python. It was rarely updated, and one day just stopped working. So developers opened issues, and it ended up on hacker news – the issue got 50 comments. So… Facebook disabled the issue tracker.
This was the worst possible scenario. The project wasn’t open source, it was public source.
Public Source: Company puts out a chuck of code with an Open Source License on it, hoping that it will be useful. This is better than closed source, but can easily end up abandoned due to lack of interest or change of focus. The motivation for sharing is unclear.
GitTip is a platform for sustainable crowd-funding. It takes open-source to the extreme, striving to be the world’s first truly “open company”. It’s run by Chad Whitacre who said “I’m not building Gittip. I’m building a community that’s building Gittip.”
Extreme Open Source means:
- There’s a GitHub issue for everything.
- Major decisions are voted on GitHub.
- Interviews with journalists are live-streamed.
- All formal discussions are publicly documented and shared.
Shared investments: Shared ownership, and extreme transparency. New contributors can follow a documented process. It is low-risk, with a high bus-factor.
Requests is HTTP for humans – one of the most installed PyPI projects. It’s different because project decisions are made by Kenneth (the owner).
Dictatorship project: Totalitarian “Benevolent Dictator for Life” (BDFL) owns everything. They are responsible for all decisions. Feedback is encouraged, but users shouldn’t have any expectation of change. Their extreme opinions will guide the project, and they will be able to make quick, precise decisions.
Downsides: Low bus factor, risk of burnout is high. If the BDFL loses sight of goals, the project will be ruined.
Lessons from a Dictatorship Project
Be cordial or be on your way.
Contributors:
- Be as respectful as possible.
- Remember, they don’t owe you one moment of their time.
Maintainers:
- Be thankful.
- Contributors are the lifeblood of your project.
- Ignore non-constructive suggestions.
- Remember that some people take things too seriously.
- Be cordial.
- Contributors take what you say personally.
- Take the opportunity to educate the user.
- Remember, you could be their first interaction with an Open Source project.
- A little kindness goes a long way.
You could be their first interaction with an Open Source project – this is a really important point! Don’t scare people away from Open Source!
Burnout
Sustainability is the biggest challenge in Open Source. Everyone has limited time, and it is easy to become a bottleneck.
Wesley Beary: “Open source provides a unique opportunity for the trifecta of purpose, mastery and autonomy. By recognising the power of these factors, we can keep ourselves motivated and continue to increase our impact.” (Worth reading the entire article there).
Learn to do less. Lead-Contributors triage issues. This saves a lot of time. Focus time on larger issues, and help make the best of their time and efforts. Faster for contributors and users – only good things happen.
JUST SAY NO.
This is really difficult. Sometimes people send crazy features disguised as practical pull requests – they are trying to help. But it is a use case, not for library. If you say yes too often, the project will be ruined – tragedy of the commons.
Pieter Hintjens: “Simplicity is always better than functionality”
- You cannot support every use-case, look for the 90% use-case, not the 100% use-case.
- If a new pull request adds complexity – say no.
- Plugable, modular system – pass it in as an argument, and everyone wins.
- Simple code is good.
- Code solves problems created by humans.
- Less code = less to maintain.
- Negative diffs are the best diffs.
- Complex code is bad.
- Tight coupling.
- Technical debt.
- High maintenance.
- Self-serving, rather than project based.
Open Source makes the world a better place – please don’t make it complicated.
Audience Question: “Is forking ever a good thing?”
Answer: Sometimes – see Hudson/Jenkins – forking might be required for political reasons. But don’t fork instead of contributing, talk first.