paint-brush
Scaling an Open Source Project: a Startup Success Storyby@eionel
160 reads

Scaling an Open Source Project: a Startup Success Story

by EionelFebruary 10th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Lens — The Kubernetes Platform as an open source project launched 16 months ago. It has been adopted by some of the largest companies across the globe and is seeing over 15% month-over-month growth. The goal is to eliminate complexity and increase productivity with the cloud-native platform. The project is one of the top trending open source projects within the cloud native ecosystem. It is now February 2022, 16 months after launching Lens, it has over 500,000 active users and over 17,000 GitHub stargazers.

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Scaling an Open Source Project: a Startup Success Story
Eionel HackerNoon profile picture

It is now February 2022, 16 months after launching Lens — The Kubernetes Platform as an open source project. How has the project come so far in such a short time?

Lens was built to help developers, operators, and site reliability engineers take control of their Kubernetes clusters like they never imagined. Today, Lens has over 500,000 active users and over 17,000 GitHub stargazers. As a growing community, Lens has become one of the top trending open source projects within the cloud-native ecosystem. It has been adopted by some of the largest companies across the globe and is seeing over 15% month-over-month growth.

Growing an open source technology can be challenging for many reasons, from user adoption to building trust within the community, and of course, overall product retention. In this post, I’ll break down the tips and tricks we have used to ensure our open source project’s success within the cloud-native ecosystem.

Step One: Understanding the Challenges

As Kubernetes users, we understood that Kubernetes has many underlying challenges that individuals and organizations need to overcome for their application modernization initiatives to be successful. Managing Kubernetes means writing code and keeping track of multiple Kubernetes YAML files and sets of access details. Keeping track of all of this information and all of these resources becomes especially challenging when working with dozens of Kubernetes clusters.

We identified several underlying challenges when it comes to Kubernetes, including:

  1. The technology can be complicated and a burden to learn.
  2. Understanding the root cause of errors is increasingly challenging.
  3. Individuals / Organizations spend too much time helping users onboard their applications.
  4. Users spend too much time switching between browsers, command lines, and documentation.

These issues are only the tip of the iceberg, but for the purposes of this blog, I want to emphasize that when you are trying to create something truly extraordinary you must sell the problem you solve, not the product…and before you can do that, you need to have a clear understanding of what that problem is. Once you’ve identified the problem space, you can move on to the next step, which is identifying the value you bring.

Step Two: Understand Your Product’s Value Prop

As you begin your journey in building an extraordinary product, software, or technology, you need to understand the value prop that you are providing to your end-users or customers. Based on the challenges you have identified, this is where you begin to think of the solution to these challenges. So how do you begin?

One great advantage we have in building an open source project that provides value is simply being an end-user. What exactly do I mean by that? Well, it’s quite simple: the majority of individuals who are building an open source project are most likely already experts in the topic at hand.

With Lens, most of our engineers and developers already work with Kubernetes on a daily basis, easily identifying the challenges. Lens made their lives easier. Your team themselves should benefit from the open source project you build. If your team cannot benefit from the project, there is a strong possibility your targeted audience won’t either.

One feature we implemented for Lens is product telemetry. In our license agreement and source code, we ensure that we are able to collect anonymous user telemetry data that provides insights and highlights our user journey (while giving users the option to opt-out, of course). We leveraged this telemetry data to better understand our user usage patterns, aggregating and analyzing this data to make product roadmap decisions, improvements and to understand why and how our users leverage Lens. Real-time telemetry is by far the most influential data we could leverage; the hard part is digesting and analyzing it appropriately.

We also took the opportunity to incorporate real-time surveys that our users can fill out to give us a better understanding of how to position our roadmap moving forward. Leveraging both our telemetry and real-time surveys gave us a clear understanding of how our users are leveraging our technology and how we can improve our product.

The main point I want to make here is that it is never easy to identify the true value your product brings to its end users, but there are several channels that you can explore to better understand how your users leverage your product. When building your product, it is essential to implement telemetry to identify the usage patterns of your users.

Step Three: Build a Product That Resonates with All End-Users

When it comes to adoption, not much has changed. We know that we need to build a tool that is explicitly geared towards our end users. Our audience, specifically developers, operators, and site reliability engineers, all have one thing in common. They want to improve their overall efficiency, when working with Kubernetes. The goal is to eliminate complexity and increase productivity.

Every one of our “potential” users has a different level of expertise when working with Kubernetes, which meant we had to focus on building a tool that both experienced and novice Kubernetes users could use daily. This is our third step and one of our most important: creating a product that can resonate with all Kubernetes users, regardless of their experience. I know this might sound cliché, but I can’t overstate how essential it is to understand your targeted end-user.

The main point I want to stress here is that your entire targeted audience should have the ability (and desire) to get up and running with the product relatively quickly. The solution, product, or tool should be so easy to use that anyone can become a “power user” with minimum effort (and without having to read documentation).

Step Four: Listen to the Community

Okay, now for the part you guys all care about: how Lens grew from 0 to 500,000 active users in less than two years. The majority of our growth came with virtually zero PR and without a profound marketing budget. The open source application grew, and continues to grow, primarily from word of mouth.

Yes, I said it: word of mouth. I know it’s not the growth hack you were expecting, but Kubernetes developers, operators, and SRE’s currently using our product did the majority of the heavy lifting for us.

But that doesn’t mean that we ignored the need to increase user adoption. One of the most important things we did to improve user experience and growth was to enable our community to provide feedback.

Due to this opportunity, we have had over 1000 commits with roughly 1200 issues resolved within the first sixteen months of Lens being launched as an open source project — and we are just getting started! We quickly learned that resolving issues in a timely fashion demonstrated our care and respect for our users and the product, resulting in us quickly building trust within the open source cloud-native community.

Indeed, to “hack” the system, you need to focus on developing a fantastic product. What do I mean by that? Well, I think author Seth Godin says it best: “Don’t find customers for your products, find products for your customers.” And this is precisely what we did. We put our end user’s biggest challenges first and built a product that anyone within the Kubernetes ecosystem could use. We learned that everything started with the product, so we asked ourselves, “Are we building something extraordinary that our end users would be willing to share with their colleagues?” If the answer to this question is anything but yes, then you have some work to do.

When it comes to building something truly extraordinary, you need to focus on understanding everyone that will try or use your product.

  • Do we solve problems, or are we just trying to sell a product?
  • Are we incorporating our user feedback into the solution?
  • Can anyone within the Kubernetes ecosystem use our product?
  • Is our product extraordinary and easy to use?

The main point here is that you will never know exactly what it takes to make your product, technology, or software extraordinary. But there are several things you need to do to ensure you are on the correct path. The bullets mentioned above are specific things we kept in mind while building Lens.

Feel free to reach out to me directly if you would like a further conversation around this topic. Thank you for your time.

About Lens — The Open Source Kubernetes Platform

Lens is the way the world runs Kubernetes. It’s lowering the barrier of entry for people just getting started and radically improving productivity for people with more experience. Users of Lens gain clarity on how their clusters and cloud-native software stacks work. It helps people to put things in perspective and to make sense of it all. Thousands of businesses and hundreds of thousands of Kubernetes users develop and operate their Kubernetes on Lens.

The Lens open source project is backed by a number of Kubernetes and cloud-native ecosystem pioneers. With a community of over 500,000 Kubernetes users and 17k stars on GitHub, Lens is the largest and most advanced Kubernetes platform in the world. Download Lens at https://k8slens.dev.