The Zen of Python has been my inspiration in programming from the early days. I have even found some of its principles priceless in daily life. After nearly a decade of involvement with the Open Source world, this is my humble attempt at jotting down the “Do’s and Don’ts” of the Open Source world in the style of The Zen of Python. Consider this to be a tribute to PEP-0020.
This post consolidates the thoughts of Pieter Hintjens, Bruno Rocha and Christine Hall on Open Source, and adds some of my experience to it.
The Zen of Open Source
- Open is better than closed.
- Explicit license is better than implicit intention.
- Public domain is better than copyleft.
- Copyleft is better than copyright.
- Small team is better than working alone.
- Community is better than a small team.
- Documentation counts.
- Special projects aren’t special enough to file patents.
- Although practicality beats ideologies,
- Patches should never be ignored silently,
- Unless they break tests.
- In the face of ambiguity, refuse the temptation to close an issue.
- There should be one — and preferably only one — style guide.
- Although that way may not be obvious at first unless you’re a bot.
- Incomplete project is better than none;
- Although never is often better than yet-another library that reinvents the wheel.
- If a code is unreadable or archaic, it’s a bad idea.
- If a code is eccentric but has documentation, it may be a good idea.
- Tests are one honking great idea — let’s do more of those!