Subject: Re: Fwd: Wall Street article on a new Cooperative
From: Brian Behlendorf <brian@collab.net>
Date: Tue, 20 Apr 2004 10:23:07 -0700 (PDT)

On Mon, 19 Apr 2004, Adam Turoff wrote:
> As I understand it, it's about N companies coming together to split the
> cost of developing, say, call-center software.  They each pony up 1/Nth
> of the cost, rather each pay $X to a vendor for licenses.  The vendor
> only spends $Y to develop the package, so the premise is that $Y/N is
> much less than $X, even though $Y > $X.

Not really.  Think of it this way: most companies have some asset
repository of the software they build, intended to track these like any
other asset tracking system might, and as nearly an afterthought to allow
for re-use of the system.  Many, particularly in the financial services or
health-care industry, *must* maintain repositories like this for
auditability purposes - for example, the FDA certifies software used in
clinical trials.  Whether or not those organizations actually see reuse
internally is another question.

In Avalanche, companies pay $30K to create a meta-repository of code each
company feels comfortable sharing with others.  There's still a
"free-rider" problem - if two competitors are both members of Avalanche,
one participant's code may be valuable to the other, even if
non-differentiating (actually, especially if non-differentiating) - but
companies who are not on the bleeding edge of IT innovation are probably
much more comfortable sharing code with the limited community than the
wide-open internet.

But to get back to your point: this isn't necessarily about hooking up
with other parties to jointly develop new software.  That may indeed
happen, as reuse leads to bug-fixing leads to feature-adding.  But it's
opportunistic rather than pre-planned.

[...]
> Non-tech firms write a small amount of general purpose software, because
> it has low ROI.  It does happen, like BestBuy's AppTalk, but I don't see
> how paying $30K/year to pony up to the bar is a benefit for BestBuy or
> for AppTalk, when they could release that software as open source, and
> get more benefit for less money.

*You* are convinced of the truth of your last sentence, but I'd bet these
companies are preferring this private source model precisely because they
aren't convinced of that benefit.  Instead they hear about Open Source and
they see lawsuits, flame wars, and half-finished software that might be
promising some day.  That's not so compelling.  :)  All that might still
happen in this private community, but there may be parts to the agreement
they sign when they join up that stave off those problems, in a way that a
public project can't.  I don't know, but that's what I'd do if I were
running this.

On Mon, 19 Apr 2004, Matt Asay wrote:
[...Matt said, "how is this different from Open Source?" ...]
[...I said, "because there is no right to fork." ...]
> Please explain, Brian.  I assume that Avalanche allows any amount of
> forking within its code base/contributors.

I'm sure it does.  But the inability to fork *outside* the organization is
quite significant.  With any Open Source project, if that project
leadership goes astray, then participants with different objectives can
head in a different direction.  Nearly every major open source project
started as exactly that kind of institutional "fork".  This ability to
part ways is a big deal - it means that the risk of investment into a
community is low, since you can always go somewhere else without having to
start from scratch.

That difference is not just academic, nor based on overparanoia.  It's the
fundamental reason why if they call this "Open Source", the actual Open
Source community will have a problem.

I actually do not think this is a bad idea at all - we (CollabNet) build
networks like this all the time.  Rarely is such a community limited to
one company; usually it's a company and 1, 5, or 200 business partners.
Or it's fully open source, but there are lots of valid reasons why that's
not an option for many companies.  So, showing the companies the
*practical* advantages to sharing code before convincing them of the
*strategic* reasons to share it with the rest of the world is noble.  So,
I wish Avalanche well.  What I hope is that the member companies don't
judge the community by the same metrics they might apply to the open
source community, as getting the necessary developer-interest critical
mass within the smaller circle is going to be tough.  I also hope that
companies involved don't decide that this is "good enough" for the
components that really should be shared publicly, like bugfixes or
components to pre-existing Open Source projects.  I'd hate to see a
private fork of OpenOffice inside there, for example.

I also hope Avalanche takes IP assignment of the donated code, with clean
bills of health w/r/t patent issues, so that they have the option of
relicensing under an open source license in the future.  Finally, I hope
they're able to convince companies to make this a two-way exchange - not
just dumping a tarball here of their code once a month, but also *using*
whatever new stuff this community creates.

I've shared these thoughts with them.

	Brian