Just because you can, doesn't mean you should. It's a simple lesson, one learned by most of us by the time we're twenty (OK, fifty). But it's lost on some very high profile open source efforts, which seem increasingly to think that the workers of the world don't deserve the benefits of decent software. If something can be changed, it should — and that's a fatal approach for enterprise IT.
It's not that open source software can't do enterprise-quality jobs: obviously, it can and it does. But the dynamics of managing the workplace IT environment are just as important as the capabilities of the technology within: if you can't support something, it's too dangerous to use.
For the enterprise, stability is the cornerstone of support. With each product, you learn how to secure it, your users learn how to use it, you make it part of your systems and you trust it as a component around which you build your digital working life. Something that changes a lot - or even a little - resets the whole process when you should be thinking about something else.
So why is stability a dirty word in some open source circles? Mozilla, for so long the movie star in open source's fight back against the dominance of the closed, is openly disdainful of enterprise's need for something they can fit and forget. Not something it wants to think about, says Mozilla. The consumer is king, and the consumer loves shiny and new. The roadmap — something else enterprises love, because it's actually useful — consists of "Make it better" followed by "Make it more betterer". Thanks for that.
Canonical, too, is febrile in its approach to user contentment. Although its programme of LTS — Long Term Support — editions of Ubuntu is welcome, with guaranteed support for three to five years, it has got into the habit of making such fundamental revisions to its mainstream releases that moving on at the end of an LTS period becomes a dangerously radical experience.
Open source software designed for enterprise would look rather different. There are areas where rapid change must be possible: security, for example. Other areas need a different dynamic: drivers, protocols, package integration, all need to have the ability for change outside the major upgrade cycle. But user experience should be stable. Change should come through business need, not developer foible.
That calls for a different kind of lifecycle engineering altogether, one where the modularisation of components within a product is consciously aimed at easing the long-term support issues, and one where tools are created to explicitly deal with the contradictions of needing to evolve over time without losing the advantages of stability, familiarity and tested code.
Such an approach may not suit the revolutionaries who hate to leave a good thing alone. But it is in the nature of open source that it doesn't have to - if three or four major enterprises decided to get together to create their own distribution that precisely met their needs, they could. There is any number of solid, well-featured starting points they could adopt.
Open source isn't code and it isn't a catalogue of solutions: it's a way of thinking that gives the willing the ability to solve their problems in their own way. Enterprise deserves the best of that, and it's there for the taking.