This open source project has (for the first five years of its life) been developed not as hobby but rather for me, Conrad, it has been a full-time professional undertaking. I have funded the large majority of this work out of my own pocket with money I made living in San Francisco working for companies like VMWare and Facebook. Yet I can say without hesitation that my ability to support the project with my personal resources is not only finite, but is at present exhausted. The project needs money to keep going, and I obviously hope to see some return on my investment in building it. How can we resolve the paradox that writing permissively-licensed, open software is a notoriously difficult way to be able to turn a profit? Will we eventually be reduced to trying to sell some weird BABLR+ product?

The answer to that question has a great deal of nuance to it, but perhaps the least nuanced aspect is that I've co-founded a for-profit company, Silphium Labs, together with BABLR contributor Stirling Hosstetter. Where other recent devtools startups have promised to carve out a modest niche for themselves, Silphium is taking a moon shot: we aim to eat Github's whole market.

We think we can do this basically the same way that Github itself did it: by making best-in-class tools for engineers, offering free hosting to open-source projects, and then ultimately winning the corporate market for code hosting by word-of-mouth, from the bottom up. The good news is that this strategy gives us a very clear proposition for how to make money: cash for services, and it clearly gives us monetary incentive to do good work.

While this plan is highly audacious, in a way it's also extremely simple. Microsoft's market dominance is formed by a web of integrated technologies, most importantly VSCode, Language Server, Github, and Git. These are the tools most developers will have in their hands as they are reading, writing, and sharing code day-to-day. To succeed, we need to make tools that feel better in their hands. Once you pick up our tools and get familiar with them we hope (and think) you'll dread having to go back to using the old ones.

Building some high-quality stuff won't be enough though: even with solid tech we'd still be many orders of magnitude short of reaching the desired scale! Fortunately we have a core engine of growth in our standards for "narrow-waist" interoperability between editors and languages. Our tools let the author of a programming language define its parser once while supporting even tools that haven't been written yet. And on the flip side we let the author of a tool use our APIs in such a way that their tools is able to support programming languages that haven't been written yet. This is the same engine of growth that has led Language Server Protocol to become so dominant. The more parsers are built the more valuable the BABLR platform will be to build tools which support those languages, and the more tools are written on the platform the more incentive there will be to write new parsers. If the standards layer is effective in transmuting "m times n" complexity into "m + n" complexity then a virtuous cycle will be created; a community which fuels its own growth.

It should finally be noted that even some degree corporate success cannot guarantee the ongoing health of an open project like this. An astute observer will respond that the project is still vulnerable to becoming closed, either as a result of actions by future-me, or as a result of an "embrace extend extinguish" play by a heavyweight player. Oddly I think of these as almost the same risk. Both involve an "extend extinguish" attitude, as a new restrictively licensed product will be left to compete in a market with its open doppelganger(s). I am fully willing to see future-me as a risk, but the actions I'm taking in the present to guard against both threats are basically the same: I build software by a process of refining it until there is nothing left to simplify.

My goal in doing this is to deny leverage that a forked project would try to use to supercede the open mainline with an alternative closed implementation. Attempts to keep a platform proprietary and closed usually require making it convoluted, opaque, and generally hostile towards interoperation with the idea that the company can provide a better end-user experience if they are in complete control, which sometimes they can for a while. But this strategy is highly unlikely to be successful when established open tools are polished enough to offer a good user experience, as there would then be no UX leverage to get people to go closed.

As I am writing this we are just starting out on our long journey and there is no telling what ups and downs may be ahead. Building out language support and a tooling ecosystem will be a gradual process. We're going to build an IDE. We're going to built a code forge. We live here, and every day we make it a little better of a place to be. We're in it for the long haul!