Subject: Re: Who Owns You?
From: Bob Young <>
Date: Thu, 31 Aug 2000 20:25:21 -0400

> Submitted for peer review. (And to make sure I haven't offended Bob or Tim.)

Fine by me.  


>                                  Who owns you?
>    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 pretty fraught with controversy, and
>    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, and so the
>    most important thing to do is keep yourself honest. So how do you take
>    that dream job without losing your impartiality?
> Why is it happening?
>    First, though, let's have a look at why they're doing it: the reasons
>    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 in having the big names in a project working
>    for you: to take a random example, Red Hat employ Alan Cox and Dave
>    Miller - these guys know Linux, and 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 primarly because they love the software - as another
>    random example, O'Reilly employ 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 as examples of some of the reasons, but
>    that doesn't mean that the reasons I picked are the only reasons for
>    employing Larry and Dave and Alan.)
> What impartiality?
>    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 it, 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.
>    Firstly, we don't really work for the community - we work for
>    ourselves. Sometimes we hack on software to scratch our personal
>    itches - that's almost a selfish way to look at free software
>    development. I fix something because it's stopping me 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 you're prepared to admit it or not, seeing your name in the
>    credits file gives you 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' gives you a sense of achievement.
>    There's nothing wrong with such `selfish' motivations for software
>    development - it's how the best software comes togeter - and there
>    are, of course, other reasons why we hack, not least because hacking's
>    fun! (See Eric Raymond's [1]Homesteading the Noosphere and the
>    [2]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.
> 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
>    maintainance 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 which 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 be avoiding
>    suspicion, not arousing it.
>    What if your employer really is putting pressure on you to do
>    something which 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 which
>    accomodates 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 which 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.
>      _________________________________________________________________
>    [3]Simon Cozens is an Open Source programmer and author, and solves
>    the problem by staying on the wrong side of everyone.
> References
>    1.
>    2.
>    3.
> -- 
> Given an infinite amount of monkeys an infinite amount of time, an
> infinite amount of drafting supplies, and an infinite amount of crack,
> they'd come up with Downtown Chicago. --  David Jacoby, in the monastery

Red Hat, Inc.------------------------------------------------
Phone 919-547-0012 x227			Fax   919-547-0027
P.O. Box 13588				email:
Research Triangle Park, NC 27709