The Open Source Ethos: Why Lens Made a Mistake

With the release of Lens 6, the underlying open source project was repurposed, breaking an unwritten rule for open source projects.

Feb 17th, 2023 2:38pm by Sergio Ocon-Cardenas

Featued image for: The Open Source Ethos: Why Lens Made a Mistake

“Every good work of software starts by scratching a developer’s personal itch” — The Cathedral and the Bazaar, Eric Steven Raymond

In 1997, the concept of open source was often associated with individual “hackers” who were both developing and using a particular project and had a strong personal interest in its evolution and improvement. This was particularly evident in the successful open source projects of that time, some of them still being widely used like Linux and Apache.

Fast forward to today, and open source has become mainstream, in particular in the container space. The latest Octoverse report by GitHub reveals that 90% of companies use open source software. The growth and success of open source companies is also remarkable, with companies like Red Hat experiencing a 15% quarter-over-quarter growth and generating over $1 billion in revenue from OpenShift alone. But there are now more than 10 unicorns in the open source space (Grafana, Redis Labs, Anyscale, etc.)

Many of the largest open source projects are now backed by commercial organizations, making them a popular choice for first-time open source contributors. Projects such as VS Code, Kubernetes, Android, Ansible and Terraform, among others, are all examples of how companies can effectively contribute to open source and develop successful business models.

Why is that? The Free Software Foundation defines free software as the freedom to run, edit, contribute to and share software (open source is a term with slightly different meaning but related). It is possible and ethical to put a price on free software, knowing that there’s always the option for others to circumvent commercial efforts by creating a competitor or a copy (fork) with your own original code, and the code is available, so quick and dirty is dirty and public. Does it then make sense to create open source projects? Yes, it does!.

There are many good reasons to create open source software: Open source software provides companies with access to a larger user base and the opportunity for more collaboration, resulting in better user feedback. With the code available to all and the open source community being more involved, it’s easier to produce more secure and stable software. The large community also provides free feedback and testing, which is invaluable for small companies, and sometimes even contributes code or ideas to improve the software.

Finally, open sourcing software can drive adoption for paid services or software built on top of the software. Even if the majority of the users are free riders, the system as a whole benefits from those users, as some of them will contribute back, some with code, but also reporting bugs, suggesting and requesting enhancements and new features, or complaining about a function that could be better implemented.

However, balancing openness and a commercial model requires some adjustment to the business model and some companies struggle to reach it.

Recently, the internet was buzzing about the changes to the license for Lens, a popular tool for inspecting and troubleshooting Kubernetes clusters and applications

Recently, for example, the internet was buzzing about the changes to the license for Lens, a popular tool for inspecting and troubleshooting Kubernetes clusters and applications, which was acquired by Mirantis in 2020.

With the release of Lens 6, the underlying open source project was repurposed, breaking an unwritten rule for open source projects. The new end-user license agreement (EULA) for Lens requires sign-in and payment for organizations with more than $10 million in annual revenue, forcing the user to create an account even when payment is not needed.

Users that previously were not required to pay suddenly were asked for payment under the new EULA, and as there is no prepackaged build of the tool, most of them will be forced to use the free license and give up their data. If you didn’t like it, you could still use the open source version and compile it yourself, but it was no longer an opt-in if you liked the advanced features, but an obligation.

To make things worse, Mirantis deleted some of the core features from the underlying OpenLens project and kept them only under Lens, the commercial product. There could be some business sense in trying to capitalize better on their investment, but some of the changes crossed the line reducing the value of the open source project to benefit the commercial offering. Suddenly, the next open source version was less useful than the previous one because of a commercial decision (not a technical one) outside of the community, and any user is required to manually modify the code to get back logs, terminal and other missing features.

In open source, trust and transparency are a key indicator of health.

Yes, there are ways to get those features back through extensions, but any developer that has participated in development will feel treated unfairly, even more when the open source product is not provided as an easy-to-use package, only as code.

In open source, trust and transparency are a key indicator of health. So the question arises: Is this the first change of many? Is it safe to continue investing in a product that changes in that way? There are many examples where a change of license to avoid competitor products has led to a fork in code under the old license, and the community moving away from the original product (like LibreOffice).

So, please, if you are responsible for maintaining or contributing to an open source project:

DO adhere to the principles and values of the open source community.
DO differentiate the open source project from the commercial version, and don’t change the project just to benefit the product.
DO be transparent about what you are doing and why you are doing it. Don’t let people discover a feature was dropped without any reason why.
DON’T ask for unnecessary information from users, like sign-ins, to use the product.
If you use telemetry to understand how to improve the product, DO make it easy to be disabled.
DO treat your contributors fairly. Recognize that contributions come with concomitant rights, like not dropping useful features.
DO provide clear guidelines and license information for use and reuse of the project.
Be professional

How We Do it at Kubeshop

Kubeshop is an accelerator for open source projects in the cloud native space, and of course we want to make some money out of it. We are a group of open source enthusiasts, and we want to make sure that the results are good for the users, the community and the developers too.

One of our projects, Monokle, streamlines the process of creating, analyzing and deploying Kubernetes configurations by providing a unified visual tool for authoring YAML manifests, validating policies and managing live clusters. We have split the project into a suite of separate components that can be used in isolation or together depending on your use cases: Monokle Desktop, Monokle CLI and Monokle Cloud.

As we evolve and release Monokle, we strive to be transparent and clear about our commitments. The Desktop version will always be available as open source, along with the core libraries and functionality in the CLI. Additionally, we are providing a SaaS tool (Monokle Cloud) that is more convenient for teams working with GitOps, and that uses the core components of the open source project to create a distinct solution to the market. It is not open source, but contributes back to the open source components while being independent of it.

You have a clear understanding of where the contributions are going, and you can and will always be able to use the open source components at the extent of the MIT license. There is no pay upgrade for the open source version, but instead a different tool, so everything is crystal clear to everybody.

We think that is the way to respect our users and the MIT open source license while still being able to create valuable opt-in solutions for companies. We need to earn some money if we want to continue paying our developers, and in turn, create the best tool in the market.

Give us a chance and use any of the tools. You can reach us in our Discord, and you can open an issue directly in our GitHub. We want to hear your feedback!

Links:

Sergio Ocon-Cardenas is product manager for Monokle at Kubeshop. He has been working in the cloud ecosystem for the past 10 years. He provides a broad point of view from his experience in a variety of positions in the industry including...