What factors determine the success of an open source project?

Question

We have a series of closed source applications and libraries for which we believe it makes sense to open source.

What has blocked us so far is the effort needed to clear the code base and document the source before it opens.

We want to open the source only if we have reasonable chances for successful implementation of projects, i.e. with the participation of participants. We are convinced that the code will be interesting for a large base of developers.

What factors, excluding the "interesting" and "usefulness" of the project, determine the success of an open source project?

Examples:

• Code cleanliness
• Having comments on the source code
• Fully or partially documented APIs
• License selection (GPL vs LGPL vs BSD, etc.)
• Select shared storage
• Investing in a public website

Answer 1

There are several things that dominate code success. All this should be achieved for the slightest probability of adoption.

• Market. There must be a market for your open source project. If your project is an orange juicer in space, I doubt that you will be very successful. You need to make sure that your project is highly recognized among users and developers. This is twice as likely to succeed if you can force other corporations to accept it as well.
• Documentation. When you dealt with earlier documentation, this is the key. This documentation includes comment code, architecture, and API notes. Even if your documentation contains errors or errors in your software, everything is in order. Remember that transparency is key.
• Liberty. You must allow your code to be “free” - by this I mean free, as in speech, not as in beer. If you have the feeling that your market is a library for other corporations, the BSD license is optimal. If your piece of software runs on desktop computers, then the GPL is your choice.
• Transparency - You must write software in a transparent environment. When you go open source, there are no hidden secrets. You must explain everything that you do and what you do. It will hide developers like no other
• Developer Community - Requires a strong developer community. It should be. Only about 5% of users contribute to the project. If someone notices that there were no releases during the year, they won’t think: “Wow, this piece of software is not done,” they will think that “developers should reset it.” Keep developers on it, even if it means they cost you money.
• Communication You must be sure that the community can communicate. They should be able to log errors, discuss workarounds, and publish corrections. Without feedback, it makes no sense to open a project
• Accessibility - make your code easily accessible, even if it means that you wrote lawyers. You need to make sure your project is easy to download and use. You do not want the user to jump over 18 nag screens and sign a contract to do this. You have to make things simple and clean.

Answer 2

I believe that the most important factor is the number of users who use your project. Otherwise, it's just a very well-written, useful and well-documented group of things that sits on the server, not very many ...

Answer 3

To get contributors, you first need users, then you need some incompleteness. You need to call "It's cool, but I really want it to have or have it differently." If you lack an obvious function, it is very likely that the user will become a contributor to add it.

Answer 4

Most importantly, the program should be good. If this is not good, no one will use it. You cannot hope that the chicken and the egg will be canceled and people will take it for granted until it becomes good.

Of course, “good” simply means “better than any other practical option for a significant number of people”, this does not mean that it is strictly the best, only that it has some functions that make it, for many people, better than other options. Sometimes a program has no equivalent anywhere, and in this case there are almost no requirements in this regard.

When a program is good, people will use it. Obviously, it should have a market among users - a good program that does something that no one wants, is not very good no matter how well designed it is. One could talk about marketing, but really good products, up to a point, tend to market. It is much more difficult to promote something bad, so clearly the product itself, and not the promotion of the product, should be one of the first priorities.

The real question then is how do you do it well? And the answer is a dedicated, experienced development team. One person rarely can create a good product on their own; even if they are much better than other developers, several perspectives have an incredibly beneficial impact on the project. That's why corporate sponsors are so helpful - it puts other developers (from the corporation) minds on the problem to give their own opinion. This is especially useful if program development requires significant knowledge that is not usually available in the community.

Of course, I say this all from experience. I am one of the main developers on x264 (currently the most active), one of the most popular video encoders. We have two main developers, various small community developers who provide patches and corporate sponsorship from Joost (Gabriel Bouvigne, which supports speed control algorithms), from Avail Media (who I sometimes work on contract and who currently hire coders for contract to add support for interlaced scanning MBAFF) and from several others that appear from time to time.

One good developer does not do a project - many good developers do. And the end result of this is a program that encodes video faster and has much better quality than most commercial competitors, hardware or software, even those with extremely huge development budgets.

Answer 5

When considering these issues, you might be interested in checking the online version of the open source course at UC Berkeley called Open Source Development and dissemination of digital information: technical, economic, social and legal perspectives. Its co-teacher Mitch Kapoor (founder of the lotus) and Paula Samuelson, professor of law school. Last year I had a long dial-up access, and I put the audio course on my iPod - they talk a lot about what works, what is wrong and why, from a very broad (albeit obviously academic) perspective.

Answer 6

Books have been written on this subject. In fact, you can find a free book here: creating open source software

Answer 7

Indeed, I think the answer is: "How do you launch a project."

All your examples matter, yes, but the main thing is how the interaction between developers is controlled, how corrections are processed and accepted, etc., who “answers” ​​and how they cope with this responsibility, and so on and so forth. .

Comparison and contrast (history is hard to trace!) Perl. :: DBI and DBIx :: Class class development management.

Answer 8

I just read an excellent post today about the usability aspect of successful and unsuccessful open source projects.

Excerpts:

Most of the bandwidth was wasted due to lack of usability in open source / free software (hereinafter - OSS). The discussion continues at this point on Slashdot's blogs, forums, and comment threads. Some say that poor usability is endemic to the whole world of OSS, while others say that the usability of OSS is great, but the real problem is the closed users who expect each program to clone Microsoft. Some people argue that UI issues are temporary growing pains, while others say that the OSS development model systematically creates a bad interface. Some people even claim that the GPL indirectly rewards software that is hard to use! (For the record, I do not agree.)

http://humanized.com/weblog/2007/10/05/make_oss_humane/

Answer 9

Just open source. Most likely, no one will begin to contribute. But at least you can write in press releases that your product is GPL or something else.

The first step is that people start using it ...
And maybe after users become convenient, they will begin to participate.

Answer 10

All answers have been good so far, but there is one thing missing and that is good supervision. Nothing kills an open source project faster than the lack of any project management. Do not tell people what to do to simply add structure and tasks for the developers you hope to attract.

Unorganized projects are falling apart quickly. This is not a bird that you just let go and watch it fly away.