What is open core? Is a challenge open core, or is a enterprise open core? That’s debatable. Like open supply, some view it as a development model, others view it as a business model. As a product supervisor, I view it extra within the context of worth creation and worth seize.
With open supply, an engineering staff can seize extra worth than it contributes. An engineer collaborating in an open supply challenge can contribute $1 price of code, but get again $10, $20, $30, or extra price of worth. This worth is measured in each private model, in addition to capability to steer and affect the challenge in a course that’s useful to their employer.
With open core, at the least among the code is proprietary. With proprietary code, an organization hires engineers, solves enterprise issues, and prices for that software program. For the proprietary portion of the code base, there isn’t a community-based engineering, so there is not any course of by which a group member can revenue by collaborating. With proprietary code, a greenback invested in engineering is a greenback returned in code. Unlike open supply, a proprietary growth course of cannot return extra worth than the engineering staff contributes (see additionally: Why Red Hat is investing in CRI-O and Podman).
This lack of group revenue is absolutely vital when analyzing open core. There is not any group for that a part of the code, so there isn’t a group participation, no group revenue. If there isn’t a group, there isn’t a potential for a group member to realize the usual advantages of open supply (private model, affect, proper to make use of, studying, and so on.).
There’s no differential worth created with open core, so in 18 ways to differentiate open source products from upstream suppliers, I describe it as a strategy for capturing worth. Community-driven open supply is about worth creation, not worth seize. This is a basic pressure between open supply and open core.
Open core versus glue code
First, let’s check out what individuals usually view as open supply. As described on Wikipedia, “the open-core model primarily involves offering a ‘core’ or feature-limited version of a software product as free and open-source software, while offering ‘commercial’ versions or add-ons as proprietary software.” The drawing beneath exhibits this mannequin graphically.
An instance of this mannequin is SugarCRM, which had a core, open supply piece of software program in addition to a bunch of plugins, lots of which had been proprietary. Another instance of that is the original plan Microsoft had for the Hot Reload feature in .Net (which has since then been reversed).
Another associated mannequin is what I’ll check with as glue code. Glue code would not instantly present a buyer enterprise worth. Instead, it hangs a bunch of initiatives collectively. Notice, on this instance, I display three open supply initiatives, one data-driven API service, and a few glue code that holds all of it collectively. Glue code will be open supply or proprietary, however this isn’t what individuals usually consider once they discuss open core.
An instance of open supply glue code is Red Hat Satellite Server. It’s made up of a number of upstream open supply initiatives like Foreman, Candlepin, Pulp, and Katello, in addition to a connection to a knowledge service for updates (in addition to connections with tools like Red Hat Insights). In the case of Satellite server, the entire glue code is open supply, however one can simply think about how different corporations would possibly make the selection to make use of proprietary code for this performance.
When open core conflicts with group targets
The traditional drawback with open core is when the upstream group needs to implement a characteristic that’s in one of many proprietary bolt-ons. The firm or product which employs the open core mannequin has an incentive to cease this from taking place within the open supply challenge on which the proprietary code depends. This creates some critical points for each the upstream group and for patrons.
Potential prospects might be incentivized to take part locally to implement the proprietary options that are perceived as lacking. Community members who attempt to implement these options might be shocked or irritated when their pull requests are tough to get accepted or rejected outright.
I’ve by no means seen a critical resolution for this drawback. In this video, How To Do Open Core Well: 6 Concrete Recommendations, Jono Bacon recommends being upfront with group members. He recommends telling them that pull requests which compete with proprietary product options might be rejected. While that is higher than not being upfront, it is not a scalable resolution. Both the upstream challenge and the downstream product with proprietary options are continually altering landscapes. Often, group contributors aren’t even being attentive to the downstream product and do not know which options are carried out downstream, or worse, on the roadmap to be carried out as proprietary options. The upstream group isn’t emotionally engaged with the enterprise issues solved by downstream merchandise, and may simply be confused when their pull requests are rejected.
Even if the group is keen to simply accept the no-go zones (instance: GitLab Features by Paid Tier), this makes it a excessive likelihood that the open supply challenge might be a single-vendor endeavor (instance: GitLab contributions are primarily GitLab employees). It’s extremely unlikely that rivals will take part, and it will intrinsically restrict the worth creation of the group. The open core enterprise may nonetheless seize worth by way of thought management, expertise adoption, and buyer loyalty, however arguably they may by no means really create extra code worth than they make investments.
Apart from these issues, if an upstream challenge really adheres to open governance, there’s really nothing the open core enterprise can do to forestall proprietary options from being carried out. Intra-project (inside a single challenge) proprietary code simply would not work.
When open core would possibly work
Glue code is a spot the place open core or proprietary code would possibly work. I’m not advocating for open core, and I usually suppose it is inefficient, however I wish to be sincere with my evaluation. There are certainly pure boundaries between open supply initiatives. Going again to my open supply as a provide chain thesis (see additionally: The Delicate Art of Product Management with Open Source), a fuel injector is a gas injector; it is not an alternator. These pure demarcation factors do make good areas for differentiation of the downstream product from the upstream challenge (see additionally: 18 Ways to differentiate open source software products from their upstream projects).
A traditional instance of proprietary glue code is the unique Red Hat Network (RHN), launched within the 12 months 2000. RHN was primarily a SaaS providing which offered updates for Red Hat Linux machines, and this was earlier than Red Hat Enterprise Linux was even a factor. For context, when RHN was launched, the time period open core wasn’t even invented but (coined in 2008), coincidentally the identical 12 months that the upstream Spacewalk project was launched. Back then, everybody was nonetheless studying the core competencies of the right way to do open supply properly.
In retrospect, I do not suppose it is a coincidence that RHN existed on the nexus of the pure demarcation level between an upstream Linux distribution and pay-for providing. This naturally suits the psychological mannequin of differentiating a product from the upstream supplier. It is perhaps tempting to conclude – “See!?!? The largest open source company in the world differentiated itself with proprietary code! Open core is the reason Red Hat survived and flourished” – however I’d watch out to not confuse correlation with causation. Red Hat finally open sourced RHN as Spacewalk and by no means took a success to income.
Pivoting barely, one may additionally make an argument that the cloud suppliers usually comply with this mannequin at the moment. It’s well-known within the trade that many of the giant cloud suppliers carry their very own forks of the Linux kernel. These forks have proprietary extensions which make Linux usable of their environments. These options do not resolve a buyer’s enterprise drawback instantly however as an alternative resolve the cloud supplier’s issues. They’re primarily glue code.
Cloud suppliers have a barely totally different motivation for not getting these modifications upstream. For them, carrying a fork is commonly cheaper and/or simpler (although not simple) than contributing these options upstream, particularly when the modifications are sometimes not needed by the Linux kernel group. Cloud suppliers are sometimes selecting the perfect unhealthy concept out of a bunch of unhealthy concepts.
Open core glue code is perhaps referred to as inter-project (between a number of initiatives) proprietary code. This would possibly work, however arguably, this type of code is already tough to implement and would not want the perceived “protections” of a proprietary license. Stated one other approach, open supply contributors aren’t essentially incentivized to work on and preserve glue code. It’s a pure place the place a vendor can differentiate. Often glue code is complicated and requires particular integrations between particular variations of upstream initiatives for particular life cycle necessities. All of those particular necessities make glue code a fantastic place for a product to distinguish itself from the upstream initiatives with out the necessity for a proprietary license. The velocity (velocity and course) of enterprise integrations are fairly totally different from the speed wanted for collaboration between a number of upstream initiatives. This velocity mismatch between upstream group wants, and downstream buyer wants is an ideal place for differentiation with out the necessity for open core.
Conclusion
Can open core work? Is it higher than open supply? Should everybody use it? It appears apparent that Open core can work, however solely in very particular conditions with very particular sorts of software program (ex. glue code). It appears much less apparent that there is any argument that open core is definitely higher for creating worth. Therefore, I don’t suggest open core for many companies. Furthermore, I believe the percieved protections that it affords are literally pointless.
Often, distributors discover pure locations to compete with one another. For instance, SUSE runs the OpenSUSE Build Service, which relies on utterly open supply code. Even although Red Hat may obtain the supply code and arrange a competing construct service, they have not. In reality, the upstream Podman challenge, which is closely sponsored by Red Hat, makes use of the OpenSUSE build service. Though SUSE may simply make this code proprietary, they needn’t. Setting up, working, and sustaining a competing service is plenty of work and would not essentially present Red Hat prospects with plenty of worth.
I nonetheless suppose Open Core is a step in the best course from totally proprietary code (instance: GitLab is open core, GitHub is closed source), however I do not see a compelling purpose to market it as a greater various to utterly open supply. In reality, I believe it is exceedingly difficult to do open core properly and sure inconceivable to genuinely create differentiated worth with it (see additionally: The community-led renaissance of open source and Fauxpen source is bad for business).
This thesis on open core was developed by working with and studying from a whole lot of passionate individuals in Open Source, together with engineers, product managers, advertising and marketing managers, gross sales individuals, and among the foremost legal professionals on this area. To launch new options and capabilities in Red Hat Enterprise Linux and OpenShift, like launching Red Hat Universal Base Image, I’ve labored carefully with so many alternative groups at Red Hat. I’ve absorbed 25+ years of institutional information, in my 10+ years right here. Now, I’m attempting to formalize this a bit in public work like The Delicate Art of Product Management with Open Source and follow-on articles like this one.
This work has contributed to my current promotion to Senior Principal Product Manager of RHEL for Server, arguably the largest open source business in the world. Even with this expertise, I’m continually listening, studying, and looking for fact. I’d love to debate this topic additional within the feedback or on Twitter (@fatherlinux).
