Why Do It? The Motivations Behind Free Software

I have been developing free software for a long time, originally as an independent freeware author in Windows (oh the stories I could tell you there) and more recently in Linux. Why do it? And what are the values and principles that are most functional when working for free? I thought I would take some time out to share the strategies I have developed over the years that make this work.

First, why do anything for free? I think this is a core question to address before even contemplating working for free. My answer to this is that I don’t really believe that money as motivation works to the benefit of humanity. That system, which in my world is a relic of the past, leads to exploitation and corruption. The people who make the most money in this world typically do the least work, certainly the least beneficial work (usually exploiting people, other life forms, and the environment). Work produced based on the promise of financial reward is increasingly of low quality, designed to fail, and primarily seeks to make more money and create dependence. Any money made (usually most of it on the corporate level) is further used to enslave and exploit, as well as to destroy the very planet we depend on for life. (Do you know how many products are designed to fail after a period of time, and thus need to be manufactured again and again, just for the sake of profit?) I think if humanity is ever to eliminate poverty, exploitation and environmental suicide, and provide real means for people to better themselves, the money system has to be replaced, and that has to begin somewhere, and soon. I believe some approaches common in Linux are good examples of what community-based effort can produce. Regardless of your financial standing, you can download great software, learn and grow. Being a contributor to that community has many rewards, immediate and also in terms of long range dreams of what is possible.

Most of us come from cultures that aren’t based on free contribution and availability, and are based in competition, so some adjustment of values and motivations is necessary to work effectively in such a community. Especially professional software developers are accustomed to being very well-paid for their time and efforts. I find that if they bring their normal motivations and values with them into the free community, they wind up feeling resentful and frustrated, and so do their users.

Software development involves hard work and real effort. I love getting creative on the computer, designing good tools and innovating, and that is my primary motivation – to make something cool. A painter loves to paint – just try to stop him from painting! I share some of my work as public projects as a way of giving back to the community and contributing to the growth of Linux. Yet even the most fun creative project involves drudgery – chores which need to be done to make the overall project polished and usable. Further, for software to be more than just someone’s mostly-broken pet project (which if you’re lucky, you can even build with the instructions provided), it requires continuous efforts in publishing, support, documentation, web site maintenance, forum participation, etc. At times, it’s simply a LOT like work.

When people come to this work from traditional employment-based backgrounds, they tend to become resentful and quickly disillusioned. Normally they would keep thinking of their coming paycheck or their needs as a source of motivation, but there is not much pay involved in free work. If you think you will get rich off of a popular Linux project, guess again. While some developers manage to scratch out a living from donations, and corporations exploit it in the business environment, in general donations to developers are rare events, at least in my experience. My donations page has received only a handful of donations in the past year, despite thousands of people using my software daily. My software is offered genuinely for free, so I don’t have high expectations in this area – it’s a treat if a donation comes in, but I mostly avoid resentment at the tip jar being ignored. But if your motivation for doing the drudge work is money, you can easily begin to feel misused, unappreciated, ill-treated, and enslaved. You begin to ask, “Why am I devoting hundreds of hours to this? Why am I investing my time and energy?” This resentment can easily build until it paralyzes your work, and you forget your original reasons for creating it.

Simply put, the motivations for doing free work need to be different, because the conditions are different. In some cases, your expenses of maintaining servers and so forth can exceed what little income exists. If you depend on monetary reward, you’ll be disappointed. Further, there is little reward for success. Even if your project becomes hugely successful and gains many thousands of users, your ‘profits’ don’t increase much, while your workload does! More users mostly mean more work in terms of greater activity, bug reports, feature and support requests, etc. (I originally almost decided not to release SpaceFM publicly, expressly because I knew it would be popular.) Yes, it’s gratifying to see people appreciating your work, and knowing that you’re contributing something useful. This can be a little ‘ego boost’ to help push the work forward, but it’s not very tangible, and won’t feed you. Also, even if you make a great piece of software, it may never get much recognition or use – you won’t have much of an advertising budget. So pats on the back may be rare even for the finest work – don’t depend on them for motivation.

