[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [OT] Collabnet's Open-Source business model

From: Brian Behlendorf <brian_at_collab.net>
Date: 2005-01-20 03:39:09 CET

Jasob wrote:
> On Wed, Jan 19, 2005 at 02:32:38PM -0600, Ben Collins-Sussman wrote:
>> I promise that ViewCVS's svn compatibility is well-maintained. The
>> maintainer is sitting a meter away from me. It's a core component in
>> Collabnet's commercial product, so we're not allowed to let ViewCVS
>> *not* work with the latest released Subversion. :-)
> The above comment made me wonder about Collabnets "unification" of Open
> Source (Subversion and friends) and the commercial world. There's always
> a lot of noise in the OSS (Open Source Software) community about ways to
> make money when giving your software away. Which prompts the following
> questions:
> - How does Collabnet make money? What is your business model?

Before describing what we do, let me give you one premise upon which we're
built: that one reason that Open Source communities often work very well
has to do with the kinds of tools they use to cooperate. Tools that work
very well over the wide-area network, with a built-in bias towards
transparency, and that capture and link together both the formal (code
versioning, issue-tracking) and informal or ad-hoc (discussions on mailing
lists, etc) kinds of software development artifacts. These kinds of tools
are essential to really building a community or community of communities
around software, rather than just a collection of unlinked "islands" or
"silos" of development teams, which is how developers at most software
houses are organized. It also is essential to really building effective
internal software reuse repositories, and making developers in different
geographic locations able to work together effectively.

So we do this by integrating a set of developer collaboration tools used
by (or modeled after tools used by) the Open Source community into a
single suite, doing single sign-on and managing huge data sets and usage
patterns, and then providing it to companies as a managed service paid for
on a periodic per-user basis. Companies pay for this whether they want to
use it for true Open Source projects, such as Sun and OpenOffice.org or
Intel and their new Tianocore.org project; or for purely internal software
development efforts; or for an interesting grey area between the two where
companies work with other companies on joint projects, outsourcing/
contracting, technical customer support, etc. We also sell consulting on
how to set establish and maintain effective software engineering
communities, again whether internal or external. And we're hiring. :)

> - In retrospect, would you expect to make more or less had you chosen
> not to make Subversion and friends OSS?

While I think it'd be impossible to truly objectively measure the impact
Subversion has had for us, there's no doubt on my part or our execs or
board that our investment in Subversion has been paid back in spades, and
not (just!) in the form of goodwill. None of that return for us, by the
way, is predicated on being the only one making money from Subversion - we
*want* to see a healthy ecosystem because that should lead to more users,
more developers, more eyes looking for defects and hands willing to help
fix, more integrations into client-side IDEs, and more features and
reliability. We knew from the beginning this wasn't something we could
build all ourselves, and we also know that not everyone can afford to hack
just for fun - though those that can often provide some of the most
significant features, because they often have less to lose by being wrong.

> - What is your experiences in bringing OSS to the commercial world? Or
> bringing the commercial world to OSS?

There's a book or two in answering this question, more than I have time in
answering right now, but to try to do it briefly: the OSS and commercial
worlds (by nearly any definition of what those terms mean) are not
disjoint sets, nor do they necessarily have incompatible goals. Most
companies are using OSS *somewhere* in their organization, but most don't
understand the process by which it's built. That's changing, though, and
is one reason why the world needs companies like us, or MySQL, or Red Hat,

> - Have you encountered problems with the OSS community being a
> commercial entity? Or with the commercial world being an OSS shop?

Hopefully the Subversion community feels we've been good stewards of the
project. We have our goals for specific features and quality criteria,
but we try to ensure that pursuing those goals doesn't disincent other
contributors with good ideas. So much of what makes Subversion valuable
today came from non-CollabNet employees, and we respect that.

Selling the merits of Subversion to the commercial world has been easy
thanks to the great feature set, documentation, and quality it has and the
resulting great press. There's always edge cases and "you'll pull
ClearCase from our cold-dead-hands" situations, but so far no objection
has been raised to SVN (or any of the other OSS components we've
incorporated) due to its Open Source origin. That's largely because
we're the ones on the hook to any customer for any defect, slowdown, etc.,
and because we run it as a managed service. No one objects to using
Google, for example, because they run Linux. That layer of abstraction
for us has helped tremendously.

> - Did you choose the OSS way of doing things from an ideological or
> commercial perspective?

Commercial, certainly, but not without a bit of a leap of faith and a
gut-level sense of "this feels like the right thing to do". Still, I
don't know that there is one single "OSS way" of doing things; we still
have plenty of software we do not release under an Open Source license,
that is something you can get only by becoming our customers. Balancing
such a "hybrid" approach is not unlike what nearly every software company
is doing these days.

> - Did you start out as an OSS shop or was it decided later on? If so,
> what steps/pains/surprises did you come across?

We started in 1999 on the premise that the Open Source community had
figured something important out about how software is written, and that
there was a need for a company that could translate that for the rest of
the software industry. We're not the only ones, of course, who came to
that decision.

> - Any other insights regarding the topic at hand?

There's a few books out there now about Open Source business models worth
taking a look at; I've not read any of them, but have heard good things.
There's one coming out by Dick Gabriel and Ron Goldman in a few months
that I've read, more on the topic of building successful open source
communities, that I've read and really liked. There's also a mailing list
you can join of people who talk about open source business issues - called
the "Free Software Business List" (acknowleging that OSS and Free Software
are different but related concepts), which you can join by emailing
fsb-subscribe@crynwr.com, or you can read the archives at
http://brian.behlendorf.com/fsb/ .

It does feel like there's a phase change happening in the software
industry these days, one towards open source, but one more generally
towards software as service; whether a managed service like us or
Salesforce.com, or open-source with support contracts, etc. Most of the
software written in the world, though, is not released as a product, but
instead written for internal use. Even there, especially there, Open
Source principles still apply and can have a huge impact.

Anyways, yeah, beyond this email this'll probably get off-topic, unless
followup questions are around CollabNet and Subversion. Please cc me
directly as I'm not reading the users@ list every day. Thanks!


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 20 03:42:30 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.