Why We Need to Pay for Linux/FOSS

If you rely heavily on open source software, should you be expected to contribute financially to its success? What if the project coordinator is specifically seeking out donations to keep things afloat?

These are questions that I think most of us avoid. I believe that this avoidance might make sense to some end users, since no one wants to spend money where they don’t have to.

In this article, I will point out how this way of thinking is why so many promising projects don’t last over the long term. While some open source projects manage to find successful ways of funding themselves, many others do not – a loss for all Linux users.

Free as in freedom

I believe that everyone that follows open source news has their own view about what open source means to them. Unfortunately, this has led some people to the belief that open source software must be made available to everyone, even to those who could contribute financially, yet choose not to.

Because most open source projects are stereotyped as “freeware” by newer users, there’s a sense of entitlement that must be overcome. If a software application is meant to be freeware, I imagine that the license selected would then reflect this intent. That developers of open source projects should expect those who can help out to do their part, however they can.

My take on open source software and the collection of licenses that it encompasses, is that we as a community need to show support for those applications that we enjoy. For some of us, this means offering to contribute bug fixes. Other people might instead offer to share their knowledge in community forums or perhaps offer a Paypal subscription payment to help offset of the developers’ expenses.

Even though some open source projects are considered hobbies, if a donation button is offered on the website, it might be nice to send a few dollars in the developers direction as a kind gesture.

Now I would be remiss if I didn’t mention that many projects targeting the needs of enterprise users already receive financial support from various interested companies.

And why not? When you consider the value these companies gain from the money they’ve spent, the financial support from end users should also be considered a no-brainer. Doesn’t it also make sense for people interested in popular open source applications to follow this enterprise-led example?

Open source developers need to be more aggressive

When it comes to project sponsorship, open source developers need to be crystal clear about what they’re seeking. Sadly, some developers who claim to be seeking financial support are entirely too subtle for most people to care.

This leads to projects falling through the cracks and eventually, becoming little more than a memory.

I believe that asking for a random donation is a waste of time. Instead, I’d like to see developers explaining that the next release of their software with ___ features is a mere $___ away.

The best part about that latter approach is that no one is being hounded for money! Because if you’re happy with the current release of the software, then you don’t have invest in the next release of that application. This approach puts the end user in the drivers seat, while also ensuring that the software project has a shot at seeking the funding they need.

Software bounties 2.0

Anyone who has been part of the open source community for any length of time is familiar with the term software bounty. The idea is that an interested party posts a bounty to be offered upon completing a task on a software project.

Often this approach is used for bug fixing or other related tasks, and are generally created by end users rather than the original developer. Handling this type of stuff can be challenging, since there’s so much room for interpretation.

This is why open code markets such as RentACoder offer such a valuable service. This sort of coding marketplace isn’t perfect for every situation, but it does present us with a working model, if nothing else.

Now here’s where I see a smart developer tapping into this type of resource: features and functionality. I can think of a couple of projects I would contribute more money to myself, if I had a way of knowing that my funds would go directly to addressing specific feature requests.

If a project developer were to offer me a donation button for a missing feature I wanted, I would be very happy to contribute more frequently. Obviously, this type of thing would have to be developer approved in order to prevent people from donating bounty money to functionality that simply isn’t possible.

Short of that small issue, a bounty system would be a smashing success for projects such as Linux video editors, Gimp, and other open source projects where features are often requested.

The above scenario covers one approach to handling features requested frequently. It’s pretty straight forward. Unfortunately, things can get dicey with trying the same type of approach with smaller features. Existing features might be better presented with user specific tweaks. Custom Blender based 3D titles in OpenShot video editor, for example. Even a branded version of a specific open source application would be a smash hit.

The opportunity for both developer and end user in this space is genuinely limitless. And yet surprisingly, hardly anyone is doing it!

To be fair, this might be an area where heading over to a coder marketplace would be a better use of time, since the developer of the related project may already be too busy.

However, for those unemployed open source developers looking to make a name for themselves, this is a really great income opportunity. Projects like Miro have been doing this for some time. Which is why I think it’s a great idea for an additional revenue stream.

Why not Linux distros?

The last area I want to touch on is the need for a branded USB wifi dongle. This is completely brain-dead simple for any distribution to offer. Atheros and Ralink, among other chipset vendors, would be happy to set up such a deal. Simply insert the dongle inner-workings into some branded plastic and you have a fully supported wireless device with your favorite distribution’s logo on it.

Anyone telling you that it cannot be done hasn’t investigated it thoroughly – I have. I’ve spoken to chipset vendors, looked at 802.11n options natively supported and I’m saddened to tell you that this could have been offered years ago.

Even worse, it’s practically “drop-ship easy” thanks to most of the chipset vendors coming from areas of the world desperate for new customers.

Think such a thing isn’t needed? I can direct you to hundreds of forum posts that would indicate otherwise. These forums, filled with posts of individuals who purchased devices that do indeed provide Linux drivers. Despite these drivers being offered already, the end user still has to compile and configure many 802.11n devices.

Now obviously, most Linux distribution developers don’t have time to chase down every possible wifi bug one encounters. This is especially true when you consider how bad the wireless chipset revision/version system is.

Look at the back of most USB wifi dongles, you’ll find it likely has a version or revision number on it. This means that while the model number may be the same, changes to the chipset are likely and undocumented.

A decision needs to be made

Over the years, I’ve worked with a number of open source projects. In that time, I’ve come to an interesting conclusion. The brains behind these fantastic projects may be successful coders, but they’re often lousy at funding their own endeavors.

So my thinking is that even if an open source project is formed as a hobby project, it would still be nice to offer the end-user an option to keep the project alive with some extra money. Should the developer not want to keep the money for themselves, they could simply offer the funds to a worthwhile charity.

Back on the user side of things, we need to decide whether we’re going to continue perpetuating the stereotype that open source enthusiasts are just freeloaders. As stated previously, this is a vision for the future that can be overcome by simply opening up our hearts and our wallets.

Because if we don’t, who will be around to pick up the next dropped open source project that many of us depended on? Consider this food for thought.