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."
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!
Are the users happy, overall?
There are no karma whores, only moderation johns
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
If a piece of software serves your needs -- whether you built it yourself, modified something someone else made, or just downloaded a pirated copy of something commercial -- it is "successful software."
"Success" is not really a concept that can be accurately applied to "software in general."
If you are an OSS designer you will have your own standards of what is "successful" and what is not for your baby. These are not necessarily standards held by anyone else, nor should they be.
Does it really matter?
Really, the only reliable measure of a software project's success is if its useful to you and meets your needs. If your satisfaction with a project is dependent on other people's useage/opinions of the software, you will probably never be happy. Remember, open source software development is for 1) fun and 2) to scratch an itch. Anything more is chasing after the wind...
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.
is one that meets it requirements.
sig
Profit indicates success of the marketing plan, not the software development effort. It doesn't matter if you're coding for love or for money, there are some things that apply to both. Take a look at process and product. How is the process? Are there goals and are they being met? How is testing coverage and how often is testing being done? Is the code maintainable? Take a look at the end product. Does it do what it's supposed to without too many bugs? Are issues being addressed in a timely manner? Most importantly, how well does it fit the need for which it was designed?
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.
Probably the same things that make commercial projects a success, a well defined, well structured and maintained project definition and active development. If you look at some of the more successful projects out there, such as Mozilla, they are actively being maintained with a goal in mind. If a project has no user base, then it is doomed to fail. If there hasn't been an update to it in like 2 years, then chances are, unless it was perfect the first time around, it will fail. If the project isn't useable or provide any sort of functionality or value, it is doomed to fail. After all, how is a project going to succeed without a user base. Commercial support doesn't seem to hurt Open Source projects either. With commercial backed projects, some of the more important things that programmers are inept at, like UI design, could be addressed (although there have been very few instances where it has).
I look at the several open source projects I have done, from just a few lines of code, to several thousand, and I think success, like beauty, is in the eye of the beholder. If i have users, and users that enjoy the software I am happy. I am just elated when the users get on my forums and help each other out. Not only are there people out there using my software, but people that like it enough to keep coming back to my site and post helping other less experienced users with issues and chit chat.
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
Hmm, a lot of the posts seem to be missing a big point.
A good metric for "success" in an OSS project must be whether the developers have fun hacking on it. Even Linus has said repeatedly that he made the kernel "just for the fun of it".
Most of the projects are hobbies, and the point of a hobby is to provide an interesting diversion for the hobbyist. If thousands of people get to enjoy a web browser/OS kernel/game/whatever as a side effect of the hobby, well that's just dandy. But if it isn't a commercial product, then who cares about market share, step-3-Profit!, or any of that other nonsense?
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
The important gateing factors on any Open Source project are:
1) Motivation (a problem to solve, that people
can agree upon)
2) Working code (something that comes close to
solving the problem, or from which people can
see a solution)
3) Community (communications and peers to provide
a context in which the work can take place)
A lot of people have #1, so they declare a Source Forge project, try to cookie-cutter #3 (impossible to do), and leverage having #1 and #3 into someone creating #2 (also impossible to do).
Mozilla had #1, some of #3, and almost none of #2 for a very, very long time, and it's still suffering the backlash from it (for example). BSD did not take off until Bill Jolitz made it boot. Fetchmail sort of works, but no one cares. Etc..
As a matter of fact, I claim that, given any #2, I can *find* #1, and *create* #3.
It's trivially easy to start Open Source projects by the dozens, if you are even a halfway decent coder: just make something good enough to work, but lacking enough to convince a group of people that they could (and should) improve it, rewrite it, or otherwise do better.
That sounds like most modern commercial software, to me, since it has legacy design factors from the 1980's/1990's causing it to need documentation, support, and training materials as part of the (no longer relevent) copy protection systems that grew up around the software developement process.
Seriously, it took a *lot* of skill to come up with the first Word Processor that needed documentation for people to be able to use it ("PC Write"). The author, Bob Wallace, said at one convention where he spoke, "Software...", gestured expressively above and to the sides of his head, "...is all up here. I sell manuals.".
-- Terry
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.
I think that (even though this may be obvious) that the 'success' of a project largely depends on its initial goal. Traditional measures don't really cut it.
For example , if I start an open source game, and my goal would not be to make the next DOOM/UNREAL/HALF-LIFE killer for linux, but to have fun trying something hard. So the success of the project of that would be how well I did that, with or without the help of others. Anything after that would be a bonus
If a project is really ambitious in what it wants to achieve (mozilla, WINE, etc...) then its success will depend on more tangible factors... how bug tracker submissions (is anyone trying it out and care enough to report bugs), how many downloads are there (is the word out?).
The real catch though is that OSS is much more dynamic. My OSS uber-linux game might become a huge success and become much more ambitious as a result and so the project could start to take shape as something much more elaborate. This aspect is a huge advantage and disadvantage of OSS. The project will change as whoever becomes interested or disinterested in it.
So, perhaps a successful project should have interest in it by whomever. At least by the developpers involved, and of course in a general sense as well. It doesn't really matter if it becomes 'the sliced-bread' of OSS (as much as the developpers may dream - a definite good thing) but as long as someone cares about it. Most projects suck, some are good ideas poorly implemented, some are bad ideas well implemented and some manage to get both right (Apache?). They all have potential, but without someone caring that initial potential will go nowhere.
So if you are still interested in developping your project, then I would say its still a success.
"The large print giveth, and the small print taketh away" -Tom Waits
What makes open source projects successful is obvious. Look at things like Mozilla, gaim, DC++, CDex, etc. What do they all have in common?
Most open source projects fall into one of the following categories.
1)A program someone wrote for themselves, and decided to make freely available for the heck of it.
2)By geeks for geeks.
3)Done by a group, for free and open, but thinking like a commercial product.
3 are the succesful projects. They have good GUIs, they don't crash, they have features that make them better than commercial alternatives, they install easily, they work on many OSes, and they are generally useful. They are often mistaken for commercial products. Slick interface is key. They just happen to be free and open.
The GeekNights podcast is going strong. Listen!
The same thing that makes any software project successful:
...or you can tell that a project is successful when people keep asking for a Win32 port.
a win32 port.
Opus: the Swiss army knife of audio codec
I'm not sure whether or not stratjakt was trying to be a troll, but I think a Win32 port of a project really is a legitimate indication of success. It likely means somebody enjoys your program so much that they want to use it in those situations where they're forced into using Windoze. Because of the number of apps that are available for Windoze, that's a real compliment.
Good forks have the following in common:
Consider some good forks:
- mozilla -> phoenix -> mozilla(whateveritisbird)
- X11 -> XFree
- GCC2 -> EGCS -> GCC3
- linux is perhaps the best example - two major branches running all the time, and both
(particularly the 2.3, 2.5, etc. dev fork) heavily forked themselves. 2.5 changes are
often backported to 2.4, even to 2.2, and the maintainers all still talk to one another.
By way of contrast, the GNUemacs/Xemacs fork is a prime example of a bad fork. Bad blood, wilful incompatibility, divergence, duplication of effort.If XFree's current "governance fork" turns into an all out code fork then that would, I fear, be a bad fork - all that bad blood will surely make things very difficult technically.
So perhaps the best advice to a successful project is "encourage forks, and provide a safe environment for them". Apache and Mozilla both do this, to their benefit and credit.
## W.Finlay McWalter ## http://www.mcwalter.org ##
Actually I'm writing some software and will consider it a success when it is good enough to be accepted into the gnu project.
Its like having to buy the knock off of your favorite cereal because its cheaper and you are poor. But in this case, since it is worse than the originals and costs more (time to figure it out), you should never use it.
Open source software today has no cleaning mechanism to remove old junk and concentrate development resources on the cream.
The one thing that everyone seems to have missed is that successful Open Source Software tends to have a greater scope of use than it's original conception. The programs I find myself using are programs that can interact with each other in a modular fashion; whether that be throught a piped command, or simply support for "generic" file formats (such as XML, CSV etc etc). With a little effort you can bring together a suite of programs you already have in your library to get a task done, rather than wait for the possibility of someone else writing a specific program.
This is one downfall of the Win32 platforms, they currently do not provide the same flexibility of application as the various Unix variants provide. If you don't have a log analyser, knock one up with Perl, or a combination of various GNU/Utils (Grep,Cat,Less etc etc etc), or a C/C++ program, or however you may wish. There seems to be a comfortable number of ways around most problems in *nix. This is the kind of task that one would have a dedicated program cluttering the desktop of a Win32 machine.
Anyway, enough Micro$oft bashing. The fact is that OSS provides a free (and often high quality) solution to problems. OSS is often born out of a necessity for a program, where there is no viable and affordable solution, and what could be better than software which gets the job done for free!!!
If you want to write successful OSS be clear about your goals, achieve them using standard interfaces and as efficiently as possible. Don't spend time on features that won't be used - too many programmers spend too much time on insignificant features, time that could be spent ensuring that the damn thing works in the first place (sorry pet hate of mine). And finally don't try to reinvent the wheel. There are a lot of good apps out there that can't really be improved upon. If you geniunely believe that you can improve upon a solution then more power to you, however it can be a pain sometimes having to search through several second rate apps to get to the one killer app that you've been looking for.
God bless SourceForge
If they were good products (i.e. worth their price), people would be willing to pay for them.
The burden is yours to show that this is so. From where I stand, people take a 90% product for free over a 100% product for cost any day. And if the for-cost people try to provide 90%, the same people whine excessively that 90% isn't good enough because they paid real money and deserve better.
Everyone wants free stuff because they have no money to buy it. They have no money to buy it, of course, because they don't charge for what they themselves make. This is not how capitalism is supposed to work.
Well, that's a market. It doesn't care about individuals but about society.
Actually, markets don't care about anything at all. They simply have effects, and when they have effects that are societally bad, we try to herd the market in a new direction. Right now we're headed as if our compass was set for 'please economically disempower all programmers'. One day we'll all be able to program and none of us will be able to make a living at it.
It will be like gardening. We can all buy tomato seeds for our garden, but none of us can be a commercial farmer any more, not really. Because commercial farming means global delivery, and that market is all locked up by people with the commercial capital to sustain it. Arthur Daniel Midlands can do it, but mere mortals cannot. We won't have commercial capital, because we have no economic power, because we've (as a group) given away everything we have of value and said "please don't pay us for it--it's your right to take and not ours to benefit". That's no future I aspire to.
Kent M Pitman
Philosopher, Technologist, Writer