Navigate Your Open Source Project along the Hype Curve
The first post-pandemic KubeCon had a very different feeling from the last couple I had been to, and it wasn’t just because of the masks and general fear of COVID hanging overhead.
For a while now there has been increased interest among contributors in the peripheral Kubernetes tools and plugins, rather than the Kubernetes core. Now that the core Kubernetes has stabilized and the pace of adding new features has slowed, the Kubernetes community has begun pivoting to a maintenance-focused mode. That’s not to say there aren’t new things still happening in Kubernetes core, but the core is not what people are primarily working on anymore.
No open source project is immune to the rollercoaster that is the dreaded hype cycle.
When OpenStack encountered the tipping point at the Peak of Visibility and Kubernetes was on the rise at the same time, some people thought that Kubernetes would never fall victim to the same situation. Many people thought that Kubernetes would solve it all and that it was in direct competition with OpenStack (spoiler: It’s NOT — they solve different problems and are complementary in many ways). It seems, however, that Kubernetes now has made it to that difficult point in the hype curve that no open source project is completely immune to.
Let’s take stock of what we have here — a massive global community with hundreds of vendors and hundreds of users relying on the core repo; thousands of people around the world employed to deploy and operate it; the challenge of battling sprawl and keeping contributors engaged. Hmm, that sounds familiar.
Where have I heard all this before? Oh, right, OpenStack like 3-5 years ago. These growing and maturing pains of open source projects do not come on suddenly; they slowly build as the project progresses along the hype curve, and they don’t become a real problem until the number of drive-by contributions begin to drop and core community members inevitably get moved by their companies’ shifting priorities to adjacent tools and technologies.
Hello, Trough of Disillusionment. Please show us the way to the Plateau of Productivity.
It’s important to understand that just because something is past the peak of its hype curve doesn’t mean it’s dead or about to die. It doesn’t mean the project is now useless, and it certainly doesn’t mean that the project won’t continue to be adopted and used by companies across the globe. Take OpenStack, for example. Tytus Kurek, product manager of cloud & NFV at Canonical, spoke at the OpenInfra Summit Berlin in June and described how OpenStack has entered the “Slope of Enlightenment”:
OpenStack was founded in 2010 to address the need for an open source, open infrastructure implementation, and it got a lot of visibility in the open source community. Then it moved to the “Peak of Inflated Expectations” somewhere around the Icehouse release. There was a lot of excitement. There were a lot of hopes. There were a lot of dreams. But not many of them became real, and then OpenStack started being less and less visible.
A lot of new technologies came in, including containers and several others, and we all had doubts whether OpenStack would ever rise again. Today, I have no doubts that OpenStack has passed this difficult period. I have no doubts that OpenStack has just entered the Slope of Enlightenment, and I have no doubts that it will continue to grow in the following years until it reaches the “Plateau of Productivity.”
Kurek said, “When Kubernetes and container technologies originally came in, they were seen as competitive technologies to OpenStack and people became uncertain whether they should perform their digital migration based on OpenStack or Kubernetes. Today, we know that Kubernetes and container technologies are complementary technologies to OpenStack. This trend falls very well under this new acronym, LOKI, which stands for Linux OpenStack and Kubernetes Infrastructure.”
Indeed, with over 25 million cores running in production, OpenStack has become the key layer of the open infrastructure stack, serving as a foundation for Kubernetes deployments, powering workloads of today and tomorrow. OpenStack has been adopted by service providers powering telco NFV services, research organizations with high-performance computing needs, and distributed edge deployments across a variety of industries including retail and telco.
OpenStack is also leveraged to build local public cloud infrastructure across over 180 data centers worldwide, helping bypass the limitations of hyperscalers, such as low bandwidth and high latency. But OpenStack still has its future as a general-purpose private cloud — something that every organization can use on their own in their data centers, effectively bringing infrastructure costs down.
OpenStack’s story illustrates that what we’re seeing now in the Kubernetes community is to be expected. Moving past the peak of the hype curve just means the project is entering the next stage of its life span and is having to deal with some growing pains it had been able to ignore up until this point.
Technically, it’s more “shrinking pains,” as the drive-by contributors slow down and the community shrinks its core set of people working to keep the software healthy and strong. The real concern at this stage is to support these core maintainers as much as possible to make sure they don’t burn out.
Many of the conversations, both in the hallway track and the Kubernetes Steering Committee AMA during the Contributor Summit on Day 0 of KubeCon + CloudNativeCon focused on the need for more maintainers of the core Kubernetes. More than one member of the Steering Committee called for more support from sponsor companies in the form of maintainers doing code review. The focus was on how to stabilize the testing infrastructure and keep the quality of the code being merged above a certain standard, which is a major concern for an open source project as popular as Kubernetes.
The moral of the story here for open source communities is two-fold: 1. Face the facts: All open source projects and communities will feel the effects of the hype curve at one point or another (exactly how much varies on the community and the scale); 2. Be ready with a post-hype strategy for maintaining and nurturing the project and the community for the long term.
Here are five things to keep in mind when you think that your project’s hype-curve rollercoaster might be reaching that scary drop. (It is coming; don’t go on thinking it won’t happen.)
- Protect the Golden Goose. Your maintainers are your community’s lifeblood. Do what you can to make sure they don’t burn out. There are oodles of resources from a community standpoint and also from a company standpoint on how to support maintainers and make sure they have the support they need to keep your best interests at heart and keep the project healthy.
- Simplify where possible. There are likely to be a lot of processes that you won’t have enough people to support. You might need to take a harsh stance on combining community roles and cutting activities that might be “nice to have” but are not required to keep moving forward.
- Stop the sprawl. When you have resources coming out of your ears because you are racing up that hype curve, it’s easy to say yes to all the things. Just know that there will be a time of famine. You can’t have all the extras forever, and you will need to cut back (see number two), so being a little more choosy at the start will make that a little easier later.
- Sponsors, “walk the talk.” Sponsor companies need to step up and make sure they stay involved. If you are running the software, you should have at least one full-time upstream contributor involved in the project. Granted, this isn’t easy for smaller companies, but it’s the best way to protect your interests and investments. If the project fails, you’ll likely incur greater costs in migrating to a new piece of technology.
- Don’t sweat it. This is not the end. It’s a natural part of the maturation of every project and community. So teach your community to expect it and plan for it so that it can reach its full potential.
Your project will inevitably pass the peak of the hype curve, and that is okay. It really is not the end of the world, and your project is not dying. It’s not time to abandon ship; it’s time to double down and take care of your core maintainers and contributors so that you can keep moving forward as a healthy, stable, mature open source project.
