It's every hacker's dream, and thankfully, it's getting more common every day: being paid to work on your favourite piece of free software. But it's also fraught with controversy -- especially if you happen to be the maintainer of the project: Accusations will fly over conflicts of interest, political manipulation, and all kinds of other dirty whisperings. It's hard -- if not impossible -- to keep on the right side of everyone. The most important thing to do is keep yourself honest. So how do you take that dream job without losing your impartiality?
First, though, let's have a look at why companies are employing people to hack on free software. Surprisingly, it's more than just mere self-interest. Sure, it's good to have an in-house expert on your side. And there is, of course, a big prestige advantage to having the big names in a project working for you. For example, Red Hat employs Alan Cox and Dave Miller -- these guys know Linux, so this naturally improves Red Hat's credibility as well. There's also the importance of showing that you're serious about free software -- the best way to do so is to pour money into it, and arguably the best way to do that is to employ someone to work on it.
But there's also the fact that some companies really do employ free software hackers primarily because they love the software. As another random example, O'Reilly employs Larry Wall not just because Perl is a big part of their business, but also because Perl is just darned cool. In reality, I'd say most of the free software hiring that goes on happens for a mixture of the above reasons. (Incidentally, I've singled out Red Hat and ORA for examples of some of the reasons to hire in-house experts, but that doesn't mean that the reasons I picked are the only ones.)
One thing I've always loved about working on free software is that you can do it purely for the community, as a completely free agent -- doing what I want, when I want to, because I want to do it. But while that's a romantic notion, it's not totally borne out in reality. There are plenty of limits to my impartiality even if I'm not "owned" by a software company.
First, we don't really work for the community -- we work for ourselves. Sometimes we hack on software to scratch personal itches -- that's almost a selfish way to look at free software development. I fix something because it's stopping me from doing what I want to do with the piece of software. When I work on it, it's driven almost purely by my need. Sure, someone else may benefit from it if it's accepted into the main project tree, but I'm just making it do what I want it to do.
Sometimes, we do it for our own prestige and the respect of our peers. Whether we're prepared to admit it or not, seeing our names in the credits file gives us a good feeling. Being able to point at a chunk of code in a package used by people around the world and say "I did that" provides a sense of achievement.
There's nothing wrong with such "selfish" motivations for software development; it's how the best software comes together. And there are, of course, other reasons why we hack, not least because hacking's fun! (See Eric Raymond's Homesteading the Noosphere and Magic Cauldron for more analysis on motivations for free software development.) But we should never forget that the "community" begins at home, and our motivations perhaps aren't as pure as we think they are.
And when it comes to maintaining software, you don't need corporate involvement to have political squabbles. If you have a problem with someone's attitude on the mailing lists or their personality in general, it's likely you're going to be relatively more harsh with their patches, whether consciously or subconsciously. It takes a great deal of effort to retain impartiality when you're dealing with a complete pain in the ass. (Of course, there are exceptions -- I'm sure we can think of our own example of an evil genius: fantastic coder, but, boy, what a pig to work with...)
Nevertheless, there are certain freedoms you have when you're an independent hacker: Nobody can force you to work on a problem, or indeed do any work at all on a project. You can set your own work load, schedules and goals. Nobody can force the pace of development or release. (Those eagerly waiting for Linux 2.4 might think that this isn't such a valuable freedom.) Nobody tells you what you have to support, or what features you have to add. You do stuff either because it's cool, because it's needed, or because it's generally the Right Thing. The most important thing is that's it's nobody's decision but yours. That's the freedom you need to keep.
|
I'll let you into two little secrets here. The first one is that, no matter what the conspiracy theorists think, very little dirty dealing actually does go on when companies employ free software hackers. The problem is mainly a matter of perception. Any time you make an unpopular decision, work on some obscure piece of code, or jettison some unwanted feature, your employer will be dragged into the discussion -- it's obviously interference and pressure from them, right? Well, more often than not, it isn't.
To be honest, though, it doesn't really matter whether it was interference or not. The second little secret is that perceived problems are just as damaging as real ones. There's no way to prove whether or not a decision was influenced from on high when a lot of maintenance decisions come down to little other than personal taste. So if people feel uneasy about a company's involvement, that'll affect them whether or not there's anything untoward going on.
To keep the faith of your developers, you need to not just do the right thing, but also be seen to do the right thing: how your behaviour is interpreted is just as important as what you do.
Don't forget, however, that there are always going to be some people who love to stir up trouble. There'll be paranoid ones to whom everything is a plot by the evil corporates. You can't convince them. Don't waste your efforts trying. When these kinds of people start sounding off, the best thing you can do is forget it, delete the message, walk away, get a cup of coffee, count to ten, and just let it happen. Fighting back will only damage your credibility. If you are a respected maintainer, other people, independent developers, do the fighting for you. But usually, these types of people are the people who contribute little other than complaints anyway.
It might seem like it's impossible to be yourself when employed as a free software developer. Well, it isn't, and some maintainers out there do it extremely well indeed and gain almost universal respect. (I'm thinking particularly of ActiveState's involvement with Perl - despite recurrent mutterings of ActiveState bringing the end of Perl as we know it, the maintainers employed by them have been honest, fair, and thus extremely well trusted and respected.)
For a reasonable number of developers, it simply isn't an issue. And for you -- you're still the same person you were before you signed the contract, but you now have an extra responsibility to appear impartial. The most important thing to do is to bear this in mind, and think of how you should be going about your work. Here are a few suggestions as to how to spare yourself as much flak as possible.
The easiest way is to see if you can negotiate a "no interference" clause in your contract, which states legally that your employer will not put pressure on you to act in their interest while you're working in the role of a developer on a project outside their control. This won't mean much to them, and it shouldn't mean much to you: It's mainly protection for both you and them against outside accusations. Anything you can do to reassure your fellow developers of your impartiality is worth doing.
Second, delegate. Delegate anything your employer has ties to. If, for instance, you're working for a company that also makes hardware, try to delegate support for those platforms to someone outside the company. (Unless, of course, you're employed specifically because of your work on those platforms.) Involve people -- it's harder for people to accuse you of showing favouritism if you're doing what they want.
Keep honest; announce any intentions you have for the project openly and well in advance, and solicit comments from the other developers. Keep everything you do out in the open and subject to peer review, especially if it's the slightest bit controversial. If your project has a tradition of posting patches to a mailing list, follow it. Demonstrate that you're working for the good of the project and not just for your employer's good. It's important for people to see what you're doing, and that you're willing to have people scrutinise your work so that they can ensure this for themselves.
Above all, never, ever, ever be tempted to bounce something through quietly because it might be misinterpreted. You want to avoid suspicion, not arouse it.
What if your employer really is putting pressure on you to do something that you don't believe is right for the project? Well, you have to make them aware that this isn't the way things are done here. If they're truly into free software, they should be able to grasp this. In fact, it should be extremely rare that things should get past such a stage. If they do, then you have a problem.
Consult with your most trusted developers, and tell them exactly what's going on. They may be able to come up with a solution that accommodates everyone. You may want to take a back seat for a while, or warn your employer that they're putting you in an impossible situation -- when it comes down to it, it's not in their interests to do that.
Don't let me put you off. Being paid to do what you already do for fun is the chance of a lifetime. And for some projects and some people, it's the most natural thing in the world. But it is still an area where everyone involved is still feeling their way around, and the effects on the developer and the user communities can't be predicted.
However, it does raise ethical questions that you need to consider. The most important thing is that you bear these questions in mind, be yourself, be open, and be honest. If you're sure you're doing the right thing, it's more than likely that other people will think so too.
Simon Cozens is an Open Source programmer and author.
Discuss this article in the O'Reilly Network Forum.
Return to the O'Reilly Network Hub.
Copyright © 2009 O'Reilly Media, Inc.