Years ago, techies had different phrases to describe the explosive growth of computing software and networking. The “Unix development model” became “the Internet development model”, as software was deployed first and made to work in successive patches and iterations. It was exciting times — a “killer app” could launch a technology, especially if it supported the “network effect” (it was useful even if only a few people were using it, and only became more useful as more people took it up).
It seems to me that those phrases fail to do justice to the effort and ecosystem that allowed technologies like the Internet to take off and continue on a growth curve for decades.
As Open Source Software (OSS) is increasingly important to commercial endeavours, and companies worry about becoming heavily dependent on something that becomes abandonware, I’d like to offer three things to look for in technology/systems if you want to see them take off and last beyond initial specs.
- Pragmatic solution: “It”, whatever “it” might be, must provide a practical solution to a real problem for would-be adopters. It’s not a toy, it’s not a diversion, it isn’t simply beautiful. It solves a real problem that adopters recognize they have. And, there are practical ways to adopt it (e.g., free implementations).
- Engagement of user community: Adopters aren’t just consumers — there is a means for them to contribute to the solution’s onward development. This might be through open source, open standards, or a seriously engaged user community forum. Adopters’ articulations of needed refinements, and possible solutions, have to have a manifest impact on the future development of the technology. (This encourages a sense of ownership, real or otherwise, and it goes beyond the technology in question. Adopters will fight for its continued existence and growth).
- Coherence: It’s not enough that there’s simply somewhere for adopters to spout their requirements, or write and post updates randomly. There has to be some level of coherence in the development, or acceptance, of new contributions, and in raising awareness of new features. That might be top-down (Linux, in the early days), or bottom up (IETF, some OSS platforms), but it is likely governed by an ethos or philosophy that people can understand and subscribe to. (Otherwise, it all falls apart from in-fighting, large company sway, government argumentation). It’s always a delicate balance between keeping the acceptance cone wide to accept as many new ideas as possible, and ensuring focus, so that it doesn’t become too dilute or discouraging of new contributions
As illustrations — I give you the Internet’s technology, which is developed through open standards at the Internet Engineering Task Force (IETF), and the Apache Foundation, which has developed and fostered the pre-eminent http server through open source, for years.
And, as a contervailing example, contribution (engagement) is not just a “nice to have”, it’s necessary, in order to build and support the community around the effort. Simply taking OSS and running it to make a profit, without contributing back to the community, is a fast way to starve the community that brought it to you in the first place. (See, for example, https://www.geekwire.com/2018/open-source-companies-considering-closed-approach/ ).
Clearly, not everything needs to be developed using these guidelines. Only things that are going to scale beyond wildest expectations, and solve global problems. You know — the easy stuff 😉