Open core is worse than plugins… and that’s why it’s better
Open core is obviously a horrible approach to creating a product with an ecosystem of extensions and integrations: There are no proper protocols and interfaces. Instead, anyone can just add their integration to the code base and even adjust said code base 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 conceived by Richard P. Gabriel). Of course, it turns out that “Worse” is actually even better than Worse is Better suggested. Gabriel’s original argument was that (slightly) intrinsically worse but simpler and easier to implement software has better survival characteristics than better-designed, more complex software, and thus will consistently win in the marketplace. At GitLab, we have found that this is basically true, which is why we, for example, favor “boring technology,” even if it might not be the best possible solution for a given scenario. But this doesn’t tell the whole story: It turns out that such software is not just more successful, it also ends up being qualitatively better in the end. Worse is even better It is important to note that Gabriel’s original argument was not that bad software wins out. In fact, both his “worse” and his “better” have the same qualities: Simplicity, of interface and implementation Correctness Consistency Completeness However, his “worse” and his “better” have slightly different weights for the value placed on these characteristics, with the (worse) New Jersey school favoring simplicity of implementation over simplicity of interface, whereas the (better) “MIT” school favors simplicity of interface, even at the cost of a more complex implementation. If 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 worse even better, and what Gabriel didn’t take into account even in later versions, is the tremendous value of feedback loops. Being early doesn’t just let the New Jersey approach win in the marketplace, it also allows it to collect feedback much, much earlier and much more quickly than the MIT approach. Paul MacCready won the first Kremer prize not by initially setting out 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 sometimes flew again the same day. And so it was exactly this willingness to lose sight of the prize that resulted in him winning it. In much the same way, it is these quick feedback loops that a “worse” approach enables, started much earlier, that eventually lead 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 compelling for users and less easy to leave behind by creating a third-party ecosystem that provides useful functionality without the vendor having to provide all of that functionality 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 succeeded in the marketplace. One of the reasons is that good plugin interfaces are not just hard, but downright fiendishly difficult […]
