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.
Actually, he just says that C++ is no longer a viable programming language. A quick look at the sourceforge project page reveals that peek-a-booty is indeed written in C++.
If you were me, you'd be good lookin'. - six string samurai
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.
However, designing things in C++ and doing it properly is damn tough; many designs may seem easy to begin with, but then run into trouble with things like multiple inheritance from related parents, or simply that encapsulation is difficult because of the need for exposing the inner workings of classes... STL fixes some of this at the expense of code bloat -- it is easy to produce executables tens of megabytes in size.
Another problem with C++ which has been bothering me, and I would presume, the developers of Peekabooty, is the tendency towards static compilation and inclusion of everything. I looked at the source files here, and the sheer number of include-files compared to source files indicate that this probably does not compile quickly.
There is a way around this, if the application can be divided into several major and fairly independent components which then are compiled and linked as a number of dynamical libraries (.DLLs on Windows, .so on Linux and Unix). Now, with proper design, recompiling the whole lot is not necessary for smaller changes within one of the parts where no changes in this part has taken place. The trick here is encapsulation: do not let code in any one part know about any of the internal structure of code in any other part.
SIGBUS @ NO-07.308
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).
Java - install the compatibility VM; use the same binary on all platforms
.NET...
I'm laughing so hard Dr. Pepper is spewing out my nose! Let me wipe off my screen...
Trying to get Java applications to work on my Solaris workstation is a nightmare. I can't understand it because the company that makes Java makes Solaris. I try to figure out what the problem is, and hidden way deep in the README is this thing that says I need to install a different version than what Sun provided with Solaris. I fix that and it still doesn't work. Looking deeper into the problem, I see that I need a couple of other components that didn't come with the application. After about two hours of searching for the "myleetclasses.jar" and "ubercoolstuff.jar" files, I put them in a directory, fiddle with the CLASSPATH variable, and finally get the program up and running. And then it crashes five seconds later.
you either have to manage binary chaos or you have to start distributing your code as source.
Binary chaos is a pain. A royal pain. So I distribute my code as source instead. Easy. Painless. Users that don't want to compile can grab a prebuilt package from their distro or another repository.
Of course, I'm writing Open Source, and not cheesy shareware. Perhaps that's the true niche for Java and
A Government Is a Body of People, Usually Notably Ungoverned
-
Existing C++ code in Oracle products has already raised serious portability issues.
-
Oracle RDBMS is one of the first products to be ported to a new platform, often before the official release of the new platform. At the time of porting, a C compiler will be available, but a C++ compiler may not be.
-
C compilers for 64-bit platforms are far ahead of their C++ counterparts.
-
C++ compilers on some platforms are immature. It's far easier to write incompatible C++ code (than C).
<disclaimer> My views; not those of Oracle. </disclaimer>The Mozilla C++ Portability Guide also restricts use of some key C++ features (rtti, exceptions, templates (which rules out the STL by the way!)).