What Makes an Open Source Project Successful? 201
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."
Step 3! (Score:3, Funny)
Re:Step 3! (Score:4, Funny)
I heard it first as:
1. steal underpants
2. ?
3. profit!
What more is necessary? Just steal underpants!
Read "The Cathedral and the Bazaar" (Score:5, Informative)
Re:Read "The Cathedral and the Bazaar" (Score:4, Informative)
I consider my project, The Java X10 Project [homelinux.org], a success based on several factors:
First: I've had hundreds of downloads, and since I run this project on a Cable Modem connection, my ISP hasn't become unhappy
Second: I've had dozens of email's asking for support as well as asking how to contribute.
and Third and finally (I think this one is a very good indicator): There are other websites out there that link to my site.
Oh, and there's a fourth optional measure of success... more for bragging rights... my site is THE FIRST result when querying google with "Java X10".
All in all, it is a very small project, but I have tangibles that give me a sense of success. Will this ever reach the magnatude of Apache? Probably not, but gawd, I'd prefer it remain relatively small anyway where I can control it.
Ambition and Drive (Score:5, Insightful)
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.
Re:Ambition and Drive (Score:5, Interesting)
The real question is how do you determine if you are successful without having profits.
Its simple. Open source is scratching an itch, right? Is the itch scratched? If yes, then its a success. If it doesn't do what someone else wants, they can add it in, or ask you to do it.
Popularity != Success
Re:Ambition and Drive (Score:5, Insightful)
I just the success of the project by how satisfied I'm with it. This extends to huge projects like mozilla and apache too. As long as the developers themselves are satisfied with it, its a success. If there is a person who is unsatisfied, he can contribute code to fix/modify/enhance whatever feature (hence becoming a developer himself) and become satisfied too.
Other people being happy with your software, is just a bonus IMO.
I'm not saying its right or wrong, I'm just describing the way it is. It would also explain why OSS is often accused of being poorly documented, or difficult to use. The person who wrote it didn't really care for those things.
Non-inflammatory question follows (Score:2)
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"?
Re:Non-inflammatory question follows (Score:2)
Careful, you're making this political, and making a false assumption while you're at it. See, you assume that developers care one way or another whether or not open source "[carves] out a majority chunk of the desktop (or any) market". But, speaking for myself, I know I don't give a
Re:Non-inflammatory question follows (Score:2)
I wonder how widespread this view is. Because if it is common, then all this "Micro$oft" bashing is quite pointless. I mean, why ascribe to evil what can be explained by apathy?
Re:Non-inflammatory question follows (Score:2)
You're assuming that I (and others like me) dislike Microsoft because of their massive marketshare, and so I should do all I can to reduce said share. However, that isn't correct. If Microsoft had massive marketshare and got it because they played fair and produced a high-quality product that everyone could agree was worthy of i
Re:Non-inflammatory question follows (Score:2)
Hey, fair enough =)
Re:Ambition and Drive (Score:2)
I agree. With any project, you have to define some goals. It's usually a pretty good idea at that time to try and figure out how you'll know when those goals are met. I would imagine that most open source projects don't have goals like "develop a product that takes 40% of the market in genre X," (although some do) but instead have a goal more like "develop a product that does x, y and z." You could
Re:Ambition and Drive (Score:4, Insightful)
Me & bunch of friends started doing a game (well we talked a lot about it). It isn't done (after 1.5 yrs) because
- I am the only coder.
- there is no 'peer pressure' to work on it regularly.
- and after spending 10 hours at work in front of computer, I just don't feel like coding at home!
- the code is not ready to be released, and going through some design changes. So I am reluctant to invite any others to join.
once the 1.0 is ready, atleast I can release it and follow up with development.
slow and stead wins the race, or so they say.
LinuxLover
If the project works (Score:4, Informative)
Seems straightforward (Score:2, Insightful)
Are the users happy, overall?
Re:Seems straightforward (Score:3, Interesting)
Easy (Score:5, Insightful)
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.
Re:Easy (Score:2)
Any FreeBSD 2.x machine.. openbsd 2.x.. linux 1.x.x.x.x.x (ok, i added a few
meta-html, a foul foul language written by bash author was a huge failure. About 10 people used it, one person developed it, and it did things badly. Well, maybe the fact it gets used at all at some pointmakes it successful.
Who knows...
I suppose the logical answer is: (Score:5, Insightful)
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.
What makes an OSS project successful? (Score:5, Funny)
a win32 port.
Next question please.
Re:What makes an OSS project successful? (Score:4, Interesting)
Get ready for the troll mods, though. That's not the kind of truth that goes down well 'round here =)
Re:What makes an OSS project successful? (Score:2, Informative)
Re:What makes an OSS project successful? (Score:2, Insightful)
Re:What makes an OSS project successful? (Score:2)
DevNull Ogre made a valid point that when people choose to use an open source project on an OS which has so many commercial offerings competing
Re:What makes an OSS project successful? (Score:2)
True enough. Then there are those that use Windows by choice. Choice is important, right?
can't fix the inevitable problems that come with MS Windows
If you can suggest an alternative that involves Linux, I'm sure you'll make a lot of money. Until then however, computers will continue to be rather complex. But the less you're exposed to that complexity, the less technical you need to be. You can be technical and save the money, or you can spend t
Re:What makes an OSS project successful? (Score:2)
Now do me a really big favor and FOAD, mmkay?
Re:What makes an OSS project successful? (Score:2)
You're not giving Joe User enough credit, I think. People are smart enough to know what kind of OS they want, the same way they know which car they want. But they don't make that decision based on the quality of the virtual memory manager or how many file systems are shipping with it this week.
Forced is definitely the right word for them
Then I suppose it's OK if I deliver bottled water in a GMC truck and moan abou
Re:What makes an OSS project successful? (Score:2)
The people that I was talking about are ones who prefer Linux (or something like it) and use Windows because of factors outside their control. That doesn't make them bad or stupid (I'm one of them more often than I would like), but it does mean they have a familiarity with Unix-based open so
Re:What makes an OSS project successful? (Score:2)
For home users, that may be true. (Except the one that hasn't been used at all. I'll only give you that if he didn't use it as a Windows box either.) But only because Windows is already so entrenched. All the games and apps th
Re:What makes an OSS project successful? (Score:2)
You need to find someone who gives a flying fuck.
Re:What makes an OSS project successful? (Score:2)
And of course, there are a lot of Windows users out there.
I don't download from sourceforge much... (Score:2)
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.
Re:What makes an OSS project successful? (Score:4, Insightful)
a win32 port.
Re:What makes an OSS project successful? (Score:2)
Open source success (Score:4, Insightful)
"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?
Its successful if its useful to you (Score:3, Insightful)
Doing something people want, cheaper. (Score:5, Insightful)
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.
What counts as "cheaper" if you do no accounting? (Score:2)
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 pric
Re:What counts as "cheaper" if you do no accountin (Score:2)
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 the
Re:What counts as "cheaper" if you do no accountin (Score:2)
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 doi
Re:What counts as "cheaper" if you do no accountin (Score:2)
Re:What counts as "cheaper" if you do no accountin (Score:3, Insightful)
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 d
A successful software project (Score:2, Insightful)
Re:A successful software project (Score:2, Insightful)
Profit does not mean success (Score:4, Insightful)
milestones and traffic (Score:4, Interesting)
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.
How to tell that your OSS project is a success (Score:5, Funny)
Stallman demands that people call it GNU/[Foo]
Re:How to tell that your OSS project is a success (Score:3, Insightful)
Re:How to tell that your OSS project is a success (Score:2)
I'd say if you want acceptance into GNU, make it massively flexible, massively portable, and, most importantly, massive.
Re:How to tell that your OSS project is a success (Score:2)
Mailing List to measure success (Score:3, Interesting)
Re:Mailing List to measure success (Score:2)
Most of the the stuff that I develop is heavily bent towards usability/ease of use. A mailing list full of people having trouble is not a great sign of sucess from my point of view... But thank you emails on the other hand...
--
Simon
It should be... (Score:3, Interesting)
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!!!
By feedback (Score:5, Insightful)
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.
Re:By feedback (Score:3, Interesting)
Success (Score:3, Insightful)
what I do (Score:3, Interesting)
Of course this leaves out win32 users who just download the binary, but oh well.
Re:what I do (Score:2)
Is this a good idea? Does the other 50% manage to compile without help or simply throw their hands up and move somewhere else?
Re:what I do (Score:2)
Your project is successful if... (Score:5, Funny)
Re:Your project is successful if... (Score:2)
Users (Score:2, Insightful)
Open Source Success. (Score:2)
Its the charisma (Score:5, Insightful)
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.
Simple (Score:3, Interesting)
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.
What Linus said... (Score:5, Insightful)
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?
Re:What Linus said... (Score:2, Insightful)
someone *other* than the project creator takes over the maintenance/leadership of the project. It *must* be fun/love/etc if it gets to this stage, right?
h.
Success with Open Source (Score:3, Interesting)
Fun (Score:5, Interesting)
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. [mail-archive.com]
The important gateing factors... (Score:5, Insightful)
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
Re:The important gateing factors... (Score:2)
Cheers,
Costyn.
Well, it depends (Score:5, Insightful)
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.
A very hard question (Score:3, Insightful)
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.
Success means... (Score:3, Funny)
It's all downhill from there.
one point of view (Score:2)
Does something useful (Score:2)
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.
I notice (Score:4, Insightful)
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.
Goals (Score:2)
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 w
Win friends and influence people (Score:4, Interesting)
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.
Tolerance for forks, tolerable forks (Score:4, Insightful)
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.
easy (Score:2)
What makes an Open Source Project a Success... (Score:2)
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.
Plug early and often... (Score:2)
Click me! Click me! [sourceforge.net]
When other projects mention you in FAQs... (Score:4, Interesting)
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...
The resume test (Score:3)
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.
Re:The resume test (Score:2)
I tried this and it didn't help at all!
Bucky Fuller's Car (Score:2)
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.
I think that most open source is unsuccessful (Score:3, Insightful)
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.
When you don't have to do all the work any more (Score:3)
Use an eigenpoll. (Score:2)
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 [all-technology.com].
How bought this (Score:2)
Fogel's CVS book covers this (Score:4, Informative)
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 [red-bean.com], Open Source Development with CVS [red-bean.com]. Fogel's one of the developers behind CVS [cvshome.org] and it's planned successor, Subversion [tigris.org]
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.
Re:Fogel's CVS book covers this (Score:2)
There. 'Nuff said.
As for the correct reading of this question about success, everyone else has said it well. All I can add is a quote: "if you're not having fun, you're probably not doing it right..."
It has to be useful to others (Score:2)
Itch --- fun --- fame! (Score:2, Interesting)
- It scratches the itch
- It's fun to do
- Other people like it
- Other people send in contributions!
- It makes you famous!!!
One Thing Missing... (Score:2, Insightful)
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
Proposed metric (Score:2)
Not reading slashdot - but getting on with it. (Score:2)
Re:Web related things easier to judge (Score:2)