Using proprietary services to develop open source software

339 readers like this.
A fortune cookie that says "to succeed, you must share"

It is now pretty well accepted that open source is a superior way of producing software. Almost everyone is doing open source these days. In particular, the ability for users to look under the hood and make changes results in tools that are better adapted to their workflows. It reduces the cost and risk of finding yourself locked in with a vendor in an unbalanced relationship. It contributes to a virtuous circle of continuous improvement, blurring the lines between consumers and producers. It enables everyone to remix and invent new things. It adds up to the common human knowledge.

And yet

And yet, a lot of open source software is developed on (and with the help of) proprietary services running closed-source code. Countless open source projects are developed on GitHub, or with the help of JIRA for bug tracking, Slack for communications, Google Docs for document authoring and sharing, Trello for status boards. That sounds a bit paradoxical and hypocritical—a bit too much "do what I say, not what I do." Why is that? If we agree that open source has so many tangible benefits, why are we so willing to forfeit them with the very tooling we use to produce it?

But it's free!

The argument usually goes like this: Those platforms may be proprietary, they offer great features, and they are provided free of charge to my open source project. Why on Earth would I go through the hassle of setting up, maintaining, and paying for infrastructure to run less featureful solutions? Or why would I pay for someone to host it for me? The trick is, as the saying goes, when the product is free, you are the product. In this case, your open source community is the product.

In the worst case scenario, the personal data and activity patterns of your community members will be sold to third parties. In the best case scenario, your open source community is recruited by force into an army that furthers the network effect and makes it even more difficult for the next open source project to not use that proprietary service.

In all cases, you, as a project, decide to not bear the direct cost, but ask each and every one of your contributors to pay for it indirectly instead. You force all of your contributors to accept the ever-changing terms of use of the proprietary service in order to participate in your "open" community.

Recognizing the trade-off

It is important to recognize the situation for what it is: a trade-off. On one side, shiny features and convenience. On the other, a lock-in of your community through specific features, data formats, proprietary protocols or just plain old network effect and habit.

Each situation is different. In some cases, the gap between the proprietary service and the open platform will be so large that it makes sense to bear the cost. Google Docs is pretty good at what it does, and I find myself using it when collaborating on something more complex than Etherpads or Ethercalcs. At the opposite end of the spectrum, there is really no reason to use Doodle when you can use Framadate. In the same vein, Wekan is close enough to Trello that you should really consider it as well. For Slack versus Mattermost versus IRC, the trade-off is more subtle.

As a side note, the cost of lock-in is a lot reduced when the proprietary service is built on standard protocols. For example, Gmail is not that much of a problem because it is easy enough to use IMAP to integrate it (and possibly move away from it in the future). If Slack was just a stellar opinionated client using IRC protocols and servers, it would also not be that much of a problem.

Part of the solution

Any simple answer to this trade-off would be dogmatic. You are not unpure if you use proprietary services, and you are not wearing blinders if you use open source software for your project infrastructure. Each community will answer that trade-off differently, based on their roots and history.

The important part is to acknowledge that nothing is free. When the choice is made, we all need to be mindful of what we gain, and what we lose. To conclude, I think we can all agree that all other things being equal, when there is an open source solution which has all the features of the proprietary offering, we all prefer to use that. The corollary is, we all benefit when those open source solutions get better.

So to be part of the solution, consider helping those open source projects build something as good as the proprietary alternative, especially when they are pretty close to it feature-wise. That will make solving that trade-off a lot easier.

This article was originally posted on ttx:reloaded and was reposted with permission under a CC BY-SA 4.0 license.

User profile image.
Thierry Carrez has been the Release Manager for the OpenStack project since its inception, coordinating the effort and facilitating collaboration between contributors. He is the elected chair of the OpenStack Technical Committee, which is in charge of the technical direction of the project.


One of the things we increasingly face with closed source software is the desire that entrepreneurs have to take information about us and make additional income from it. The typical EULA is so wide-ranging yet fuzzy in its details, so you have no idea what rights you're giving up.
The individual person may not have the capabilities to search for unexpected consequences of using open source software, but when the code is available, you can be reasonably sure that someone will take a look at it to see how it works.

Great to see this article - I've been struck by this apparent contradiction in many communities, which promote "open" while requiring community members to adopt proprietary (closed) tools in order to participate... I lean towards adopting open tools from the ground up, *where possible*. I also think there's an emerging axiom (feel free to contest this, I'd like to hear arguments to the contrary): "Expedience is the enemy of principle". I think that choosing closed to boost open is a bit hypocritical. (and, for the record, we make extensive use of FOSS tools like, Rocket.Chat, Wekan and Kanboard, Gitlab, and others - going "open" with your tooling is *not* a step down.)

Thank you very much for the article! Very nice.

As an free software developer, I am facing these problems.
I am developing an AGPLv3 Git hosting solution ( and I am worried that nobody will use my solution because the market is full of closed source solutions. Or free core solutions, which are equaly bad in my oppinion.


The first question to ask anyone looking askance at a well-run open source project using a proprietary tool is: Do you use a Mac, or Windows, or a commercial Linux distro? If so, why do you use that proprietary tool?

Ideological purity is fine if that's your primary goal, but for most open source communities the goal is to 1) make software that's useful for you, and 2) try to encourage others to contribute to your project. And for any independent or small-scale FOSS project, you're probably doing this on the cheap as well. Thus, using whatever tools are most *effective* for your existing community is a good choice - proprietary or not.

Thus, many Apache projects use JIRA, since the maker has donated a free license to the ASF to run that powerful issue tracker. It's got far more functionality in an easy to administer platform (remember: the ASF runs it's own servers for this stuff) than other open source alternatives, so it's well worth using to get our project communities the functionality.

There are plenty of companies that will donate development-focused software licenses to bona fide FOSS communities, so it's worth asking around if you're in the market.

But I agree: it depends on *how* the proprietary tools affect your contributor's workflows. Anything that is 1) costly for developers, or 2) forces the project development cycle to be locked into that one vendor is definitely a danger - both to attracting new contributors today, as well as to longevity for your project when that vendor ups their prices.

Followup to this article: excellent point raised that any FOSS communities that do use proprietary tools should do the research and explain *why* it's a good idea, and how / if it affects IP rights of contributors. It's far easier for the community to collect this research and present it than hoping that every potential contributor will do it.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.