The Business of Open Source

Have you thought about how your OSS license could impact your ability to grow your community and monetize your OSS in the future? Attorney McCoy Smith talks about what to be aware of at the beginning to avoid messy legal issues down the road.

Links:
McCoy on LinkedIn
Lex Pan Law
Opsequ.io

Some of the highlights of the show include

• Why Adform decided to move to a cloud native architecture and Kubernetes specifically
• Who was the driving force behind the move to Kubernetes?
• Was the switch purely an engineering decision or did it involve people outside of engineering?
• Positive and less positive surprises that come with switching to cloud native
• Organizational and technical problems Edgaras has faced
• What’s next for Adform on their cloud journey

Links

• LinkedIn: https://www.linkedin.com/in/apsega/
• Twitter: https://twitter.com/Apsega

Transcript
Announcer: Welcome to The Business of Cloud Native Podcast where we explore how end users talk and think about the transition to Kubernetes and cloud-native architectures.

Emily: Welcome to The Business of Cloud Native. I’m Emily Omier, your host. And I’m here today with Edgaras Apsega, lead IT systems engineer at AdForm. Edgaras, what I’d like to do is just start out with you introducing yourself.

Edgaras: I’m Edgaras. I’m working in the Adform. For anyone that doesn't know, Adform is one of the leading advertising technology companies in the world, and provides the software used by buyers and sellers to automate digital advertising. And, probably one of the most interesting parts of our solution stack is demand-side platform that has real-time bidding. And, what it means is that when that page is loading for some kind of internet users, behind the curtain, there's actually a bidding process that takes place for the placeholders to show ads. So, basically, you're doing low latency stuff. And, in Adform, I'm a lead systems engineer for the cloud services team. Our team consists of eight people, and we are providing private cloud storage, load balancing, CDN, service discovery and Kubernetes platforms for our developers that are in [00:01:36 unintelligible] production services. So, to better understand the scale that our team is working on, first of all, you can see that we are not using public cloud and we have our own private cloud that has six regions, more than 1500 physical servers, and there are more than 4000 [00:01:55 unintelligible]. And, for Kubernetes, we have seven clusters, more than 50 physical machines and around 300 constantly running [00:02:05 pods]. So, we can say that we prefer bigger clusters with bigger resources sharing pools. And you asked, how do I spend my daily work, right?

Emily: Yeah. So, when you get into the office or—right now you're not going into the office—get into your table or your [laughs] home office, what are the first couple things that you do, or...

Edgaras: Yeah, so, when I arrive at work, or, like, at these times, just get off the showers straight into work desk, [laughs] actually, I'm most productive in the mornings and evenings. So, in the mornings, when I go to my work desk, I try to do as much as I can. My sprint plan tasks, and then I scroll through the Slacks, emails, and the tickets assigned to me because we have a development team in another region. So, instantly in the mornings, we have some kinds of support tasks that we need to do.

Emily: Let's go ahead and talk about what this is all about, the business of cloud native, and tell me a little bit about why Adform decided to move to a cloud native architecture. Why did you decide to use Kubernetes, for example?

Edgaras: I'd say, actually, there were two parts. At first, we moved from traditional and, let's say, old-fashioned monitoring solutions to Prometheus, and its integration with service discovery solved lots of operational time for constantly managing and configuring monitoring and alerting for our, quite often, changing infrastructure. And the second part is the adoption of Kubernetes and all of the together coming parts like continuous integration and delivery. So, why we moved to this kind of architecture? It was because the biggest pain points for developers were to maintain actually their virtual machines. And rolling out new software releases in an old-fashioned way, took just lots of time for new software releases to reach production. So, we were looking at the new solutions that were available in the market, and Kubernetes was actually one of them. So, after successful proof of concept, we have selected it as our main application scheduler and orchestration tool.

Emily: What would you say was, like, the business value that you were hoping to get out of Kubernetes, out have the ability to release software faster, for example?

Edgaras: Yeah. So, actually, we wanted to remove the operational time from our developers so that they could spend more time coding without taking care of all of the infrastructure surrounding parts, like the appli...

"Fueling a culture of openness in innovation and research." That slogan is well known to Abigail Cabunoc Mayes, a leader in GitHub's open-source maintainer program. With a background in open science, Mayes felt right at home when jumping to open source and mentoring many developers at the Cloud-based Hosting service.

