Subject: Re: Dealing with the Open Source community
From: kmself@ix.netcom.com
Date: Sat, 18 Nov 2000 04:54:40 -0800
Sat, 18 Nov 2000 04:54:40 -0800
on Fri, Nov 17, 2000 at 03:40:08PM +0000, Simon Cozens (simon@cozens.net) wrote:
> Here's something to think about, and I'd appreciate hearing your
> thoughts.  
> 
> More and more "old guard" commercial software businesses are trying to
> get into open source, pushing out their old software or getting
> involved in development; publishers, support companies, consultancy
> companies, recruitment agencies, and so on, are all getting involved
> with the Open Source community.
> 
> And, on the whole, they're making a mess of it. This is because
> they're used to dealing with a certain type of corporate culture, or
> development culture, and they know what they expect from programmers
> and those working in the community - but they're wrong. Our community
> is not like their expectations.
> 
> What I'd like to do (and I know Skud has also expressed some interest,
> and anyone else can play that wants to, this is Open Source after
> all...) is to write an article or a guide (which may blossom into a
> complete book, God willing and time permitting) explaining the new
> world order, the way old style companies should interact with the new
> style technocracy, a sort of 'Dealing with the Open Source Community
> HOW-TO'. 

Required reading:  JWZ's Mozilla exit essays "nomo zilla" and "nscp/aol".  
    http://www.jwz.org/gruntle/nomo.html
    http://www.jwz.org/gruntle/aol.html


Dumping dead product on the free software community doesn't bring it
back to life, and broken code developed in a proprietary environment may
well be beyond resucitation.

There are structural requirements for code going into a software
project.  JWZ hits on several of the key points.  Brian Behlendorf
touched on others both in his  Open Sources  article (O'Reilly, 1999),
and in his July, 2000 O'Reilly Open Source Conference presentation.
Project management is another key component of success, addressing both
developer and end-user needs.

> Here are three sample ideas I'm planning on expounding:
> 
> i) Personal contact is everything.
> 
> If you want to get someone from the open source community on your
> side, you need to engage with them personally. 

Some agreement.  Though I'd put good code and an interesting challenge
above feel-good.

<...>

> ii) Your status means little.
> 
> With very few exceptions, status from the commercial world does not
> translate to status in the open source community.

Mild disagreement.  Status translates.  Attitude doesn't.  Or rather,
bad attitude gets old fast.

A large part of this might be mitigated by corralling your legal team
and giving them this dictum:

   Here's what we need to do.  Provide us the tools to do it.  *Don't*
   tell us we can't do it.

What you need to do is:

  - Release your existing code (or a reasonable portion of it).

  - Provide means to get community code in.  Under generally accpetable
    licensing terms.  And that means *not* writing your own but going
    with an existing model:  L/GPL, BSD, BSD/MIT, and MozPL provide a
    pretty broad range.  If you *have* to write your own, strongly
    consider a dual license.

  - Enabling.  No.  Mandating, public communication in all details of
    development.  JWZ and Brian both get into this, it's been noted
    strongly in other projects as well.

Too often, lawyers play (or are allowed to) the role of dictating terms
and conditions.  Simple truth is that they are agents of the firm, like
any other employee.  While I *would* strongly encourage paying heed to
counsel, particularly concerning risks and possible legal threats,
piling legal baggage on the free software effort is going to seriously
impede progress.

One option I'd strongly consider would be divesting the development
effort entirely into a freestanding organization.  Netscape did this
with Mozilla, Sun may or may not be doing this with Java and/or
StarOffice (the intent apears to be that they mean to), IBM effectively
adopted an external organization in the form of the Apache group.  You
don't need to own your development effort.  This may reduce or eliminate
many of the legal concerns arising from it.


> iii) We do this for fun.
> 
> The vast majority of programmers, writers, and other helpers in the
> open source community do it for one simple reason - fun. We don't get
> paid for it, we don't *have* to do it. 

I dispute the last sentence, particularly the first clause, strongly.
Free software wont scale if it can't be a livelihood, and hasn't scaled
without becoming so.  Free software will be written by people who are
being paid to write it, whether directly through an employer, through
contract work, or on assignment.  

That said, I have to agree that if it's not fun, people will bail.  One
of the best things about free software is that it does offer a promise
of making programming fun again.   Lord knows, I walked from my prior
life in large part because it wasn't fun.

But free software programmers, like any other kind, have bills to pay,
families to feed, and dreams not (necessarily) existing online to
fullfill.  And that takes dollars, euros, yen, and rupees.


-- 
Karsten M. Self <kmself@ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Zelerate, Inc.                      http://www.zelerate.org
  What part of "Gestalt" don't you understand?      There is no K5 cabal
   http://gestalt-system.sourceforge.net/        http://www.kuro5hin.org


["application/pgp-signature" not shown]