Open Source Project Management Lessons

cpfeifer writes "Paul Baranowski takes a moment to reflect on Open Source Project Management in his blog. His reflections are based on the first two years of the Peek-a-booty project." Interesting comments on media coverage, choice of programming language, when to release a project, and more.

Comments

I bet...

[macshune]

The peek-a-booty project is a lot less interesting than I would imagine...

Project management Lessons

[stanmann]

Is Open source project management really that much different from any other project management?

don't release before it does something useful

This is a rule in "traditional" project management too.

and the other lessons read just like Project Management 101 too. I would have loved to have seen something insightful or interesting about how open source changes the development environment or the management environment from single location to distributed, but no such luck.

Compilation time bounds productivity?

[BreadMan]

It requires compilation - as your code grows larger, the wait time to see if your code works increases.

Everyone knows that once your code compiles, it will work!

An excerpt

[Call Me Black Cloud]

June 14, 2003

Dear diary,

I have decided to record my thoughts on managing the project "peek-a-booty". The most important lesson I've learned is not to use booty in a project name!

Sure, it was funny two years ago after a few beers, but I swear the next person that makes a "booty" joke will die. I'm serious. "Dude, is it for peeking up skirts?" "Hey, if you integrate telephony you can call it 'peek-a-booty-call'"

In other news, I'm starting a new project to manipulate network traffic, this time using Java. I'm thinking of calling it 'jAck Off'. I like the sound of that. It will be good to get that whole 'booty' thing behind me...

Re:"C/C++ is no longer a viable development langua

[hackrobat]

I work at Oracle. C++ is banned here. Apparently, Oracle software runs on more platforms than there are C++ compilers for. Therefore, C++ is a strict no-no. The internal C coding standards doc reads somewhat like this:

1. Don't write C++.
2. If you've already written C++, rewrite in C.

:-)

So it's either C, or Java (lately). Anything else is considered as scripting (Perl, Shell, SQL).

Repeat after me: The Interface is Everything

[2TecTom]

As an interface designer and technical writer, this has always been my personal mantra. It's finally nice to see that at least one engineer finally actually gets it!

You probably won't believe how many MMI designers and technical writers are feeling totally vindicated at this point.

Really, it's not often one sees history in the making. ;~)

95-5 Rule

[jmacgill]

Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this.

Actualy, if you are about to set out on a new project, its probably best to tell yourself that you are NOT willing and ready to accept this.

6 years ago I started a project called GeoTools and it was, for the main part, excactly that - two people doing most of the work. This was fine for a few years but over time the user/developer ratio got out of hand.

Eventualy it became all but impossible for the two lead developers to support 300+ users and although other developers wanted to contribute it became dificult to 'train' new developers as the knowledge of how things worked existed mainly in the heads of only two individuals who had done 95% of the work.

Two years ago we took the descision to re-design the toolkit from the ground up with as much input from as many people as possible. Since that time we have strived to make sure that as many people as possible have an input into the design process and we keep that process as open as possible by pubishing the IRC sessions in which discussions take place.

The project now has 9 very active developers who are members of a Project Management Committe and a number of other active contributers as well. The end result is that quiries to mailing lists get responded to far more quickly.

Getting other people to work on your project is often - TO START WITH - more effort than just doing the work yourself, but the pay off is HUGE, as you then have someone else who can explain things to others.

If you ever have a contributor who gets stuck or confused and you find yourself thinking 'oh, it will be quicker/easier for me to do this part myself' STOP. Spend the time, help them work out how to do the modification even if it takes a few hours when you could have done it yourself in minutes becuase after you have invested the time in them, they will be able to add things in minutes too, and they can teach others as well.

If you work on a tight, well defined, non-evolving project then most of my ramblings are probably irelelevent if not they they may be of use. The only danger is in investing time in helping developers who then wander off - it happens, but I tend to find that the more you invest in them, the less likely they are to loose intrest.