Slashdot Mirror
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.
Story was just released to subscribers and already it's loading slow so here's the article text for when the inevitable /. effect comes:
Peekabooty - Lessons Learned
By Paul Baranowski (paul@paulbaranowski.org)
July 1st 2003
Here is a review of the first two years of the Peekabooty Project. Over that time I have had to re-evaluate many of the things I learned in university and in the working world - many of the engineering lessons that I had been taught turned out not to work so well. The project management of an open source project is very different from old-school engineering project management, so I had to learn a lot about how open source project management works.
All of these problems have been seen before - by no means do I see these as unique. They are simply more data points on the "How To Do Open Source Development" graph.
What did I learn from the first version of Peekabooty?
Open-Source Project Management Lessons
Don't release before it does something useful.
This lesson is recounted in Open Sources: Voices from the Open Source Revolution as well as other places. I had even read about this rule before we released, but I had to learn it for myself. If you release too soon, you spend a lot of your time answering emails instead of developing.
The press is a tool - more like a hammer than a Swiss army knife.
The press is like a hammer - it can help you or hurt you, depending on how you use it. But like a hammer, it can't do everything, like cut a tree in half. It has limited capabilities and you cannot expect too much from it.
How the Press has Helped
The press has helped to bring awareness to key people that have the ability to help the project grow.
Press will get you more downloads. Whether this is good or bad depends on lesson #1.
Press will not get you more developers unless #1 is in place. The fastest way to get more developers is to network with other developers.
How the Press Has Hurt
The press loves infighting because it's a good story. However, the infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund things they feel will have a high chance of success, and instability erodes that confidence.
95-5 Rule
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. If you want to lead an open-source project, it helps to be independently wealthy. This allows you to forget about things like a job and work on the project you want to work on. In hindsight, wouldn't it have been better to take a really long vacation instead? Doh!
Engineering Lessons
C/C++ is no longer a viable development language
This may seem obvious to some people, and other people may recoil in shock. In college/grad school we were taught to believe that C/C++/Java, etc are the best languages in the world, so it was a very difficult transformation to accept that these languages are not viable development languages for application level work.
C++ is seen to be great for execution speed, static binding, object orientation, templates, and more. However, it is absolutely lousy for development time. Here's why:
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 ot
I have often regretted my speech, never my silence.
-Xenocrates
Not mentioned is the final langauge they used. Is the code in C/C++?
I do agree with the binary protocols vs. text protocols, but I'm not sure that is a recent revelation. Most of the Internet protocols use text based protocols.
It is hard to back the statement up with an "absolute" truth thanks to the fact that you will always choose your tools according to the task at hand. You can't say that language X is better than language Y when both are generally ment for different things.
Oh, and C/C++ are still viable options, but don't dominate the market as much as they used to.
In the past, we have used squid proxy running on a server at home to bypass the filters at our work so we could read Penny-Arcade...
you might want to check that out...
If you're interested in Open Source project management you might find some of these Mozilla lessons learned interesting.
It sounds like he busted his ass on a project no one appreciates because it is generally useless.
You should be good with C++ which includes having a knowledge of pthreads, the Standard Template Library (STL), and templates.
Plus the thing only runs under windoze or under WINE...
This really has nothing to do with MySQL. It due to the crappy database access interface in PHP and developer laziness/ignorance.
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
C is a must when performance is of big importance. If the program structure and APIs within the program modules are designed properly and in a clean way, I don't think it is much more difficult to maintain and improve on the code.
A "mixed" C/C++ approach is probably worthwhile using when the program has extensive GUI requirements and performance is still top requirement. Use C++ for the GUI (qt, wxWindows or whatever gui library you like) but for the performance critical parts and the algorithms that are in the heart of the program just use plain C under simple C++ class wrappers if at all (no abstract classes, overloading, etc.). Personally, I have found this approach quite useful.
my that-was-ridiculously-stupid meter flew off the scale
What about your attention span? The paragraph below says:
it was a very difficult transformation to accept that these languages are not viable development languages for application level work.
Buy a Nintendo DS Lite
He disparages both C++ and Java as open source development languages, and I agree with his comments on those.
I don't -- at least not his comments concerning Java.
At one time (before they were bundled) people had to download a web browser if they wanted to view a website. I don't recall any webmasters who felt that they shouldn't work in HTML because people had to go and download a browser in order to view it.
Every software project has prerequisites. Some projects require external libraries, others require external runtime environments. If you code an Open Source project is Perl, I'm not going to be able to run it on my OS/2 systems without downloading the Perl runtimes, for example. The only way to avoid this is to statically compile everything you need into a native executable which, once again, isn't going to work for people running on a different platform(s) than what you're building for. Now they have to go through the pain of installing (and possibly paying for...) a compiler, and then modifying the code to make it compile on their platform of choice.
If your application does something useful that people can't otherwise do, they'll take the one-time hit and download the Java Runtime (or any other project prerequisite).
I think this is a non-issue. As the administrator of a Java-based Open Source project that targets client-side Java (The jSyncManager Project), I can say that using Java hasn't inhibited the growth of my project significantly, as it provides value that people can't get elsewhere (namely, a single application and plug-in architecture that can run on any Java-enabled system, which allows organizations in heterogeneous environments to run the same application on all their platforms, reducing maintenence costs). As such, people who need this sort of value have no problem taking the one-time hit in installing the proper prerequisites.
Yaz.
like using high-level languages like Perl or Python. But when I need to write an application that I want ordinary users to be able to download and _just use_, I don't have a choice - I have to write it in C or C++.
.EXE file", Python can do exactly what you need. You can turn your app into a single directory worth of files (all necessary DLL's and a standalone .EXE - no interpreter installation required) using Py2Exe. Most ordinary users are capable of downloading and decompressing a .ZIP file.
Uhhh... unless you mean "when I need to produce a single
I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.
I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.
So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.
I could either:
I eventually chose the tcl/tk option, because of the following reasons:
So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
Eiffel is, or are you concerned about possible IP problems with the language spec per se?
take the best aspects of java, objective-c, eiffel and maybe some smalltalk like elements and roll them up into one language.
The D programming language looks somehow interesting...
You are almost a text book example on how to do things right.
See my journal, I write things there