Slashdot Mirror


Ask Slashdot: What Defines Success In an Open Source Project?

rbowen writes "Nine years ago, Slashdot readers discussed what makes an Open Source project successful. The answers were varied, of course. An academic paper summarized the results, agreeing (albeit with more precision) that motivations for Open Source projects are varied. Has anything changed since then? In the era of mobile apps, social media, and Google Ad revenue, have the definitions of Open Source project success changed at all? Have your reasons changed for being involved in Open Source?"

4 of 88 comments (clear)

  1. Score by Anonymous Coward · · Score: 5, Funny

    Your project is a success when a corporation embeds it in their product and violates the GPL.

  2. Usage by recoiledsnake · · Score: 5, Insightful

    I think widespread usage is a good metric and not just gloating over profit like the Apple fans like to do. "Apple derived the most profit from the cell phone industry." they say, to put down Android's usage gains. By that metric, IIS is totally killing Apache and Nginx in the web server space, but most folks consider Apache beats IIS. Which of this is true?

    --
    This space for rent.
  3. What is best in life? by binarylarry · · Score: 5, Funny

    I believe RMS said it best when he declared the following metrics required for FOSS project success:

    1) To crush your enemies
    2) To see them driven before you
    3) To hear the lamentation of their women

    For a good example of this, check out how Android has dominated Window Phone 7 and how their womenfolk continually spam Slashdot with first posts about their crushed dreams.

    --
    Mod me down, my New Earth Global Warmingist friends!
  4. Lots of things you can look at by dkleinsc · · Score: 5, Insightful

    1. Did it solve the original problem it was intended to solve?
    2. How many other people had their problem solved by it? (usage stats, as much as possible)
    3. How many other people were motivated to improve it? (got involved as developers, testers, documenters, etc)
    4. Did it reach a point where it was so darned useful and bug-free that nobody really needed to think seriously about the problem ever again? (e.g. GNU's "bc" utility, which hasn't changed since 2000, and does its job beautifully)

    The ultimately successful open source project goes through a lifecycle of something like:
    1. solve an immediate problem
    2. get developers, testers, documenters involved solving the problem in a wider context
    3. solve the problem for a whole lot of users
    4. nobody thinks any more work is needed

    --
    I am officially gone from /. Long live http://www.soylentnews.com/