Subject: Re: Who Owns You?
From: Bernard Lang <>
Date: Wed, 30 Aug 2000 18:21:22 +0200

Nice papers

BTW, being an academic and a research scientist, I do not see where it
differs from my own activities.  Research has its own dynamics, like
free software, and the results are, or should be freely


Bernard Lang

On Wed, Aug 30, 2000 at 12:16:25AM +0100, Simon Cozens wrote:
> Submitted for peer review. (And to make sure I haven't offended Bob or Tim.)
>                                  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

         Non aux Brevets Logiciels  -  No to Software Patents
           SIGNEZ    SIGN             ,_  /\o    \o/    Tel  +33 1 3963 5644  ^^^^^^^^^^^^^^^^^  Fax  +33 1 3963 5469
            INRIA / B.P. 105 / 78153 Le Chesnay CEDEX / France
         Je n'exprime que mon opinion - I express only my opinion