A question of maturity

Posted: September 15th, 2009 | Author: Stephen | Filed under: Ecosystems, Open Source | Tags: Maturity | No Comments »

Open Source Maturity
In yesterday’s post, I talked about some of the drivers and benefits of open source adoption for organizations. However it is important for any organization to do their due diligence before deciding to use or contribute to an OSS project. Like any other investment it is important to have a good idea there will be a return on that investment and that the time to profitability is acceptable for your organization. Immature projects may be gone tomorrow, while mature projects may have support plans that rival the cost of commercial offerings.

It is important to ensure the project is mature enough for consumption or contribution by your organization. Open source maturity is defined differently by different sources but it boils down to the stability, reliability and community a project has.

Immature projects
Immature (new) projects will have a smaller, less active community – there will be fewer developers, testers and end-users. The application itself may not be feature complete and will almost surely have a large number of defects, leading to lower reliability. At this stage an evangelist organization can easily become a large contributor to the project and help shape the vision and direction, but the risk that the project will not succeed is still high at this point. Immature projects are usually not suitable for consumption, especially for core processes or applications; this is not always the case however and should be decided on an independent basis.

Maturing projects
Maturing projects tend to have a larger community of developers and the community is often very active. There are lots of releases and bug fixes happening at this time. If the project is succeeding there will be an increasing number of end-users who are also acting as testers, reporting problems and defects. At this stage the reliability of the project increases rapidly. In order to gain a large stake in a project at this point an organization needs to invest a lot of resources, since the community is already beginning to thrive without them. However, with a growing community, the success of the project is more likely to judge so this may be a safer time to invest in the project. From a consumption standpoint this may be a good time to begin testing the project in an organization’s core processes. The project is probably safe to use for non-core activities and processes.

Reliability, Developers & Risk vs. Maturity

Mature projects
Mature projects will have a stable community of developers and a large and growing end-user base. At this point, the project is stable, there are few defects and the releases are incremental. Project managers will be weary of risky changes or additions that will alienate them from their core users. Gaining a large share of the decision making process at this point is usually very difficult. The core developers are a tight-knit group who will be unlikely to need a lot of outside management or resources at this point in the lifecycle. Consumption during this stage is probably safe for even core processes, the investment will likely be worth while.

Ecosystems and maturity
If you are an organization that has a visionary stake in an open source project, it is important to project the project’s maturity to potential users and developers so that they are comfortable contributing to or using it. Ecosystems also tie in to open source maturity in two ways: the first is that a healthy ecosystem built around an open source project will dispel potential consumer’s fears. There is a visible, vibrant community that is known to support, maintain and offer complementary applications and processes. The second is that a burgeoning ecosystem tends to be highly productive leading to rapid maturity increases as many new developers and users enter the fray.

Further reading