Using proprietary services to develop open source software

Using proprietary services to develop open source software

To succeed you must share
Image by : 

opensource.com

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.

3 Comments

Greg P

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.

Vote up!
1
Vote down!
0
lightweight

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 OnlineGroups.net, Rocket.Chat, Wekan and Kanboard, Gitlab, and others - going "open" with your tooling is *not* a step down.)

Vote up!
0
Vote down!
0
Catalin(ux) M. Boie

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 (https://rocketgit.com) 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.

Thanks!

Vote up!
0
Vote down!
0

Comment now