A community of technology community managers, leaders, and builders.

Should open source/free software projects use non-free tools?

Lots of infrastructure for developers (Github, Launchpad, Jira and other Atlassian stuff, Basecamp, Trello,…) is not free software. Much of the non-free software that people want to use (things like Stack Exchange or Twitter, for example) have free software alternatives (AskBot or pump.io) which are not quite feature-comparable or don’t have a critical mass of participants to get the social benefits.

In general, I have always held the view that if you want to be a community project, then community members should be able to participate in all aspects of the project, including maintaining, hosting & monitoring infrastructure. However, this isn’t always the easy option. The free software alternatives are missing features, have warts and corners that you keep bumping off, and I have gotten push-back that we’re forcing tools which are not the best available down developer’s throats. In some sense, this is the classic idealist vs pragmatist debate.

In another sense, I still remember Microsoft, Sun/Oracle, Bitkeeper, Sourceforge, Google and others disappointing when the markets or business leaders forced them to cut services or make money. Using free/open source tools is a hedge against future corporate wind changes. So I see the decision to use free infrastructure as a pragmatic one.

Still, I see both sides - so it seems like there might be a good discussion about this - should free software projects have a strong preference for free software toolchains?


1 Like

A minor nit-pick, but Launchpad is free software now, has been for many years

1 Like

Great question, @dneary, and a good opportunity for a discussion.

Like you, I used to have the view that we should also provide Open Source / Free Software (FLOSS) infrastructure and tools for FLOSS projects. My view on this has changed in the last four years or so.

Firstly, FLOSS projects have hugely diversified in recent years. While once the domain for deeply technical software (such as kernels) run by technical people with access to technology, the growth of Free Culture has resulted in people creating lots of communities that centralize around free access to technology and content. Thus, there are people out there running projects who neither have the time, interest, nor skills to deploy infrastructure and maintain it.

Secondly, tools define communities, access does. There are many Open Source projects out there for proprietary platforms that are written and maintained in non-free platforms. The key thing is that these tools are available to anyone who wants to participate and in many cases offer advantages over free tools.

Of course, the risk with non-free tools and platforms is that they change and the community is hung out to dry, but I think that is a general issue with software, both free and non-free…it is always changing, and when major platform changes happen, usually there is enough time to react and change course.

Thoughts from others?

Interesting topic. From my point of view, there are two main reasons for keeping the infrastructure used by free / open source projects as free / open source as possible:

  • Control. At some point, having full control over the infrastructure may be an issue. If the project grows large enough, this is going to happen for sure. And when the project is evolving, forking, combining into new projects, that control may become a real pain in the neck. I want to relate services, but they are on a infrastructure I don’t control: I can’t. The service provider decides not to provide the service any longer, and migration is difficult / impossible: I’m done. I want to twist details in how tickets are working: I can’t. And so on.

  • Innovation. Almost by definition, core innovation in proprietary products can only be done by the product owner. But infrastructure for free / open source software is a moving target. It has been in the front wave of tools for collaboration during the last 20 years, and it is still there. In free / open source software projects we have, well, developers, who know what they want, and who know how to build it if they want. It is not casual that many large free software projects either produce and maintain their own infrastructure, or adapt some other.

But I’m pretty much sure you know all this :wink: Those are just a part of the advantages of free software. Please, forgive me if I become emotional here, but after many years trying to explain why free / open source software is in many cases a better option, it is a bit strange to me to explain this to a part of the free / open source software community. And here, I’m not talking about people participating in this thread (exchanging opinions is always a good thing ™), but to people who in one talk try to explain as much as possible why it is a good thing that their product is free / open source software, and in the next one explain why they are very comfortable developing in a proprietary system.

All this said, I understand why many free / open source software is developed in proprietary infrastructures. I’m a happy user of github, and some other proprietary services. As @jonobacon comments, it is a matter of service. If I find what i need, at a convenient price, and I cannot get a similar service on free / open source software, well, I have to decide. In some cases, I try to foster the creation of the free / open source option. In others I just use the proprietary service as I can… But I try to be always ready to switch when a free / open source alternative becomes viable. And that’s just because it is in my own interest, and in the interest of the whole community.
Finding ways of providing services fully hosted by free / open source software, in a sustainable and competitive way is another story. In some cases of success, in some other not…

Well, sorry for the length: you touched me ;-). Just my two cents…

I think that as a society, we need to question any use of proprietary software, period.

This has been the biggest challenge in getting Snowdrift.coop going. We reached out early on to the FSF community and learned to be especially thoughtful about this. We are still on GitHub, but we’re also on Gitorious (which is Free/Libre/Open — FLO), and we point our links to Gitorious. We started using GitHub issue tickets but have switched to building an integrated ticketing system that meets our needs and is, of course, FLO. We even point people to the Haskell Wikibook as the place to go for learning rather than pointing to proprietary textbooks.

In all this, we realize how important it is for us to show others how we made our decisions and be a model / guide for anyone else to follow. If we can figure out how to effectively stay FLO, we can show others how to do what we did.

In the end, I think the most important element is acknowledgement. Every FLO project should accept the burden of identifying and explaining their use of non-free tools, in my view. Otherwise, people often aren’t clear about what is or isn’t FLO. But given the lack of feature-parity, asking for this type of transparency and acknowledgement is as far as we can really demand typically.

Thanks to for being the kind sponsor for this forum!