One of the more interesting areas of innovation in open source has been the licensing models companies have used to commercialize it. For years, a number of companies subsisted on the Open Core model, wherein the core of a product was open source licensed while add-on capabilities (like advanced security) were kept proprietary. In a conversation with RackN CEO Rob Hirschfeld, he pointed out an oddity of this model: Few contribute to the core of a project, but many want to contribute around the edges.

For RackN, primary sponsor of the Digital Rebar open source project, this “aha” realization led them to completely invert their Open Core model, open sourcing their extension ecosystem while making their core closed. Has it worked? Let’s see.

Open to developers with time

No matter the open source project, it’s hard to get much involvement at the core of the code. Why? Because…time. Or, rather, a lack thereof. That is, it takes a lot of time for a developer to come up to speed with a particular project–most can’t afford the time commitment unless they’re getting paid to contribute.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

In a 2005 presentation at the MySQL Users Conference, then MySQL CEO (now HackerOne CEO) Mårten Mickos captured this, and I later packaged as part of my 2006 OSCON talk:

For better or worse, the ideas in this slide have remained relevant many years after I first presented them. It’s still the case that the vast majority of work on a given open source project is done by a small group of contributors. The closer you get to the core of a project, the more true this is. As mentioned above, it’s usually just a matter of time: Only those paid to make significant contributions can afford to keep up with the pace of a project, and can build up the credibility over time to be invited to become a project maintainer.

This brings us back to Digital Rebar, a data center automation, provisioning, and infrastructure-as-code (IaC) platform.

“Don’t give me the B-grade stuff”

Digital Rebar started out as Crowbar, a Dell project launched nearly a decade ago under an open source license in part because, Hirschfeld said, “That was the only way we could move code through Dell.” A few years (and name changes) into the project, now under the RackN sponsorship, RackN did an evaluation of its community. “We reviewed the [Digital Rebar] code base to look at where we were actually getting contributions. And over the course of our history of building the project, we didn’t have any core contributions at all,” said Hirschfeld. 

Not “a few.” Not “some.” The answer was “none.” 

SEE: How open source might prove helpful during the coronavirus pandemic (TechRepublic)

Nor, I suspect, would Digital Rebar be particularly atypical in this. For projects with significant commercial sponsors, there are a variety of reasons that outside contributions to the core tend to be rare (including, as mentioned, time). It’s harder to build a community of developers participating for the fun of it. What is easier, however, is gathering a community of commercial developers for the profit of it. To get there, though, it’s not really the core that needs a vibrant community.

It’s the ecosystem.

Though the Digital Rebar community didn’t seem interested in making changes to the core platform, they have demonstrated interest in expanding the functionality on top of it. For example, RackN recently saw a contributor add support for Chef Server in the content packs. “That means the community member is able to come in and add in an extension and then it becomes part of the catalog that we maintain,” noted Hirschfeld. So the community gets a curated, supported ecosystem. Nice.

At the same time, Hirschfeld said, the change has allowed RackN to more aggressively upgrade the platform. Prior to the change, RackN engineers wanted to implement a 10X improvement in the backend performance, which required a change to how the platform stores objects and manage things. “We would have had a lot of trouble committing that change into the open source code base because it was a huge IP change,” said Hirschfeld. By inverting the model and making the core closed, RackN was able to make the change with minimal disruption to the community of users, who were more interested in innovation around the edges of the project. 

Almost by definition, Open Core tells the user, “This open source code isn’t good enough. You need the Enterprise version.” For Hirschfeld, this proved problematic, and led to the company dumping the Open Core model. “The core’s got to work. It’s got to be rock-solid….[Open core, by contrast,] undermin[es] itself. [Customers don’t want] the B-grade stuff.” 

Disclosure: I work for AWS, but nothing herein relates to my work there.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see