At some point in the lifetime of an open-source project, having survived rewrites, deployments in hundreds of organisations, battle-testing… it becomes boring. The sheen goes off it, and people move on to the newer and shinier. When this happens, the number of maintainers drops off, releases slow down to a trickle, and issues or improvements that users would like to get addressed gather dust in long-forgotten JIRAs. Eventually the level of inactivity causes companies to move their platforms onto other better-supported tech, not because the older is no longer useful (the ultimate measure of worth in software), but because the lack of support becomes a risk.
Over time even companies that support open-source commercially are likely to feel this pressure from within, as the teams that work on the stalwart pieces of often highly-complex infrastructure move apart over time.
This is not specific to any one piece of software, but applies to entire categories of products. What happens off to the very right hand side of the Gartner Hype Cycle? Where does the curve of enlightenment lead to? What does the long end game of a successful product look like?
Perhaps what is needed is a rethink of the relationship between the users and the maintainers of a piece of OSS. Companies often will not go into production without some sort of commercial support, which forms a type of insurance. A subscription or a license is the equivalent of an insurance premium. Over time, the lack of a major production incident, causes them to question the value of that policy. This is a bit like thinking “I have been paying for maintenance of this bridge for 5 years, and it hasn’t once fallen down. What’s the point?”
From a commercial standpoint, once the custom starts to drop off and demand rises in other sectors, it makes commercial sense to ramp down the support on the older products and divert resources elsewhere. But this is only a rational conclusion if the purpose of your company is to maximise profit, rather than support its clients in the long term. Given that this by definition is how commercial companies work, perhaps the problem is the nature of the company itself.
I have been thinking about this area for some time, having recently read Wired Differently – the 50 year story of NISC, a company providing software to electricity providers. NISC is set up as a co-operative, a model typically applied in areas such as agriculture, but that has much wider applicability; there are nearly 7,000 co-ops in the UK – banks, retailers, funeral homes, accountancies…
Under this scheme, the co-operative behaves like any other commercial company, acquiring clients, selling services etc. The big difference is structural in that the shareholders are the staff and customers of the co-operative; clients take a stake in the company through membership. The purpose of the co-op is to principally serve its members as well as possible, while operating at a lower cost than would be possible for a commercial organisation. At the end of the year, the treatment of profits is voted upon democratically by members, to either reinvest or distribute back in accordance to usage of its services. The model works particularly well in industries where specialization and stability are the most highly sought after attributes.
Co-operatives fill a niche in the market by providing long term stability, to the specialists working in those areas, as well as members who rely on the co-op’s services as a key component of their infrastructures. The service would be the ongoing development of these pieces of infrastructure, support, as well as elements that would be impossible for a commercial entity to justify, such as components that proactive monitor the infrastructure and prevent service callouts.
Perhaps it is time to apply the co-operative model to open source; it seems a natural fit. A co-operative as a form of sharing the costs of maintenance; half-way between an external vendor and a dedicated in-house team.
You can read more about the mechanics of co-operatives at Co-operatives UK.