Slashdot Mirror
What Makes an Open Source Project Successful?
crowston asks: "There have been a number of discussions on Slashdot and elsewhere about how good projects work (e.g., Talk To a Successful Free Software Project Leader), but less about how to tell if things are going well in the first place. While this may seem obvious, most traditional definitions of software project success seem inapplicable (e.g., profit) or nearly impossible to measure for most projects (e.g., market share, user satisfaction, organizational impact). In an organizational setting, developers can get feedback from their customers, the marketplace, managers, etc.; if you're Apache, you can look at Netcraft's survey of server usage; but what can the rest do? Is it enough that you're happy with the code? I suspect that the release-early-and-often philosophy plays an important role here. I'm asking not to pick winners and losers (i.e., NOT a ranking of projects), but to understand what developers look at to know when things are going well and when they're not."
My suggestion, read "The Cathedral and the Bazaar" by Eric Steven Raymond....not just that paper, but the actual book of papers he put together. Very good read, and he takes a lot of the ideas of open source projects and converts them into real world applications.
What makes Open Source (or ANY project) successful is ambition and drive.
You have to be realistic in your goals, and have the drive to see everything through. Open source projects that are abandoned or failed is simply because the developers gave up for one reason or another.
You know how you got together with your buddies to make a game, but never got very far? That is a classic example of a project failing due to lack of ambition and drive.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
It's easy.
Are there more people using the project than developers? If so, it's successful.
Do you enjoy working on it? Then it's successful.
Most open source projects are essentially hobby projects. Whether or not they are 'successful' on a large scale is usually irrelevant.
I don't have a sig...Do you??
Success being measured on how many hits you get on your download page and how many downloads of your project actually occur.
It's one thing to be satisfied with your own code, but to see others satisfied with it, well that's what I'd want at least.
The Pigloo
The same thing that makes any software project successful:
a win32 port.
Next question please.
I don't need no instructions to know how to rock!!!!
What I see as successful are the projects that do something that already being done by a successful commercial application, only doing it cheaper and very well.
The ones that do the same thing, only poorly, will fail.
The ones that end up costing more to implement than the commercial application, even if they do it better, will fail.
The projects that do something new, something people don't know they need, are doomed to failure from the start because your typical open source developer doesn't have the resources to market the product. There was a time when people didn't need sliced bread. Bakers didn't need bread slicers. But the bread-slicer-makers had the resources to market their product and convince the bakers and public it was needed. So now we have sliced bread, and nothing greater since.
Give me my freedom, and I'll take care of my own security, thank you.
to understand what developers look at to know when things are going well and when they're not
The bug list and feature request list are one way. Strong feedback implies interested users. Also adoption by other developers into the development group shows others are interested, so you must be doing something right.
Developers: We can use your help.
You have been sued by a huge mega corp with a team of lawyers over patent infringement and the EFF comes to your rescue.
-- Thou hast strayed far from the path of the Avatar.
Some projects are simply on the right spot. Good examples are X11, SDL and Mesa. There was overwhelming need for it, so more developers quickly joined ranks.
Some projects are outright glamorous in a geeky way. Anyone working on the Linux kernel enjoys the respect of any geek for instance. Stuff like drivers and VM are supposedly tough subjects and anyone involved in ANY way is much more kool than someone making widow managers, no matter how complex.
Some projects provide the much needed high of bashing the Goliath. Wine and Samba fall in this category. Look ma! No windows. And seeing Bill Goates and Balmer try and pull the rug under a project that makes no money is just glorious.
Projects really attract various developers for various collections of reasons. The best reason is the most original.. to scratch that geeky itch. Thats how Linus started the kernel and how others like Alan Cox joined in. Thats how UNIX was originally created and BSD nurtured in the universities. Being so big now, the opensource world has other reasons kicking in, like a smart student seeing the market is kaput, realises he needs something big put on his resume fast. Thusly security and networking projects boom! Included here are also java-related projects.
The most popular projects reach there because theyre there at the right time. Apache didnt quite start out with the best design, but a good webserver was NEEDED, and apache most of the time had more features than the rest.
How do popular projects maintain their status?? Momentum of course. Both apache and the Linux kernel are good examples. FreeBSDers fume on why dont teen hackers flock to BSD. Everyone knows Linux, and once its in the upper parts of the corporate, everone needs to learn it. The media follows it and the natural positive feedback keeps it going. True also for proprietary software, like the most used OS out there for example. Bad quality but who can stop THIS momentum easy??
Yet some softwares quality and design are simply good. They have the power to dethrone the champion. Qmail simple came and is gradually removing sendmail from its position. Proftpd is removing wu-ftpd, and we can only hope Linux or FreeBSD does the same to Windows.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
There is no one definition of success for an open source project. Anybody who starts one should have some goals in mind (e.g., hack on cool code, make something which solves a problem for me, make something which is used by 100/1000/1,000,000 people). Success is meeting those goals.
Here are a couple of examples.
I wrote GNU/Taylor UUCP. When I started, success for me was to develop a UUCP package which would be widely used by people without the money to spend on AT&T UUCP, and to be the premier UUCP package on free Unix systems. I met those goals.
I was the GNU binutils maintainer for a few years. During that time, success for me was providing, on multiple platforms, 1) an assembler which could handle whatever gcc generated; 2) a linker which was compatible with the system linker (on a non-free Unix system), and was faster; 3) tools which were very fast on free operating systems--specifically, much faster than gcc so that they were not the bottleneck for development; 4) adding full support for shared libraries. Those goals were only partially met--on Solaris, in particular, the Sun linker was better.
If you don't have any goals, then you can't succeed. If you can't measure your goals, then you can't know whether you have succeeded.