Who Owns You?
Pages: 1, 2
Perception and reality
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.
Keeping clean
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.
Go to it!
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.
