Thursday, 13 December 2007

OSM: a FLOSS Success Story vs. Failure

Success of Moodle

"In academia land, one of the more popular forms of open-source is the system known as Moodle. London, UK-based The Open University is currently in the midst of implementing Moodle to the end result of “the largest use of Moodle in the world,” namely a complete student online environment. Moodle is currently employed in some aspects of Open’s distance-learning program and the “comprehensive online student learning environment” promises to be fully operational by February."

"Meanwhile, the University of Illinois at Urbana-Champaign College of Education has now in place a full-on “Moodle Service”, which acts as supplement to course material available to College of Education faculty and students and a resource to other university workgroups, workshop participants and communities."
Source

The Open Source Fiasko

"Hugger-Mugger Yoga Products is a $5 million supplier of yoga-related products such as clothes, yoga mats, and so on. After struggling with a variety of individual software products that did not integrate well, the company decided to implement open source ERP package Compiere. This package was chosen on basis of low-cost and because it includes modules that Hugger-Mugger specifically required."

Enterprise software implementations are complex — jobs can change, processes across an organization can be affected, and great care and feeding is required to be successful. This situation offers a classic study in how an IT initiative can move forward under its own steam, without sufficient reference back to what users actually need. In addition, it can be tempting to think that open source means cheap and easy, which is not necessarily the case. As someone wise once said, “Don’t let this happen to you!”"
Source

How to Make it Work?

1. Open source development is not business

Open source development succeeds or fails irrespective of the businesses that are directly associated with them. The constructive exploration of sustainability with respect to open source software development depends upon it.

2. Projects and open source development

An open source software development project can only ever be a singular instance of many possible developments of the code. It cannot be equated with the development of the code itself.

3. Projects or open source development?

The sustainability of an open source software development path is effectively beyond the capacity of analysis by case study or example.

4. Criterion of project success

Either the project retains the trust and good will of the open source community and thus remains the lead on the development path of the software or it does not. If no one is willing to invoke the option of the code-fork, then the project must be considered a success. An open source software development project which has no user or developer base will be successful by default. The worst that can be said about such a technically successful project is that it is uninteresting. By contrast a project with an extremely active development community will be at greater risk of failure using the above criterion. It will, correspondingly, also be of greater interest. Another potential limitation on this criterion of success is the very diversity of project types that may be found in open source software development.

5. All successful projects fail

A successful reference implementation project may advance the software development path even if some other project arises which carries the software beyond the reference implementation stage.

6. The success of failure

very successful open source software development project will eventually fail. Remember, it fails when some other project takes on the lead in the development path. Any project that holds the lead in an open source software development path is by definition successful.

7. Preparing for the success of failure

The test for any successful project is whether or not it stands at one point along an ongoing development path. If the project comes to an end and there is no continuance, no new project that will carry the code development further, then that software development path has truly ended. If it is the software development path itself that concerns us, then anything that assists that onward movement will be a benefit. For example, supplying sufficient comment within the code itself in order to make it easy to read by others increases the likelihood that someone else will take the code further. Structuring the code into comprehensible units is another way of honoring the code.

Source of the list

"The marker of success in an open source business is the same as that in any business: profit or loss. An open source software development project is not a business. Indeed, even when a single business lies behind the majority of the development work, I would argue that the software development project is still not itself a business. What counts as the marker of success for open source software development projects must therefore be something else."
Source

"The criterion of project success is whether or not it retains the trust and good will of the open source community and thus remains the lead on the development path of the software. Since no project is likely to sustain the lead on development forever, any successful open source software development project must encounter its own failure. The successful preparation for failure and transition of the software development lead marks an even greater success for an open source software development project."
Source


OSS Watch

Unlocking The Secrets of Open Source Success

The Secret of Successful Open Source Companies

The Myth of Open Source

The Success of Open Source

No comments: