WhyOpenSource

You may have noticed as a tool, Cmd is a little different. It's simple but powerful and takes a bit to internalize everything you can do with it. Cmd is also very different as a project. It was made to be a hosted service while also being open source.

Most projects that exist in both of these worlds start as open source and then a hosted service develops later, such as Sentry and GitLab. Projects like these were initially created with the intention of being open source software that users run on their own. Later, often to fund development of the project, or just to capitalize on its success, a hosted product version is released, usually by a startup founded by the project creators.

Much more rare, but not unprecedented, is when a hosted product becomes open source. Most often this happens because of a shutdown or an acquisition, though often these are the same. This second-act-as-open-source is effectively an attempt to not throw away the work that was done and the value it provided to its users.

An important distinction here is that running a hosted service is a very different game than maintaining an open source project. Unlike open source, you have real costs associated with running a service, which can change over time. Though hosted services and open source share a lot of roles for contributors from development to support to marketing and beyond, hosted services also have a critical role that most open source projects do not: operations.

With that in mind, running a hosted service can't just happen the same way open source can. Because of the costs and extra roles necessary, the only mechanism to make a hosted service exist and continue to exist seems to be business. This further increases the roles necessary to include sales, management, HR, accounting, etc.

It's also important to realize that open source and hosted services are very different experiences. This might be obvious to those involved in developing SaaS products, but might be less obvious to those entrenched in the open source paradigm. It's a fundamentally different experience to "just use" a tool than it is to learn how to configure, operate, and continue to operate a tool and the infrastructure required by the tool. Even as a mental barrier, those extra steps using open source can in some cases outweigh the perceived value of the tool itself.

So while some hosted services and open source overlap in functionality and features, as products, both in their user experience and their design and architecture, they are in different classes. I'd like to further posit that the type of tools possible are very different. And if you'd continue to indulge me, I'd also say that the requirements of a running a business to build and run a hosted service hugely impact and limit the type and nature of hosted tools we have available to us.

Cmd was made to be a hosted service. It's open source not specifically for philosophical or moral reasons, though I would agree that all software might as well if not should be open source. It's definitely not open source because I want the primary way to use it to be "run it yourself." It's open source because I don't want to build a business or a startup around it. For that reason alone it might as well be open source, but more importantly, I want to find a new way for hosted tools and technology like Cmd to exist and I believe this can be done building on open source as a foundation.

Hopefully this provides some context around why Cmd is to be open source, but perhaps should not be thought of as a typical open source project. In fact, if I ever introduce Cmd as an open source project, people immediately assume they will run it themselves. While that will be possible, it is not the intention of the project or how it is being built.

Open source should not be synonymous with "run it yourself", and commercial ventures should not be the only way to build cloud-based tools.

If you're curious about how we can run Cmd as a hosted service without building a business around it, well it's a long story almost 10 years in the making. Here is a blog post where the idea started to come together in 2009. Here is a talk from 2013 in which I further explain the problem and a more developed idea how to solve it. Here is a post from February 2016 on why startups shouldn't be the only option. The current plan is a variation on autosustainable, which I'll be documenting soon.