Rules of Open Source Programming
From Hackers-IL
This is a list not unlike the Ferengi Rules of Acquisition. Meaning: not all rules are yet known, and they skip some numbers. Before adding them to this main copy add them to Rules of OSP Suggestions.
The meta-rules (do not change!)
- Rules must be either funny, whimsical or true.
- You are not expected to understand these rules.
- The rules as a whole may be self-contradictory.
- Rules may have exceptions.
- Rules may be false.
The Rules of Open Source Programming:
1. Don't whine unless you are going to implement it yourself.
4. If you don't work on your project, chances are that no one will.
5. A project is never finished.
6. The user is always right unless proven otherwise by the developer.
7. Release early, release often. Clean compilation is optional.
8. Open-Source is not a panacea.
9. Give me refactoring or give me death!
11. When a developer says he will work on something, he or she means "maybe".
13. Your first release can always be improved upon.
15. If you like it, let the author know. If you hate it, let the author know why.
20. Open Code != Good Code
22. Backward compatiblity is your worst enemy.
23. Backward compatiblity is your users' best friend.
33. Don't waste time on writing test cases and test scripts - your users are your best testers.
34. Every successful project will eventually spawn a sub-project
37. Duplicate effort is inevitable. Live with it.
48. The number of items on a project's to-do list always grows or remains constant.
Notes and Links
See some discussion of it in Advogato, with more suggestions.
There are more pearls of wisdom like this in ESR's The Cathedral and the Bazaar, and in many other sources.
