The Rules of Open-Source Programming

Posted 16 Dec 2001 at 14:00 UTC by shlomif Share This

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 Rules in a PostgreSQL database, posted 16 Dec 2001 at 14:12 UTC by shlomif » (Master)

I forgot to mention it in the article, but you can grab it from here:

http://groups.yahoo.com/group/hackers-il/files/osp_rules/

Notice the Suggestor and Phraser fields.

Have fun!

Some alterations and additions, posted 16 Dec 2001 at 14:29 UTC by gerv » (Master)

> 1. Don't whine unless you are going to implement it yourself.

This should read:

1. Don't whine unless you can credibly threaten to implement it yourself.

> 5. A project is never finished.

... only abandoned.

> 11. When a developer says he will work on something, he or she means > "maybe".

...and if they say "immediately", they mean "probably".

And some of my own, from experience on Mozilla:

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

  • Those with the most opinions tend to contribute the least code.

  • Having more communication channels doesn't improve communication.

  • Don't expect people to read release notes.

  • Users believe that zero-cost software implies zero-cost support.

  • Users believe that "open source" == "change it to do what I want".

Gerv

31, posted 16 Dec 2001 at 17:15 UTC by voltron » (Journeyer)

31 is niether funny, whimsical, or true.

To-do list items, posted 16 Dec 2001 at 19:08 UTC by apenwarr » (Master)

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.

Avery

Some more "rules", posted 17 Dec 2001 at 07:17 UTC by raph » (Master)

Some more rules, more or less in the same vein.

1. Always give attribution. If you don't, you're not doing free software, no matter what the license lets you get away with.

2. Don't take on a dependency on some other project unless it's either mature or you're willing to maintain it yourself.

3. Don't try to push other people to take on a dependency to your project unless it's either mature or you're willing to see it through.

4. You really don't have any obligation to your users (or anyone) unless they're paying you.

4a. It really doesn't matter when it gets done.

5. The good reasons to do free software are to have fun, and to learn something.

5a. Don't count on being able to make money off it.

6. If you have a clear vision, stick to it. Don't let other people try to talk you out of it.

7. Don't be discouraged by competing projects. Chances are, they will fail.

8. Resist the pressure to join forces with a competing project just to save manpower. "Because it will be fun" is a good reason to NIH.

9. Accept it when other people adapt your work, perhaps not in the way you intended. It is the free software way.

10. If other projects have done useful things you want to steal, go for it. Tying together pieces is a good thing.

11. Make sure that it's possible to configure the backspace key to do something other than delete the character to the left of the cursor. Bonus points for discouraging this as the default behavior.

12. Do not expect others to contribute significantly to your project. If you treat it as a pleasant surprise each time they do, you will be happier.

13. Simple and lightweight almost always wins.

This doesn't feel anything like a complete list. But perhaps some of them will be amusing.

Corollaries to 4, posted 17 Dec 2001 at 10:53 UTC by Sunir » (Journeyer)

4. If you don't work on your project, chances are that no one will.

The corollaries to that are

4a. When others work on your project, let them take all the credit.

4b. Don't overshadow others by working harder than they do.

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.

#6 is for commercial software, posted 17 Dec 2001 at 15:22 UTC by abraham » (Master)

For free software, the rule would be:

The person who do the work gets to decide. Corrolary: The developer is always right.

[ For the overlap between free and commercial software: Whoever pay for the development gets to deccide. ]

#31 and #33 should be swapped, posted 17 Dec 2001 at 15:23 UTC by abraham » (Master)

Automated test are always the best tester, you are always the worst tester.

More on 4, posted 18 Dec 2001 at 02:32 UTC by dan » (Master)

4a. When others work on your project, let them take all the credit.

Yes, absolutely. Or just "Be generous with attribution", which has the attraction of succintity

4b. Don't overshadow others by working harder than they do.

That one I'm less sure about. "Don't overshadow others by appearing to work harder than they do"; maybe I could go for that...

proverbs, quips, maxims, posted 18 Dec 2001 at 16:53 UTC by apgarcia » (Journeyer)

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.''

ratios of developers to users, posted 18 Dec 2001 at 17:13 UTC by jrobbins » (Master)

I agree that

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.

More suggestions, posted 20 Dec 2001 at 07:57 UTC by tk » (Observer)

I'm not familiar with the numbering scheme used here, but anyway:

9. Give me refactoring or give me death!

9a. Any successful project without a design document to begin with will grow to the point where it becomes too unwieldy for any single person to understand.

7. Don't be discouraged by competing projects. Chances are, they will fail.

7a. If a competing project takes off from the ground, join it, unless you wish to cleave the chances of success of both projects.

Automated test are always the best tester, you are always the worst tester.

33a. Your own test cases and test scripts are your second worst testers.

33b. Others' test cases and test scripts are your best testers.

Re:factoring, posted 23 Dec 2001 at 04:07 UTC by KlausWuestefeld » (Master)

9a. Any successful project without a design document to begin with will grow to the point where it becomes too unwieldy for any single person to understand.

That's true. And it's also true for a project *WITH* a design document, without refactoring. :)

The advantage of not having an initial design document (or not following it) is that the quality, simplicity and elegance of your design will not be limited by it.

Regression testing, posted 30 Dec 2001 at 03:06 UTC by loam » (Journeyer)

33. Your test-cases and test-scripts are your worst testers

This should read:

33 Regression testing reduces the communication effort to fix a bug.
33a Alpha testing tells your whether you have fixed the bug on your platform.
33b Regression testing tells your whether you have reintroduced any previous bugs on your platform.
33c Your co-developers tell you whether you have fixed the bug on other platforms.
33d Your users tell you whether the bug you fixed was the bug they wanted fixing.
33e Fixing a bug without adding a test case into the regression test-suite is asking for your co-developers to re-introduce it.

Some words from an old fart, posted 2 Jan 2002 at 03:33 UTC by Fefe » (Master)

  • 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.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

    X
    Share this page