Came across this page through Slashdot today, I don’t agree with the comments on the page but a lot of the slashdotters anyway went after the poor fellow!!
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 others, but each one has a huge learning curve associated with it).
Java somewhat fixes the learning curve and the standard library problem, but still has the other two problems, and in addition requires the user to download the JRE before you can run any java program (a 25 MB separate install). One of my previous jobs had us trying to deploy a client-side Java program to much failure because of this hurdle. Server-side programming doesn�t have this problem so Java may not be such a bad choice for that.
Don�t Use Binary Protocols for Application Development
In grad school we spent a lot of time analyzing network protocols, network optimization, etc. A binary protocol may be good for core protocols of the Internet, but they are not a good choice for an application. Once again, this may seem obvious to some, and others may stop reading at this point in disgust. Here�s why binary protocols were no good for this project:
You waste too much time figuring out 1�s and 0�s instead of adding features.
You make it very difficult for others to write their own clients
Interface is Everything
This is similar to the #1 project management lesson. The program should be fun to work with. There should be buttons and things that blink. The interface should be the first thing you do. The interface serves as inspiration and motivation and helps you to learn how the final product should look. Yes, it�s going to change a lot. Yes, it�s going to have to be rewritten multiple times. Yes, it will never be good enough. Yes, it produces a never-ending list of additions and features to your already huge TODO list. But when someone downloads your program they will have something to do. No one likes to look at command lines.
These were the main lessons learned in the first two years of the Peekabooty project. The new roadmap to the future of Peekabooty will take these lessons into account. That future will be released in the coming weeks.
I have often regretted my speech, never my silence.
-Xenocrates
Some other comments:
Re:I think not (Score:4, Insightful)
by GlassHeart (579618) on Wednesday July 02, @04:46PM (#6352882)
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”.
95-5 Rule (Score:3, Interesting)
by jmacgill (547996) on Wednesday July 02, @04:55PM (#6352999)
(http://www.geotools.org/)
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.
Spell checker (c) creative spelling inc. (aka my dyslexic brain)
Not Project Management (Score:3, Insightful)
by drmofe (523606) on Wednesday July 02, @05:04PM (#6353111)
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.