Open Core is worse than plugins…and that’s why it’s better
Open kernel is obviously a horrible approach to building a product with an ecosystem of extensions and integrations: there are no proper protocols and interfaces. Instead, anyone can simply add their integration to the codebase and even adjust said codebase to their needs if it doesn’t fit.
So why have we been using the “Worse” approach at GitLab for many years now, with great success? Because Worse is better (a term coined by Richard P. Gabriel). Of course, it turns out that “Worst” is actually even better than Worse is better suggested.
by Gabriel original argument was that (slightly) inherently worse but simpler and easier to implement software has better survivability characteristics than better designed and more complex software, and will therefore consistently win in the market.
We at GitLab have found this to be fundamentally true, which is why we favor, for example, “boring technology”, even though it might not be the best possible solution for a given scenario. But that does not say it all: it turns out that such software is not only more efficient, it also ends up being qualitatively better in the end.
Worse is even better
Sid is Co-Founder, CEO, and Chairman of the Board of GitLab, Inc., the DevOps platform. Sid spent four years building recreational submarines for U-Boat Worx and while at the Dutch Ministry of Justice and Security (Ministerie van Justitie en Veiligheid) he worked on the Legis project , which has developed several innovative web applications to help legislate. He first saw Ruby code in 2007 and liked it so much he learned to program. In 2012, as a Ruby programmer, he met GitLab and discovered his passion for open source. Soon after, Sid brought GitLab to market, and in 2015 he led the company through Y Combinator’s Winter 2015 cohort. Under his leadership, the company has grown to over 30 million registered users, from startups to global enterprises.
It is important to note that Gabriel’s original argument was not that wrong the software wins, in fact, its “worst” and its “best” have the same qualities:
- Simplicity, interface and implementation
However, its “worst” and “best” have slightly different weights for the value placed on these characteristics, with the (worst) school in New Jersey favoring simplicity of implementation over simplicity of interface, while the ( better) school of “MIT” promotes simplicity of interface, even at the cost of a more complex implementation.
While a simple interface can be achieved with a simple implementation, both schools agree, the difference comes when there are tradeoffs to be made.
What Makes the Worst Even Better, and What Gabriel Didn’t Consider Even Later versions, is the enormous value of feedback loops. Being early not only allows the New Jersey approach to win in the marketplace, it also allows it to garner feedback much, much earlier, and much faster than the MIT approach.
Paul MacCready won the first Kremer Prize not by initially aiming to build the best human-powered aircraft, but by building the one that was easiest to repair in order to gather feedback more quickly. While other teams took a year or more to recover from a crash, his plane would sometimes fly again the same day. And so it is precisely this desire to lose sight of the prize that earned him the prize.
In the same way, it’s those quick feedback loops that a “worse” approach allows, started much earlier, that ultimately leads to a better product.
The problem with plugins
At least since the success of Photoshop, a proper plugin interface has been recognized as the right way to make software both more attractive to users and less easy to abandon by creating a third-party ecosystem that provides useful functionality without the provider has to provide all of these features themselves.
It was so successful that systems like OpenDoc took the idea further to be just a set of plugins, with no real hosting application. None of these systems have been successful in the market.
One reason is that good plugin interfaces are not only difficult, but downright fiendishly difficult to develop. The fundamental difficulty is that it is difficult to find the right balance: what to expose, what to keep hidden, how to provide functionality. But that’s not the evil part.
The fiendishly difficult part of plugin API development is that the very things you have to do to deal with the difficulties make it even harder: you have to design more carefully, you have to make the interfaces stable, you can’t iterate them. only slowly.
In short: you face a chicken and egg problem of premature abstraction. In order to create a good plugin API you need to see it used, but to see how it is used you must first have it. This dynamic delays initial availability and slows feedback cycles.
Software is not the only area facing this problem. Parks, for example, often have official paths that don’t correspond to where people really want to go. A group of landscape architects solved this problem by doing less: they didn’t put walkways in a park they had created. Instead, they waited for the trails to materialize as people walked where they needed to walk. It was only after these trails materialized that they paved them, making them official.
Finally, a plugin interface means that the end product the user sees, consisting of both the main application and all the plugins, is not as well integrated as it could be. The value proposition of “here’s a toolbox, have fun!” seems much more appealing to developers than to end users, even when these tools are, in themselves, best in class.
Open kernel, on the other hand, seems like exactly the wrong approach, certainly from a software engineering point of view, as there are no defined black box boundaries, but also from a business view because there doesn’t seem to be a real mutually reinforcing ecosystem.
However, the open core approach is ideal for end users, both for adopters who simply want to use it and also for adapters who need to adapt the system to their use case. And in the end, it’s the end users that matter.
For adapters, the system is immediately hackable. There’s no need to wait for the vendor to provide a plugin interface in the first place, and there’s no need to wait any longer for the vendor to get that plugin interface to provide the functionality needed for a particular application in the future, if ever. Even if modifications of the main application are necessary, this is at least possible.
Since there are more adaptive activities occurring earlier, the system is better able to meet adaptive needs, and a virtuous circle ensues.
For adopters, the benefits are multiple: First, the system gets more features faster, which is always good. More importantly, this functionality is integrated by the vendor and provided as an integrated whole. There’s a reason single-vendor office suites have succeeded where OpenDoc’s toolkit approach has failed.
That said, an open-core approach requires solid engineering, a good architectural foundation, and constant vigilance. As previously explained, we believe that Ruby on Rails has provided us with a good starting point to build GitLab as a solid modular monolith that is both accessible and well-structured. With this as a starting point, good design is encouraged by example, rather than imposed by strict API limits. Enforcement, on the other hand, takes on a more human form as pull requests are reviewed, shaped, and approved or rejected.
So the boundaries still exist, but instead of being brick walls to crash into, they are low fences that are visibly present, but can be breached if necessary.
And while these low fences are considered “worse” than the brick walls we’re used to, they actually lead to better outcomes for everyone involved.
Characteristic picture Going through Pixabay