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 think not

[The Bungi]

While saying that C/C++ are not "viable" languages any more (and making the classic mistake of bunching them into a single blob), he muses that:

It requires compilation - as your code grows larger, the wait time to see if your code works increases. This delay directly affects how fast your code is developed.
It's really, really, really hard for people to learn it, and this directly impacts the number of developers you will have on an open-source project.
It uses static binding (Isn't that supposed to be a good thing?)
There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it).

So, basically, it has to be compiled (duh). It's hard to learn (no, it's hard to use correctly) and it has no libraries... eh?

I'm sorry, but this guy is not a software developer. The usual comments about "X is the One True Language" notwithstanding, I can't follow that because he thinks it's "too hard" and he thinks it's "not viable" and decides that it simply isn't a good fit for his project, then LanguageX must be dead. Perhaps he'd like to share with us which language his OS is written in. Maybe it's Forth or Scheme. Use the right language/runtime/lib/technology for the job and refrain from saying "X sucks because I don't like it".

Other than the dubious "this is how you do open source" slant I can't see how this article is even worthy of news.

Re:I think not

[GlassHeart]

A few other points in defense of older languages:

• An older language has had more lines of code written for it, so its weaknesses are better known, and more likely published.
• An older language tends to have more developers, which means any random volunteer is more likely to know it already.
• An older language has already fought "battles" for survival, and has been squeezed out of applications for which it is ill-suited, and continues to exist for a good Darwinian reason.
• An older language is more likely to be standardized, and more widely ported.

Let's take C, for example. An experienced C programmer will point you towards two or three books like van der Linden's "Expert C Programming: Deep C Secrets", or Koenig's "C Traps and Pitfalls". C is rarely used for GUI application development, but still widely used in embedded systems where space and speed are important. C is an ISO Standard, which is important for portability.

One mistake that many people make is to dismiss older languages when a new one appears with all the old features and then some. The old language does not become any less viable the day a new one comes out than the day before. That is, if a project will take you 6 months in C, it'll still take 6 months even after Java (which might cut it down to 5) comes out. The question is whether the unique costs of using Java instead justifies the 1 month saved, not whether C is still "viable".

Interface is Everything

[Snot Locker]

Often time this principle applies to people on the project, not just the software being developed. I've learned from experience that really sharp people with a broken user interface can destroy a project!! You have to try to minimize interaction points with folks like that and find where they can excel and use their talents without creating problems for the others on the team. A difficult nut to crack at times and a far more critical factor to project success that the programming language, source management tools, etc...

Repeating the same old misinformation

[h_jurvanen]

There are no standard libraries for C++, so there?s a lot of reinventing the wheel. (Yeah, there?s the STL and others, but each one has a huge learning curve associated with it).

This is a huge error that casts doubt on the author's credibility. What is commonly known as the STL is the C++ standard library, and it has been since C++ became an ISO standard in 1998. Doubters may consult books like the clearly-named "The C++ Standard Library" (Josuttis, 1999) to get themselves up-to-date.

Maybe that's just another drawback of C++... a lot of people don't know what the hell they are talking about and thus repeat misinformation?

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

[Arandir]

C and C++ are most certainly viable development languages. Let's see now: Linux, BSD, GNOME, KDE, Apache, Mozilla. Even Perl, Python and Ruby are written in C or C++. But maybe the author is saying those projects aren't viable...

Use the right language for the job. If all you're doing is interfacing to a database, then a scripting language may be the most appropriate. But if you're writing system software, then by all means stick with C and C++ with some shell glue.

Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."

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.

Re:95-5 Rule

[JamieF]

Or, you could write some documentation. It's not that hard but for some reason developers avoid it like the plague.

I keep reading these open source project managers bitching about how hard it is to answer all the emails from users and potential developers. Then you look at their project and see this:
FAQ: (under construction)
Documentation: (under construction)
and if you're really lucky they bothered to archive the developer mailing list, which is just about the least efficient way to document the project. (Yes, let's make every developer read all of our conversations ever, including all of the arguments we had and all of the things we decided to do differently later.)

It's not that hard; I've done it. You take a day or two and STOP CODING (oh no!) and write some actual words, document APIs, and lo and behold, you realize that you're also white-box testing your code because you were forced to explain what some code does ("hmm, that actually doesn't make any sense" / "oh crap that won't work in this case").

All of a sudden you can just point people at the docs and add stuff when new questions arise. Sometimes the answers are best expressed as a FAQ, sometimes as part of API docs ("oops, I didn't explain what these constants actually meant"), sometimes as end-user documetnation. But IT'S WORTH IT.

As for the common self-delusion, "we'll write the documentation after we're done with the code", all I can say is, read any process book there is. You're doing it backwards if you start with implementation and then back into writing down what the system does and how it's designed. Those things come first, THEN you write the code that does it. Otherwise you redesign the product dozens of times as you go, each time slapping yourself on the head and saying "oh crap I forgot it has to do this too" or "argh, I need this value from here but the API doesn't allow that". If you write it all down (which first requires that you *think* about it in detail) then you won't forget your good ideas, you can jump all over the place, you can write test harnesses that make sure the code does what the docs say, and you can point newbies at the docs and say "OK cool you can get started on the email notification part, we haven't touched that yet."

Not Project Management

[drmofe]

None of the lessons learned and reported here are directly related to Project Management per se. They are all by and large implementation issues.

There is also nothing new here. This does not advance the state of the art. History does not advance by people relearning the same lessons again and again. Just because they have been reported here does not make this article special in any way. This article could have been written in any of the decades of 70s, 80s, 90s (substituting en vogue languages for C++/Java) and still make sense.

In order to truly advance the state of the art, we have to think in far more advanced ways about project management and software development. True Software Practice and Experience requires much more planning and critical thinking than evident here.

If Open Source is to provide a useful and stable platform on which to build, then we certainly need a better vision of how to build software. Otherwise, we will be doomed to repeat history by implementing old things in different ways and not really gaining any control over complexity.

In summary, we still have a software crisis; Open Source will not change that; and summaries of software development experience that just say "I made the same mistakes as other people did" are not very helpful.