As I’ve noted in the past, open source is as much of a moral issue for me as it is anything else. I feel morally obligated to write and distribute open source code. I’m a bit of an idealist, but I also realize that this principle can be at odds with modes of business, and, by extension, basic survival.

You need money to survive in this world. Freely distributing software is generally not directly profitable, but it is possible to profit from it by offering support and other services around the free software. This isn’t a silver bullet, though. Not every developer wants to provide services for a living, as it may not fit well with their skill set, interests, or other constraints. For instance, an open source developer might not feel comfortable directly working with or for others, and instead prefer to focus on product development or other solitary means of income. There needs to be another way of making money with open source software, one that is not at odds with respecting the freedoms of users and sharing useful tools with the community.

Let’s say that I want make my living by starting and running a website. For argument’s sake, let’s say I’m building a social network for coffee shop enthusiasts (yes, I am writing this in a coffee shop). To make this website, I need a server and a UI. I own and control the server, but the UI code runs in users’ browsers. It wouldn’t make much business sense to freely distribute all of the code I write, as I would be giving away any competitive edge I might make for myself. At the same time, I don’t want to opaquely control users’ machines without making it clear what my code does. In other words, users should have free access to the source code of the HTML/CSS/JavaScript that they are downloading and running in order to use the website I’ve built.

I feel that a reasonable compromise in this situation is to share the UI code, but not the server code. Computer users have the right to know everything that their machine is doing. It’s their property, it should not be made arbitrarily mysterious to them. While most users are not technical enough to understand what a piece of software is doing and will probably never care, there should never be a limitation that prevents them from doing so. However, users do not control or own the server of a web service. I do not feel as obligated to share that code with them. It would certainly be nice to do so, and in some cases it is feasible, but sharing remote server code (in this example) would jeopardize my income and livelihood.

Free software, as defined by the FSF, feels ideologically pure to me. I want to live in that world. But we live in a world where competitive edge matters, and giving away the entirety of your product is not a viable business model in a lot of cases. A more realistic compromise is to open source the code that a users’ machine will execute, but not the code that runs on a remote server that a service provider controls.

A potential gray area with this approach is service provider trust. If I as a user can’t see what the developer’s server is doing, then my data is at risk of being used in ways that I do not consent to. While there is no failsafe way to guard against this, it is the responsibility of a service provider to provide a Terms of Service document explaining what they will and will not do with users’ data. It is the responsibility of a user to read and agree to that document before using the service. Users should always be able to opt-out of a service if they don’t feel that it provides what they want, or if using it is not in their best interest.

As a programmer who loves what he does, I want to share as much code as I can. I also don’t want to starve. Dogmatically adhering to the principles of all-open or all-closed software is divisive and bad for the software development ecosystem. I think there is a better way to develop software that respects the interests of both users and developers: Compromise.