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."
the "..." part before the "Profit!"
taken! (by Davidleeroth) Thanks Bingo Foo!
Well, just make sure that project isn't like BSD... Because, well, you know, thanks to certain surveys ... BSD is dying!
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!
1. Start an open source project 2. ...
3. SUCCESS!
and it does what it is supposed to do, cleanly and efficiently, then by definition it is successful. Popular and successful are definitely not the same thing, even if you gauge a projects success by its popularity
Are the users happy, overall?
There are no karma whores, only moderation johns
if it actually works...
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??
o - it fills a need
o - it is well documented and maintained
o - it either came first Or it was so clearly
and overwhelmingly superior to its predecessors
that it supplanted them
why do people ask these questions?
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!!!!
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.
Why, Ninnle Linux, of course.
is one that meets it requirements.
sig
You can use Google to see how often the name of the project comes up. Discussion in Google groups is also a good sign.
Financial success is based on getting good people, having limited resources, but lots of ambition to succede.
A good project manager, and a good design are really all you need. The other staff will be successful regardless of skill as long as they are happy and have a feeling of accomplishment.
Personal success is harder to measure. It is based on 90% blood, sweat and tears, and 10% skill and knowledge. Lots of effort leads to success more than lots of brains.
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?
Milestones: establish concrete goals when you start the project, along with a timeline. Of course, these may evolve over time. Happens for commercial apps, too. If concrete milestones aren't met at some point, it's just vapor.
Traffic: both developer and user. Is there a relatively continuous level of input/interest in the project? If developers don't want to develop, and users don't want to use, it's probably going nowhere, even if it's the best thing since the BeOS.
"If, therefore, any be unhappy, let him remember that he is unhappy by reason of himself alone."
~Epictetus
I thought it would have been free pizza and beverage on a paypal account.
SCO to Hell
Stallman demands that people call it GNU/[Foo]
As an end user of successful open source software, I would have to say that the best way to get feedback on the success of your project is through an X-users mailing list where X is your project. It seems to me that the more activity in a mailing list usually indicates the size/success of a project. I have spent time in the past simply lurking on a mailing list for a while for products that I am evaluating, and in other cases, I join the mailing list to lurk right away on desktop software that I am not already familiar with. It is the best measure thusfar that I have found.
Stable in relation to the time invested.
Useful...to someone (this is open to broad interpetation).
It should have the goal of attaining at least as much funtionality as any of the software that it is replacing.
Other examples of good OSS is squid, openoffice and, yes, even Linux (Red Hat 9 is least as functional as Win98SE, and that is just from an end user standpoint).
Just my W.O.
WAR TUX!!!
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).
on one of my open source projects I used (more accidentaly than deliberately) the technique which is standard among people who write exploit. I have a small error in the makefile which causes something liek 50% of people come back for help on compiling it. This gives me pretty good estimate of how many people are actually using the package :)
Of course this leaves out win32 users who just download the binary, but oh well.
I passed the Turing test.
Software developers! And to atract developes you have to be successfull at some degre. The formula could be to spent full time at the begining of your proyect to create a good codebase and atract other develpers. Then you can lower your guard a little and continue your normal life.
BSD licensed software can't be stolen....
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.
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.
Most of the time Open Source Projects are something you start to solve a problem for yourself or you company and you release it open source for other people to use it so they wont have to program it them selves. So often for smaller open source projects popularity and success is not really that important, it got the job you needed done and it works. If other people like it then thats great. If they don't like it then no loss for you. Now the trick to make an Open Source product that is successful and profitable. The first part is coming up with an idea that a lot of people want and cant find a good solution elsewhere. Advertise to people who may be interested and see if they are willing to help out. When the project gets to a usable feature advertise it some more (Word of Mouth is usually the best type) to people who could use the project. You can usually judge the success of your project by counting downloads from your site. and availability around the internet. (if your program is on say on most of the distributions and you are getting a lot of email about how to improve your product. Then you may have a good OSS project. Well you want to profit from this... Well you can offer to install it at location for a profit. Sell CDs of it. Polish up on your public speaking and give speeches to linux expos and stuff. Offer support for your product. Garentee to add features for money the more money the faster they get done. Basicly the open source model is just like the closed source model. But you are giving away the software and selling services. There is still supply and demand, competition, expenses taking place.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
It has to be a project at least three years old. Just look at Perl, PHP, Mozilla, Linux, GNU...
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
bLING bLING bLING bLING
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
Quality, Usefulness, Progress, Maintenance.
Quality, because you want something that works. Usefulness, because else there is no use to the code. Progress, because you want the project to evolve constantly. Maintenance, because you don't want to use software that has a buggy, unmaintained codebase.
A message from the system administrator: 'I've upped my priority. Now up yours.'
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.
Wearing pants should always be optional.
Are you still having fun?
I've commited some of my spare time to open source projects and even started a few pet projects of my own. While success can sometimes be measured by number of users, or downloads, or mailing list traffic, I think it's worthwhile to step back from the project and make sure you're still having fun. At least that's important for those of us who develop open source software as a hobby as opposed to those who do it for a living (and there are many more hobbiest out there). If suddenly you find yourself dreading to read your mailing list or fire up you text editor or IDE, then you know it's time to take a break or re-evaluate the project.
Then again, every developer and project has different goals and really it's only by these individual metrics that a project or individual's success can be measured.
There was an interesting thread on the Jakarta general mailing list about this a couple months ago. You might want to check it out.
Who said Freedom was Fair?
Easy:
Having a closed-source product to copy.
Heh.
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
what makes a project successful, is not just if the goals and deadlines of the project are met, but if when you go to feltch the cum juice from his rectum after you've penetrated his firm buttocks, you don't get a lot of dribble on your face.
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
It's all downhill from there.
we once had a very successful project in which we took a prostitute, knocked her teeth out, then took turns french kissing her bloody mouth.
Read Get Your War On 23 to find out.
Cheers,
W00t
How about how well the piece of software manages to stay true to its objective? One of the great things about OSS is that people can take source code and fix it up to do something they need but at the same time, 1000 people with their hands in the pot has the tendency to make a project go nowhere and collapse under its own weight.
I think all that is needed is for the product to do something useful.
If I make or find something that does something useful, and actually works, it is a success.
I have several simple scripts that are successful, they simply do what I want.
1337/\/355 /\/\4|{35 1!/\/|_|>0|2
GCC was on that list but they got smart when they changed with the fork. Alot of opensource is not successful if you ask me.
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!
I think that success can be reasonably defined as attaining goals.
So the answer to your question is wholly dependant on your goals for the project.
Do you want to out-rank Linux on Freshmeat?
Do you want to clone a commercial app?
Do you want to create the gold standard app for a particular purpose?
Do you want to learn a new language?
If attain your goal, that would be success. If you end up taking a detour that is as interesting, useful, or fulfilling as your original goal, that is probably success as well.
Anything else is probably failure.
You seem to equate success with popularity. Download stats are pretty easy to monitor. You could do google searches for your project and your "biggest competitors" and count the hits. (You could even do sucks/rocks analysis.)
-Peter
My goal is to have something that is useful to myself. Nobody writes code for free (as in beer) if it isn't useful to themselves. So if my code does everything I need well (no bugs), then I have succedeed (and can call it 1.0).
Wherever you go, there you are!
The sooner western culture gets away from "monolithic thinking" the better off we will be. So many of the problems in our society is the result of that. Actually that's wrong. It's not just America, it's the whole world. When people stop thinking for themselves and believe what some one else says, we get stupid fanatics. As bhudda said it best, finding a balance for oneself is the way to happiness. well he didn't say that exactly, but something like it.
I can't claim to be part of any largely used OSS projects but in the smaller circles I travle, recognition is all I look for and how I define success. You want to hear "That perl script thing that dude worte to scrape all my assignments off blackboard is really cool." in the Union. That is how you know your project has been a success.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
As I and others have said, success for an open source project is defined by meeting your goals.
But let's say your real goal is to be a respected member of the open source community (which, as we all know, leads to fame, groupies, and vast wealth). What should you do to meet that goal? (Actually, there are several ways, but I'll only talk about ones which involve starting an open source programming project, since that is what the original question was about.)
First, your project needs to be something which other people will want to use. Don't write another mail reader. Write something new, at least new to open source. If you don't know what people want, you'll have to ask them. In general, your project needs to either be an open source replacement for an existing proprietary program, or it needs to create a new and interesting niche.
Second, your project needs to work, at least minimally. You have to be able to get it to the point of working, either by writing it yourself or talking people you know into pitching in. If your project doesn't work at all, few people will contribute to make it better.
Third, you need to sell your project by mentioning it on Slashdot, on relevant mailing lists, and on relevant web sites. You need to do this respectfully. One approach is ``I'm looking for suggestions on how to improve my FOOBAR program. It can already do AMAZING THINGS, and I'd like to know how to make it work better for specific users.''
If you follow these simple steps, you too will be on the road to fame and fortune! When you get there, just don't forget the little people who helped you along the way.
Profit can be measured any number of ways. I think that the biggest incentive for most OSS projects is some form of "my name in lights" recognition factor.
For instance; OpenBSD Leader Theo De Raadt has to sell tee-shirts and cds in order to pay his developers. You could say that the OpenBSD project is a failure as it does not generate revenue. However, this is misleading as OpenBSD is the premiere free unix in terms of stability, reliability and having "no remote holes in the default install".
So, while Theo will never need to worry about finding a tax shelter, he does get to bask in the fact he is widely acknowledged [sp?] as being the 3l33+ of the 3l33+...and by that measure, OpenBSD is an unparrelled [sp?] success!
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 ##
An open source project is succesful when it makes Bill poorer and the world richer.
you know the thing works if large corporations and/or governments try to stop you. ask dvd jon, phil zimmerman, justin frankel, ...
It seems to me that this is actually two questions with a serious caveat.
The first caveat is how we define Success. In a strictly software engineering sense, success is the fulfillment of all of the requirements in the initial requirements doc as well as the requirements in the detailed, technical requirements document. Out in the wild, software success is measured in different terms. Terms like installed user base, overall user satisfaction and often sales or other money-related, measurable metrics. For free and open source software, I see no reason to abandon the non-monetary metrics. Installed user base and market share are two very good metrics even when the customer got the software for free.
The two questions this one breaks down to are:
1. How do we measure the progress of the project during primary development
2. How do we know that the project is successfull once completed (this is basically answered in the caveat)
The answer to those questions relies almost entirely on the stated goals of the project (the stuff in that boring requirements document) and the definition of success
Question 1 is much more interesting and useful than question 2 for various reasons. What metrics are useful in guaging the success of a project while it is in development? This encompasses a whole lot of area but the primary thrusts should still be similar to traditional software project management. Namely, creating metrics to measure the quality of the product and to measure the progress of the project.
Quality metrics include things like comparisons to the requirements, code reviews, and statistical analysis of the code to estimate the number of bugs per XXXX lines of code and thus the number of bugs in the entire project. Many metrics like this are only useful if there are industry averages available for comparison.
Progress measurement is an entirely different beast. It can be based on a timeline(planned functionality implimentation over time) or based on the overall completion of the project (we just finished 3 of our 6 primary goals so the project is roughly 50% completed). Of course, the developer may weight the functionality points differently depending on their complexity. The real pain here is requirements migration over time. This is a big problem for OSS because developers love to continually add functionality as they go and there aren't any project managers to keep them in check.
Unfortunately, there is no quick and easy answer here. Finding the answers will take a bit of work and invariably depend on the individual project in question.
I can't comment on Gnutella, or Open Office but I am wondering what logic you use to call Linux bloated? I mean its not like when you compile it you can'y opt in or out of almost every kernel funciton save for the absolutly required stuff like the schedualin g system. You can still easily get a kernel down to 500K smaller if you really try I would bet, and that is without modules. To call java bloated is also somewhat trollish because to do what JAVA does it sorta the VM sorta has to beable to do everything, now wether or not you ever really need to use a tool like JAVA or should ever is an other debate. Mozilla is as we comment in the process of shedding its so called bloat. Howver even in its current release if you do your own build and get in no deeper then ./configure --diable-featureX you can build a lean mean mozilla with a reasonable memory footprint. Features are never bloat unless you don't need them and as long as you can do your personal installation without the stuff you don't need its not fair to call something bloated.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
I think code quality should be enough for success. Open Source by definition is something we'd all want. Therefore it should measure success by the quality of its code.
Also, who says you can't tell if users are satisfied? There are many ways you can gather feedback even for open source projects. You thinking it totally flawed to think user feedback is a non-issue with communally developed code. It is in fact its major shortcomming.
What Open Source Project?
Luck?
YES. Luck. Luck that your uber-buggy 100 mph tape version is picked up and used enough for poeple to send you fixes. Luck that you gain the interest of at least a few someones willing to maintain the code, and integrate new ideas into it. And luck that the functions of your project is not enveloped by a larger open-source project 6 months down the road.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Click me! Click me!
As everyone knows, Open Source software is the wave of the future. With the market share of GNU/Linux and *BSD increasing every day, interest in Open Source Software is at an all time high.
Developing software within the Open Source model benefits everyone. People can take your code, improve it and then release it back to the community. This cycle continues and leads to the creation of far more stable software than the 'Closed Source' shops can ever hope to create.
So you're itching to create that Doom 3 killer but don't know where to start? Read on!
2. First StepsThe most important thing that any Open Source project needs is a Sourceforge page. There are tens of thousands of successful Open Source projects on Sourceforge; the support you receive here will be invaluable.
OK, so you've registered your Sourceforge project and set the status to '0: Pre-Thinking About It', what's next?
3. Don't Waste Time!Now you need to set up your SourceForge homepage. Keep it plain and simple - don't use too many HTML tags, just knock something up in VI. Website editors like FrontPage and DreamWeaver just create bloated eye-candy - you need to get your message to the masses!
4. Ask For HelpSince you probably can't program at all you'll need to try and find some people who think they can. If your project is a game you'll probably need an artist too. Ask for help on your new Sourceforge pages. Here is an example to get you started:
Thousands of talented programmers and artists hang out at Sourceforge ready to devote their time to projects so you should get a team together in no time!
5. The A-TeamSo now you have your team together you are ready to change your projects status to '1: Pre-Bickering'. You will need to discuss your ideas with your team mates and see what value they can add to the project. You could use an Instant Messaging program like MSN for this, but since you run Linux you'll have to stick to e-mail.
Don't forget that YOU are in charge! If your team doesn't like the idea of giant robotic spiders just delete them from the project and move on. Someone else can fill their place and this is the beauty of Open Source development. The code might end up a bit messy and the graphics inconsistant - but it's still 'Free as in Speech'!
6. Getting Down To ItNow that you've found a team of right thinking people you're ready to start development. Be prepared for some delays though. Programming is a craft and can take years to learn. Your programmer may be a bit rusty but will probably be writing hello world programs after school in no time.
Closed Source games like Doom 3 use the graphics card to do all the hard stuff anyhow, so your programmer will just have to get the NVidia 'API' and it will be plain sailing! Giant robot spiders, here we come!
7. The OutcomeSo it's been a few years, you still have no files released or in CVS. Your programmer can't get enough time on the PC because his mother won't let him use it after 8pm. Your artist has run off with a Thai She-Male. Your project is still at '1: Pre-Bickering'...
Congratulations! You now have a successful Open Source project on Sourceforge! Pat yourself on the back, think up another idea and do it all again! See how simple it is?
If there are successful companies that rely on your Open Source Software (OSS) application, you can have a pretty good idea that it is successful (read: in the critical path of people's time and money).
To that point, many companies have based their entire business models upon open source software. This is a concept that has been around for quite a while (e.g. RedHat), but the evolution of this model is still in its infancy.
Open Source Business Models are changing the software world.
Example: IBM has been incredibly successful leveraging Linux, J2EE, Eclipse, and many other OSS Applications and Protocols, leaving them free to provide Support, Consulting, and Customisation (read: gigantic profit margins, something that Microsoft does not compete with)
Example: MySQL can compete with Oracle because developers from around the world both support and develop MySQL, leaving the company to provide Support and Consulting (ask NASA or Yahoo if MySQL is prime-time)
These companies, along with many others, are enjoying the success of leaving the burdon of the development, testing, documentation, etc., to others, while concentrating on other, higher value tasks. As new Open Source Business Models come to market, it will be harder for a company to develop proprietary software.
I own a small media and marketing technology company which has two employees. The competitors in my market space have well over 100 developers working on proprietary solutions. I can compete with these companies because I provide solutions that are quicker to market, bug-free, and scalable - thanks to Horizontal Applications like Linux, Apache, MySQL, PHP, and Vertical Applications like Open Source Survey Software, Data Warehouse Software, Pattern Matching Software, and others. My margins are greater than 30% while my competitors are losing money.
In the future, we will no longer pay for software, and only pay companies for higher added value solutions (including support, consulting, customisation, integration, project management, ASP services, etc.).
Specifically, when you see other projects you think of as being successful, including references to your project in their documentation. Even if it's telling users how to workaround your program and its, um, features.
It was a strange thrill to see ESD called out by name in the Quake (2?) for Linux documentation from Id software. I knew the project was onto something when Id deemed it necessary to warn people that my simple software audio mixer would interfere with the audio in Quake. They were expecting it to be enough of a problem to head it off in the official documentation. That's a user base.
If you have a program for Linux, inclusion in one or more major distributions is also a sure sign that lots of people are getting some use out of your program. If that many people are using your program, it may even outlive your ability to contribute to it...
How's my programming? Call 1-800-DEV-NULL
Put "Key developer on Samba" and you'll probably get the job.
Put "Key developer on [insert one of the countless projects that never released anything]" and you won't.
If all this should have a reason, we would be the last to know.
Buckminster fuller designed a radically different car that didn't get invested in, and (therefore) didn't sell.
When asked about why his car failed, Bucky responded by saying that he considered it a success as he didn't judge it in economic terms.
Success or failure strongly depends on what you are trying to succeed at.
So, first question, is your project trying to achieve:
- acceptance
- Profit!
- problem resolution
Once this is answered, then you can judge success by many different methods.
Never never never smoke crack before geometry class!
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.
... but that was just because I wasn't putting the little (tm) after "Java" on my website.
Ooh, I meant to say, Java(tm).
I mean, software for the Java(tm) platform.
Ah, whatever. It was actually a fairly friendly letter. I'll keep working until I really "arrive" and it's Microsoft or Adobe breaking down my door.
Or (more likely) Charlie Northrup's company of lawyers....
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
There was once "Managing a Successful Open Source
Software Project: FreeDOS as an Example" by Jim Hall but I can't find it any more.
The URL was http://www.freedos.org/jhall/photos/italy/latex/
You should read the 'White' paper (in the 'Blue, White, Red' serie) by Marc Fleury. Marc Fleurey is the leader of the JBoss projet, and he is making profit from service around the JBoss EJB server. In this paper he shares how his business works around a Free Software product.
You can tell you have a successful open source project when you start getting useful patches from other people. This is the main point to releasing your code as source. There are other measures of success, but they don't measure success as an open source project: if you're having fun, you have a successful hobby; if your itch is scratched, you have a successful project; if you got fan mail, you've got a successful published software project. To demonstrate success as a open source project, you need to get the expected benefit of releasing the source (as opposed to writing it, or releasing binaries).
Where would Wienerville be without my Fail it guy!
We seriously need a 1st post donkey here
The whole point of an open source project is the same as that of any other project: it's a goal-based activity, unique (as opposed to, say, on-going operational support; every Boston Marathon is 'unique' in that they don't all take place at the same time ;) ), and bounded by a finite time.
Sure, all those other aspects are useful measures, but if you want to know how the project is going, as opposed to how much fun it is, or how useful or 'good' it is, you must learn some basic project management skills.
The three main measures are time, cost and scope. Cost is generally less of an issue with FOSS. :) Time is where you can measure your progress. This is where you can do things like determine milestones, develop feature lists and so on, then during the project you have a standard to compare yourself to. Scope is the same. You may want to reduce the number of features to hit your (self-imposed) deadlines. You can always add more features in v1.1! The most important thing to do (if you're concerned about whether you're making progress is to plan first, before launching into code mode.
I always equivocate. Well, almost always.
Hi
A good way is to let users compare it to other similar software.
I have made a open source script which does that.
You can get it here.
Maybe not a sure sign of success, but a symptom of success would seem to be inclusion into a commercial distribution like RedHat or Suse. Then again, now that we have 5 or 6 CD's of "extras" that syptom might be multi layered based on if your app was included on one of the "Required" CD's or one of the "Optional/Extra" CD's.
(+1 Funny) only if I laugh out loud.
However, those are largely things we don't control. The controllable factors of success are more interesting to me. I guess it's because there are lessons on software engineering here. Cool projects can be run into the ground, and tiny niche projects can do well if they're well-run.
Hands down, the best nuts-n-bolts coverage I've ever seen on important issues to successfully developing open source is in a book by Karl Fogel, Open Source Development with CVS. Fogel's one of the developers behind CVS and it's planned successor, Subversion
The book is an interesting paradox: it has 1/2 the chapters GPL'ed. When I started working with CVS, they were useful enough that I bought our development team two copies of the book. Then I read the rest of it... and those are the chapters I'm talking about. Absolutely, they're the best summary of what it takes to successfully run a GPL-ish project. (Ironically, they've GPL'd the technical detail chapters and you have to buy the book to read the parts that talk about things critical to the success of an open source project).
Success is helped by things like doing lots of releases (seeing progress gets others to buy in, and not seeing progress leads to people quitting in frustration) and only adding features you need (let someone else add the features they need). There's a lot more here, but I'm not about to steal Fogel's thunder. Many of these are ideas that are effective in regular development, especially on custom coding projects within big companies.
The focus on GPL code is not the same as on shrinkwrapped products: you're not trying to add features just to add selling points. You're trying to get more people to use the project.
Opensource lacks leaders with vision like commercial companies have. It gets better but slowly. Mozilla/firebird , gcc are examples.
And I mean: really useful. Plus your application has to be of a quality that is only found in commercial applications. Then you have a combination in your hands that is attractive to an enormous amount of people: quality software that is useful for a cheap price: free. There are a lot of open source projects that do not meet one or more of these requirements and are therefor not succesful. A lot of developers think they have made a great tool, but do not understand that the tool they made is only useful to them because they understand it, i.e.: the quality is not up to par, and an average user will not be able to use it as it is ment, which will result in a request from the user for another tool which seems to do the same: the user will look elsewhere.
:) it wasn't ment to be released as a worldwide succes, and DemoGL was, but failed.
I've made 2 open source tools: DemoGL and LLBLGen. DemoGL was a library for win32 which let you develop OpenGL effects easily in C++. It was not that useful to a lot of people, since most people didn't need it and got things started with a few tutorials from NeHe. LLBLGen on the other hand is very succesful, it's a DAL generator for sqlserver/.NET/C#/VB.NET. The reason why it's so succesful (according to the vast amount of reactions I received from users) is that it's simple to use, yet does what the user wants and costs nothing. It comes with the source so if you want to adjust it you even can do that. (This is what I understand most users found about the tool).
The fun thing is: LLBLGen was a pet project, a project to learn C#
Never underestimate the relief of true separation of Religion and State.
It's successful if...
- It scratches the itch
- It's fun to do
- Other people like it
- Other people send in contributions!
- It makes you famous!!!
Other people being happy with your software, is just a bonus IMO.
With that attitude, how exactly is open-source software supposed to carve out a majority chunk of the desktop (or any) market? When people besides yourself being satisfied with your software is not a root goal, but a "bonus"?
The coolest voice ever.
If it has a gentoo ebuild~.
(I wonder if i'll get modded funny, insightful or troll)
2. Make them edible!
http://vibe4u.com/edible_underwear.html
But that's because nearly all the stuff developed on sourceforge I want is already available in my distro. I don't think I'm exactly Robinson Crusoe there, either.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Closing it.
while (project != success)
{
redefine success
}
it may be noticed as a success.
Here are some open source projects that I've been involved with. Fugu is a graphical wrapper for SFTP & SCP on Mac OS X. I consider it successful because many universities (my peer group) recommend it to their users. Also, one of our success "feathers" is the number of localizations that people have contributed: Spanish, Japanese, German, and Dutch.
:w
radmind is a combination filesystem integrity checker (tripwire) and manager in one package. Again, many (a couple hundred) universities use it. It's important to note that it's less important to me that other groups also use it. It's my peer group that interests me.
I'm also the original author of netatalk. I consider it a success for a couple of reasons. First, it's old. Second, I no longer work on it at all, but there's an active group that continues to make releases. Those are both success "feathers".
Finally, my group wrote the reference implementation of LDAP, and our software is the basis of openldap. The "feather" in this case is having been part of the group defining the LDAP standard, something that many vendors and many packages now use.
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
Yeah. And a lot of opensource is "useless featureless and slow" but people still find it useful for its purpose. Your point?
Java(TM) is developed by Sun Microsystems. It's hardly open source. In fact, it's developed by one of those commercial companies you attribute "vision" to.
Gnutella was also never open source. Despite its name, Nullsoft only managed to release a closed-source binary before AOL squelched it. The protocol and network themselves are dominated mostly by corporate interests right now.
OpenOffice is actually somewhat less bloaty than StarOffice, which was developed by what? a commercial corporation. In fact, pretty much the only one of your examples of open source failures that wasn't developed by a "commercial company with vision" is Mozilla, which is only heavily influenced by one of the biggest corporations in the world.
Seriously I am not running this for profit or any sort of monetary return. My goals are very simple:
- Remove one more reason for using Windows
- Learn more about v4l and working with Video and Audio on Linux
- Coolness
The last reason is essentially selfish, however I think it is one of the major reasons why anyone decides to do something open-source. It's just damn cool knowing that something you have written and built is actually out there being used, this is what people strive for. Well I do anyway.As a developer of an OSS project, my measure would be the number of bugs/RFE's reported per time. Many bugs _reported_ means that many people are kicking the tires on the stuff, and see enough worth in what you're doing to report shortcomings, rather than give up and look elsewhere. It also implies that your project is full-featured enough to have room for all those bugs, and therefore room for improvement in general, leading to future fun. ls, bin and cat are all widely used, but I daresay that there isn't much ongoing work on these tools these days. OSS coders code for fun, ego-boost or both, and a steady stream of bugs/RFE's being reported ensures that they will both be satisfied for a while to come.
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
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.
I think this is wrong.
I think that when a successful commercial application exists, open source projects have no business meddling unless that commercial application is failing to address market needs at a reasonable price.
The goal of open source should not be to destroy the commercial market for software.
Sure, sometimes an area is charging prices that are substantially too high for too long. The database community, I think did this, and I have no major concern about open source databases injuring the database community. But that's the exception. There are a dozen or two major products that are always cited in these debates because we all know them, but they are also anomalous exactly for the same reason. In most cases, commercial software companies are just barely getting by, already charging the minimum they can in order to attract a maximal audience, and anything you do to create downward pressure on their prices will just as likely sink them as cause them to respond with better pricing.
I'm all for free competition, but only among people who are really trying to account for the costs of production. Companies that are trying to sell their software are accounting for costs. Open software created by people with too much time on their hands or funding that does not have to be accounted for like to believe they have created a cheaper offering, but they haven't shown me that their cost was, in fact, lower. They've just shown they don't have to care about costs. And that not only means they may be very wrong in assessing a proper price point, but it also means they may not be able to sustain their involvement over the long term in the way a commercial company by its nature would have been willing to.
There are plenty of areas not served by computer science, and there is no need to pick one that already is. Doing so, and putting a commercial business out of business as a result, is nothing to be applauded or emulated. It is a failure of the paradigm and garners no respect from me.
Kent M Pitman
Philosopher, Technologist, Writer
My open source projects go nowhere because I spend all the spare time reading slashdot and never get started.
Just chill out, you stupid tard. Slashdot's like a computer game; screaming when you lose doesn't get you points.
I agree. Note that by definition proprietary software (what you mean by commercial; after all, free software may also be commercial) fails to address a vital market need: that of freedom. Thus, free software has plenty of business in every market.
Open software created by people with too much time on their hands or funding that does not have to be accounted for like to believe they have created a cheaper offering, but they haven't shown me that their cost was, in fact, lower. They've just shown they don't have to care about costs.
Ummm... That means that their costs are lower. If by harnessing the spare cycles of grad students and sysadmins one can write an app which may be given away, then one has lower costs.
Doing so, and putting a commercial business out of business as a result, is nothing to be applauded or emulated. It is a failure of the paradigm and garners no respect from me.
It's not the `failure of the paradigm'; it is the paradigm. Software should be free. The free software community wants to eliminate proprietary software. This necessarily means that producers of proprietary software will need to do honest work once more. C'est la vie.
They've just shown they don't have to care about costs.
Ummm... That means that their costs are lower. If by harnessing the spare cycles of grad students and sysadmins one can write an app which may be given away, then one has lower costs.
If I were funding such a university, I'd stop giving it money if I found it was giving out value rather than charging for it, while still coming to me and telling me how hungry it was for money.
But also, I rely on the capitalistic free market to weed out ways of doing things that cost too much. The problem is that this can weed out commercial offerings (no matter how reasonably priced, no matter what quality), but nothing in commerce can weed this out (no matter what its quality). As a consequence, I think, this has a corrosive effect not just on products but on commerce itself insofar as commerce is about 'the product'. This means that good products will either be killed or will never be made. Many (not all) free software advocates not only admit this, but take glee in it, as if this were the whole point. (Usually in the same conversation, Microsoft is mentioned, as if all companies were Microsoft. Meanwhile, Microsoft continues to exist and the many companies that are not Microsoft and never will be are being injured.)
I'm not concerned about their injury per se. I'm concerned about my injury as a consumer, not having access to the fine products these injured companies would have produced because the market has become inhospitable for people to earn an honest buck making and selling software.
Software should be free.
This is an interesting notiion of premise, but I don't agree. Do you agree that the world should have no secrets? No privacy? If information is always free, are you unable to receive information on condition of not sharing it? If so, you should declare this to your friends and employers so they know never to trust you with a secret. If there is the possibility of accepting information on condition of limited use, then software is no different.
This necessarily means that producers of proprietary software will need to do honest work once more.
Honest work? What is dishonest about the work they are doing?
Kent M Pitman
Philosopher, Technologist, Writer
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