Beyond this, while most users are appreciative and often take the time to give you a ‘thanks & well done’, not all users will make you happy. You’re dealing with the public, and this can take patience. A few users will even be obnoxious and rude. Back in the days of Windows freeware, I even had a user threaten to sue me, alleging installation of my software broke their system. Despite all the helpful and kind users, just a few negative experiences can cause real resentment toward ‘the users’, especially if your skin hasn’t thickened yet, or you’re already feeling resentful at working for free.

Because of some of these dynamics, people often believe that ‘free == junk’. If it’s for free, don’t expect my product to be of high quality. You’re lucky to be getting anything, so don’t expect excellence in something that is offered for free. Yet this is a trap, because it’s no fun producing junk. It’s much more rewarding to take the time and effort to produce something that shines and really works well. Yet a resentful developer won’t want to make that investment, and thus will not reach that rewarding state of accomplishment.

Sounds pretty bad at this point, doesn’t it? Hard to imagine why anyone would work so hard and put up with the hassles without monetary compensation. Yet actually I find free software development very rewarding, and that is why I have done it for so long. It’s all a question of motivation, and there are some unique rewards not found elsewhere.

Motivations That Work For Free
As I said, my primary motivation, especially in a larger project, is to make something cool – something that demonstrates excellence and innovation. Why? Simply because a painter loves to paint, and paint well. Also, genuinely serving people is always rewarding – it’s a human thing, we want to help, to contribute. Making junk is not rewarding, especially on a personal level. (Even when people work for money this is true, which is why much employment is un-gratifying.) Taking the time to dot the i’s and cross the t’s, and produce something that is genuinely useful and reflects my creativity and attention to detail is something which I have come to know as personally very rewarding, and that is motivating. This is my art, in a sense – I want it to be excellent.

Much falls out of that primary motivation. For example, I see bug reports, negative feedback, and feature requests in this light. These people are contributing to the project, helping to make it better. Often users are almost apologetic for reporting bugs or making requests with free software – they too suffer from a sense that they are merely asking for something for free, that they don’t deserve it. They will often be surprised when I thank them for a bug report or request, and say, “No, I should be thanking you.” Thank me, sure – I’m contributing – but so are you. I encourage users to contribute in these ways because just as my work helps to make the project excellent, so does such input from users – it is essential, in fact. Especially when software is free, the user is the whole reason software exists – the user is its reason for being. (Ironically, commercial software forgets this, as its reason for being is to make the developer or his/her boss the most money.)

As developers, we often spend time fixing bugs or implementing features that don’t affect our personal use of the software. Working for free, this too can build resentment. Why am I spending my free time working on this aspect that doesn’t affect me? Yet I look at this from the higher perspective of what serves the software, what helps to make it the best it can be (within what I’m willing to invest). Users may not view it this way – they may just want a feature or bug fixed for their own use. Yet I review bugs and requests with an eye toward how they serve the software, and by extension the users (who again are the whole point it exists). So contribute to the software by making reports and requests, yet remember not to make demands, which are not appropriate in a free context. At any rate, I never view them as demands, even when they are worded imperatively – to me they represent people making contributions to the software in the form of feedback and ideas. Thus I appreciate what another developer may discourage or resent, because I remember to set myself free.

Beyond the ‘make something cool’ motivation and rewards, there are many perks to free software development that can create an entirely novel context of what ‘work’ means, making it a very enjoyable process, and washing away some of the stains of exploitation which we all carry. In this sense, contributing to free projects can be liberating in unequaled ways. I still have to continuously remind myself of some of this, and remember to take this perspective, as it’s easy to fall back into conventional modes of thinking.

The Perks
Working on anything free, it’s important to assert your rights. Working for a boss, one is at the mercy of another – told what to do with one’s time and efforts, often working on things one disdains, at times when you’d rather be doing something else. This creates an atmosphere of misery, and many developers bring this atmosphere with them to free development. They are in this habit of being driven by others’ demands, so they view users and ‘co-workers’ as telling them what they have to do. This is why developers often get so cranky at bug reports – they’re being handed more work, demands! Eventually, when you’re not being paid, this can spell deep resentment. Even I fall into this trap sometimes, until I remind myself that there’s nothing I have to do!