On this episode of The Business of Open Source, listen to Mayes speak on sustainability and resilience in building a platform for developers and what makes a robust and sustainable environment. Mayes also talks about financial stability and models in the open source world and what it truly means to break from a main backer and build on your own.

Highlights:

• Supporting "maintainers" (3:02)
• Succession planning (3:38)
• Being resilient in sustainability (5:40)
• Building financially without company backing (6:29)
• GitHub experimentation (10:42)
• Strategies for critical projects that are lower in the stack (11:55)
• Technical sustainability (13:47)
• Hypothetical financial models (19:33)

Links:

Abigail

• LinkedIn
• Twitter
• GitHub

Franz Karlsberger is the CEO of Amazee.io, an open-source platform that seeks to make developers’ lives easier by abstracting their day-to-day workload. Throughout our conversation, we explore what it means to join an open-source start-up as an external CEO, and why Franz put so much emphasis on go-to-market strategy. Franz also walks through the importance of knowing what open-source business model your company will follow, and how to measure the success of an open-source project.

Listen in as Franz shares some of his most interesting mistakes, what he’d do differently if he could start over, and why Franz feels open-source is more than just a type of software, it’s a company ethos that affects everything down to the team culture.

Highlights:

• Franz introduces himself and his company Amazee.io, which is a ZeroOps application delivery platform (00:50)
• How Amazee.io went from being a point solution to a platform solution (06:20)
• Why Franz was brought in as an external CEO for Amazee.io to accelerate growth (10:03)
• How Franz adjusted to working at an open-source start-up and what that learning curve was like for him (11:47)
• The importance of open-source at Amazee.io and why it is baked into their core values and ethos as a company (15:30)
• How the go-to-market model differs for Amazee.io’s cloud offering versus their managed offering (17:51)
• Franz describes some of the most interesting mistakes he’s made and what he’s learned from them (23:25)
• Franz’s views on measuring the success of an open-source project (26:29)
• How listeners can connect with Franz and learn more about Amazee.io (32:37)

Links:

Franz

• LinkedIn: https://www.linkedin.com/in/franzkarlsberger/
• Twitter: https://twitter.com/fkarlsberger
• Company: https://www.amazee.io/

This week on The Business of Open Source, I spoke with Tyler Jewell — for the second time, now. Last time I spoke with Tyler, he was an investor at Dell Technologies Capital, he’s since taken over as CEO of Lightbend.

We talked about a lot, but there was a definite theme to our conversation: License changes. Lightbend had been running an open core model, with the open core using a permissive Apache license. The company’s open source project, Akka, is massively popular. Lightben had about $13 million in ARR. But it was spending over $20 million per year, mostly of on R&D and then GTM. And they had a churn problem; and the churn problem was that customers would stop buying Lightbend’s product, but they would stay with Akka, because it was good enough.

Why did this happen? The added proprietary features weren’t valuable enough for companies to pay for, especially in the face of budget cuts. And because the community was quite mature, it often started to duplicate these capabilities. And then the company faced a near-death experience in 2021. At the same time, usage of Akka was only growing, while the company was facing potential bankruptcy. Investors saw the potential and didn’t want to give up on the company, but it was clear to the board of directors that something needed to change — and that the thing that wasn’t working was the business model.

So they changed it.

There’s a couple things I hope people can take away from this.

• If the difference in value between your commercial product and your open source project isn’t big enough, you’ll have a rough time building a profitable company.
• Sometimes the alternative to changing a license is bankruptcy; bankruptcy ultimately is not in anyone’s best interest, not the company, not the community’s, not the customer’s.
• Offering a cloud option can work, but it’s an entirely different business, and trying to build it up while the company is in a crisis and expecting it to save the company is only realistic if there’s a good overlap between the market for the cloud offering and the open source project; in this case, there wasn’t good overlap.
• The license options open to you depend on what the actual software does. And if you’re going to enforce the license at all, you need to have some visibility into where it’s installed, which, again, can be challenging depending on what kind of software you’re dealing with.
• Changing an open source project’s license is not a trivial undertaking. You have to hold copyright to the code, and you better hope that you’re structured your contributor license agreements correctly. You also have to do the change on a new release — and it’s more likely to work if the new version is different enough from the previous one that people really want to update.
• If you’re going to make a license change, you might get backlash, but if being transparent and honest can go a long way towards minimizing the PR disaster.
• So what happened? Churn went down, revenue is nearly doubled and Tyler projects that this year will be cashflow positive.

This summary doesn’t do it full justice, though, so check out the full episode!!