Is open-source truly open?
Software tools vs services
It’s fascinating when material world circumstances spill out into the virtual world. For example, we continue referencing our bank branch number because in the pre-computer era it was crucial to specify in which branch our paper documents were stored.
It is even more peculiar when the material-world restrictions surface in software more apparently than in physical reality. For example, I pay the store to buy a microwave, then at home I plug it in and pay the power company. The microwave is a commodity and I own it. The electricity is provided as a service. Similarly, the cellphone: I can buy a device (the commodity) and choose a mobile provider I connect it with (the service).
This distinction between commodity and service is fairly clear in the material world, but not so much in the world of software. More often than not, the “tool” (i.e., commodity) and the “service”1 are marketed as a hybrid, presumably for the sake of simplicity. But in reality, the entanglement of tools and services, the lack of granularity, is what enables monopolies, constrains users’ free choices of providers, and ultimately forces customer lock-ins.
The constrained choice and lock-ins are increasingly unfortunate and flawed when it comes to open-source. Over the years, the open-source software grew from enthusiast to mainstream culture, and yet in the past couple of weeks I stumbled upon a few articles2 describing license updates by open source projects aimed at converting users to paying customers. Some authors present this strategy as a viable business model.
In my opinion, this approach undermines the open-source concept overall. As an open-source community member myself, it is my responsibility to make sure this won’t happen with XenonJs:
All XenonJs code components have no dependencies. They can stand on their own and are runnable outside the XenonJs framework.
XenonJs experiences are composed from components. Some components are “commodity” (e.g., business logic or UI), some are “services” (e.g., storage, or access to LLMs). All components are interoperable and hence interchangeable, meaning the user can easily switch between service providers without affecting the rest of the experience.
Independently from the personal qualities of XenonJs authors, due to the very nature of its architecture, XenonJs is open, flexible and unequipped for lock-in.
I’m referencing the distinction between “services and “tools” described in the platforms’ bible by Alex Komoroske: komoroske.com/gardening-platforms