As a free software author, my time is my own, and I’m my own boss. This is especially true because I tend to be a one-man band, not usually contributing to larger projects that incur expectations and timelines. And because I’m working for free, not working has no financial consequence – in that sense it’s even freer than being your own boss in business. If at any time I feel “I don’t want to be doing this”, I simply walk away from the computer, or put those files away for now. This means that my work is not a product of misery, of me forcing myself to do something at a time when I’d rather be doing something else. If I’d rather be doing something else, I do it! Thus when I am working on the project, it has my natural attention and motivation – I’m interested and engaged, enjoying the work. I think this contributes to its quality – it becomes a labor of love.

You might think I’d never get anything done under those conditions, but in fact it’s natural work for me, and at least some of the time I want to do it. I would like a bumper sticker: “I’d rather be working on SpaceFM“, because I really enjoy it. And when I stop enjoying it, I quit it for the moment. If I stop enjoying a project routinely, I quit it entirely. Of course, there are chores and drudgery involved in anything useful, aspects of the work that I can’t say I would prefer to do. But if they are a necessary part of something I want to add or make more functional, then I am willing to do the chore because I want to achieve the larger goal. Overall the process is still one of enjoyment. It’s sort of like cleaning your house or fixing your car – you may not actually ‘enjoy’ vacuuming per se, but you enjoy having a clean house to live in or a car to use, so it’s a necessary ingredient of a larger joy. Thus I do manage to get most of the chores done, often promptly, because I want the enjoyable result – the rewards. So in a sense you do work for rewards, but the primary reward is no longer money.

You may notice that I rarely involve myself in estimates of when something will be done. I may speak of general plans, and things coming up soon, but as a free software author I simply don’t do deadlines – they run contrary to my way of working. When selecting what in a project to work on next, I do consider what most needs attention, but I also consider what I simply feel like working on at the time. Sometimes I’m more in a mood for coding, or web site maintenance, or just answering questions and chatting about potential improvements. Other times I don’t feel like working on it at all, sometimes for extended periods, so I don’t. While bug fixing is usually a chore, sometimes I’m sufficiently motivated to knock a few bugs off the list – that too can be rewarding, and I know it serves the software. If I’m going to produce something of quality, bug-fixing occasionally needs to be done – it’s part of the ‘job’. If I don’t want that job, I wouldn’t share the project publicly in the first place, or would drop it.

I also almost never accept bounties, or promise to do something if a particular sum is paid on delivery. You’ll note that my donations page reminds you that “donations are not associated with feature requests, but feedback is always welcome”. I view donations as a ‘thank you’ and as general support of me and my projects – and it does boost motivation when I see a donation roll in. Just because a project is available for free doesn’t mean you can’t pay, it just means that your forms of contribution are voluntary too (and not all involve money). It does feel good to get some cash, as any developer will tell you. In fact it tends to be all the more appreciated, because you know it wasn’t required. But I find making promises to do something for pay interferes with my way of working on free projects, so I mostly avoid bounties. No one can effectively force or pressure me to do anything in this area, and I like that freedom. It’s one of the perks of free software development – guard it.

This may sound like over-analyzation of motivations, but it’s important to get and keep your head straight on these issues, as it makes a huge difference on a day-to-day basis, because it is a lot like work. Because I don’t really force myself to do anything, no one else can successfully force me, and I know that I genuinely want to be doing what I’m doing. Part of managing this level of freedom in time involves good project management. I need to be able to let some things pile up without losing or forgetting them. In addition to issue trackers, I use casual (usually downright messy) lists to remind me where I left off, what high priority items are pending, etc. So when I am able and in the mood to devote a few time clicks to the project, I can choose wisely where they’re spent.

I tend to like things to work right! I want to achieve a level of excellence – it’s rewarding, and I take it personally when it fails. I feel that if I’m going to publish something, basic support is part of that effort. So it’s hard for me to leave things go that ‘should’ be addressed – this is actually something I have to work at, letting things go. Yet if I don’t, the ratio of users to developers will overwhelm me, I’ll burn out, and I’ll become resentful of the work. It may only take a minute to add a bug report or feature request, or even to throw something on a list myself, yet each of those items can take hours to address. Thus the TODO lists and open issues tend to grow faster than items are removed. This can be discouraging if one doesn’t take an effective approach.

