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.
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.
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
I first heard about this project from a BBC Article where they describe it as a "browser free from censorship or outmoded intellectual property laws," which is something I think we can all get behind! However, they made the point that the project could have been better named.
It seems the author has picked up on that now, too. I think most telling is this passage from the author's blog (weblog):
Hopefully, he'll take these insights to heart!
Consensual sex is boring.
Well, there is the STL and the Standard C++ library. These are not really hard to learn; it is just that they are both fairly new. The Standard C++ library and STL didn't become standard until around 1998 when the ISO C++ standard was formed. Because that is only 5 years ago, and C++ is much older than 5 years, there are still a lot of books and courses floating around that don't teach Standard C++. When you learn "Visual C++," or whatever, from an older book (or bad book) then it seems that the STL is hard because you are not use to templates and all that stuff (mostly because many older compilers are broken, ie VC++ 6.0, and don't support the standard).
If you learned STL and the Standard library when you first learned C++ then maybe they wouldn't seem so difficult. Also, many people who first learn programming in a language such as Pascal, like me! :), have difficulties learning generic programming because they are so used to thinking about what types your variables are. Templates and generic programming are very powerful, if you are willing to spend the time learning how to use them.
...interesting if true.
C/C++ is no longer a viable development language
... Ever heard of protocol layering or data marshalling ?
Sure, in the scope of this particular project and in the context of their skillset and development practices.
Don't Use Binary Protocols for Application Development
Bah, I'm speachless. Yeah, right. Better yet convert data to PNG images and pass those along - it will allow you to debug networking layer with a web browser
With all due respect, it looks like Mr.Baranowski either learnt wrong lessons or likes to summarize things beyond reasonable limits.
3.243F6A8885A308D313
There is, indeed, a standard library for C++, one which is widely supported - STL.
I don't think that's what he meant by a "standard library". He's thinking along the lines of Java's standard library -- a standard library that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc. You know, the kind of stuff that would be convenient to have bundled with a language. STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.
So it's either C, or Java (lately). Anything else is considered as scripting (Perl, Shell, SQL).
His point that this is not unique to OSS Projects is a good one. While OSS development has unique constraints most are around people and personality. In an office we all have to get along or get fired, in OSS it can sometimes be worse.
...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...But when someone downloads your program they will have something to do. No one likes to look at command lines.
For example:
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.
It is too bad on so many mailing lists ego/attitude/personality or just plain rudeness show up. Things you would never say to a coworker, make it onto a mailing list for eternity, or at least what looks like one. I hope people take this point to heart before posting.
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.
Looking at sourceforge I see this lesson again and again. The idea that if I create it they will come, and build. Forgotten, or unknown, is that nearly all had a real need to be built first. I needed application ZAFDE so I built it. I then released it and people thought they could build on it, and so on.
I wanted to learn C++ or JAVA or XYZ is the reason we have 2,134,931 notepad applications, not OpenOffice.
C/C++ is no longer a viable development language
I knew we would see a flamewar as soon as I read it. My thoughts:
- Both are still viable. Much like his hammer analogy, they are not good for everything.
- What makes them "bad" for development, makes them "good" after they are developed.
Does it matter to the user that it took 81 minutes to compile? Nope, they have the binaries or compile it once and run it for years.
Every language has a shortage of people who know it. Or specifically a shortage of the people who know it and are willing to work on OSS project PDQ.
Static binding is good/bad/sometimes both. Yes it is.
All the negatives he spoke of are positives after it is developed. Which we hope is long compared to the time spent developing it.
If there is one thing projects should take away, it is probably this:
Interface is Everything
I like command lines. I use them, but I understand they are power tools. Most people do not like/use them and consider them an indicator of a poor product. Even while it may not be technically true, perception is reality in this.
He said it's no longer viable for application level programming... Linux and XFree are certainly not application level, and argubly the Mozilla core isn't either (the front end is, but you could wrap the Gecko API for some other language to create that).