The Rules of Open-Source Programming

I, along with some help from the Hackers-IL mailing list of which I am
a member, formulated a list of Open-Source rules', not unlike the
Ferengi Rules of
Acuiqisition. The Rules are still open and any additions are
welcome.

First of all the Meta-Rules:

1. Rules must be either funny, whimsical or true.
2. You are not expected to understand these rules.
3. The rules as a whole may be self-contradictory.
4. Rules may have exceptions.
5. Rules may be false.

And now the rules themselves:

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.

31. You are your best tester

32. Your users are your second best testers

33. Your test-cases and test-scripts are your worst 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.

Thanks should go to Mulix, Oleg Goldshmidt, Omer Zak, Nadav Har'El and
all the other great guys who contriubted to their (initial) formation.

The number of items on a project's to-do list always
grows or remains constant.

Not quite true. In my experience, the number of items on the to-do list
(or bug list) varies proportionally with the number of users. See:
Debian, Windows, Mozilla, StarOffice.

Also wander around bugs.debian.org for a while to see that a package's
popularity determines the number of bugs, much more than the code
quality. There are some near-totally broken packages with only one or
two bugs reported against them, but dpkg (which works fine for almost
100% of people) has uncountable hordes of bugs, most of them real.

These aren't related only to open source projects, but all projects.
For example, kuro5hin and MeatballWiki both took off
when their respective founders (Rusty and myself resp.) stopped
posting. The reason? As long as the project looks like one
person's work, it is one person's work.

The task for the leader of a team project is to work on the team, not
the project.

these rules will of course intersect with general programming guidelines. you can find tons of 'em ``out there''. i've an interesting list by alan perlis somewhere, and some by lesser comp sci professors. hmm. i also recall a few good ones on larry mcvoy's web site, and a pretty substantial db of quotes by some students at cmu.

here's one of my own: ``those who try to reimplement windows(tm) are missing the point of unix.''

The ratio of contributors to complaining onlookers decreases as project
size increases.

I have found that, generally speaking, a healthy open source project
has:

a core team with a few (1-5) project leaders

about 10x as many code contributors as leaders

about 10x as many contributors (mailing list discussants and bug
reporters) as code contributors

about 10x as many lurkers as contributors

about 10x as many users (people who download the product) as
lurkers

about 10x as many visitors to the site as actual users

The interesting thing is that the same "pyramid of participation"
seems to occur in corporate software development projects at large
companies as well. In fact, a lot of the rules for open source that
people have listed also apply to closed source development, so long as
there is some degree of voluntary contribution, which is true in more
work environments than one might imagine.

Open source projects are like protocols in that they are perfect if
you can't remove anything, not if you can't add anything.

You will know the good project manager by the number of changes he
rejects, not by the number of changes he puts in. The project manager
is responsible for deciding which patch should go in there. Always
accepting everything is sure to lead to complex and poor software.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser
code is live. It needs further work but already handles most
markup better than the original parser.