I do NOT accept “If it’s free, excellence doesn’t apply.” I believe working toward excellence in any product is the whole point, and rewarding. Yet there are also realities of time and will, and if you don’t work effectively with what is available, you’ll burn out or lose motivation for the project entirely. Thus a balance needs to be achieved between the desire for excellence and the investments one is willing to volunteer. If not, a free project will become sidelined or ignored. And this too is okay – as a free author there really is nothing you have to do.

Another perk to free software development, and a good routine reminder: it’s my program. This is my software and I’ll do what I want with it. I’m the captain of this ship, the benevolent dictator. Others can offer suggestions and even judgments, but the decisions are mine. The reason this is important is that often without meaning to, some users can become very pushy, applying pressure to a developer’s inclination to make things work well. Usually they have their own vision of the software, or they’re having problems which they feel ‘should’ be fixed. Perhaps they have a sense of quality and want things done ‘right’. Whatever the reason, in some cases people can become almost hostile in their attempts to get you to do a particular task, or make a particular change, forgetting that they are making demands on your personal time. As a volunteer, it’s easy to resent this. As a free software author, it’s important to retain command of your project, and not allow others to define it or your tasks. Always remind yourself and others that since it’s open source, they are welcome to create a fork and take it in new directions too. “While I appreciate your feedback, you are not my boss, and this is MY project.” Most users are not like this at all, but all it takes is one to begin building resentment toward all. Ultimately, this robs you of enjoying your project and the community – don’t let them rob you.

While perhaps not a perk per se, another strategy that works is to advertise your limitations. In commercial environments, this is not done. You want people to try and buy your product – you’re not likely to point out what it can’t do, or why they won’t like it. Yet with a free project, I get no kickbacks from having more users. And if users try my software with warped expectations, they will often be upset and negative, in part because they feel their time was wasted trying a tool that doesn’t do the job. While I don’t typically make long lists of limitations, I do try to make clear in web sites, screenshots, and in documentation exactly what this software is about, and what niche it fills. I don’t want to waste my users’ time, and they don’t appreciate having it wasted. It’s much better to clearly define the tool without embellishment. Nor is it necessary to defend or fight for it. This is another habit that developers import from other environments. While you tend to be a fan of your own software, there is simply no reason to fool anyone when its free. The only reason to advertise at all is to see your work put to good use where applicable.

Another strategy and perk I tend to use: use free stuff. I use free web hosts, free issue trackers, free forums, free servers, etc. Many commercial organizations involved with Linux, such as github, offer free services to the developer if your software is free and open source. Rarely do I invest money much in the process of developing and maintaining my software.

In short, get your head straight on what you’re doing and why you’re doing it, and free software development can be a tremendous experience. Having an audience, especially a large audience, can be rewarding in many ways to any artisan, and free software development is no exception in this. Not only is having your work appreciated and used personally rewarding, but the effects of community contributions and ideas to your projects can cause them to grow in directions you didn’t expect. In a sense, users become co-authors of the projects, and this is a very different experience than developing something in a vacuum (which I also know from the projects I don’t take the time to publish). Plus, it’s simply nice to work on something without a need for money involved – it’s liberating to experience ‘the other side’.

Keep expectations low in terms of financial support. Depending on how hard you push for donations and other factors, you may receive some support, but mostly the community doesn’t kick much in. I think to some extent this can use improvement – free software authors need to pay their bills too, and if no one is willing to support them in cold hard cash, opportunities become limited. Remember that “free software” doesn’t mean it’s free to produce, or that you can’t contribute financially, just that what you contribute is voluntary. I believe this is one reason why Linux is being overrun with poorly developed, corporate-driven products which ultimately undermine it – people have come to take the developers for granted. So I do encourage users to support your free developers. Yet I also advise developers to not expect a lot in that area, and to not depend on it for motivation.

Don’t let the lack of financial rewards rob you of a very rewarding experience. If you enjoy writing software (or anything that contributes to the Linux community), do so for your own reasons, and remember the perks of working for yourself, for others.