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

Re: Subversion "Whole Product" team (Was: Roles within subversion development)

From: <kfogel_at_collab.net>
Date: 2005-02-18 19:39:10 CET

"Steve Dwire" <sdwire@parkcitysolutions.com> writes:
> There's a classic book on this phenomenon that recently became "required
> reading" for our entire company when our executive team was replaced.
> Many on this list have probably heard of _Crossing_The_Chasm_ by
> Geoffrey Moore (ISBN 0-06-051712-3). Its tagline is "Marketing and
> selling disruptive products to mainstream customers." The word
> "disruptive" truly describes Subversion, especially as defined by the
> author.
> One basic premise is that if you want to take over an entire market (as
> Subversion does), and if switching to your product requires a shift in
> tools, processes, or attitudes (as Subversion does), then the entire
> customer experience becomes your responsibility, even when it's not your
> fault. Moore calls this the "whole product", as distinct from the "core
> product". The best and most advanced "core product" will lose out to a
> weaker core with a better "whole." Subversion is an awesome "core
> product", but the kinds of support problems in this "roles" thread
> (among others) demonstrate some unfortunate weaknesses as a "whole
> product."
> So, how to solve that problem? Good question. There's no way our
> current set of core contributors can be expected to take the added
> responsibility for all of the various integration issues. I believe
> they need to stay focused on the "core product" and making sure it
> continues to evolve according to plan. What I think we'd need is
> another kfogel to guide a "whole product" strategy for Subversion,
> tracking issues in the binaries, installer packages, contributed
> scripts, GUIs, and other extensions that make Subversion a stronger
> "whole product". I would think these issues should generally be tracked
> separately from the "core product" issues, but be given *equal
> importance and attention*. Then, the "core product" team can continue
> to focus on making the Subversion *code* the best it can be, and another
> (related and perhaps intermingled) team would bear the primary
> responsibility for making the Subversion *experience* the best it can
> be.
> Well, at least that's my current thought based on the
> "Hey-I-just-read-a-new-book" syndrome... :-) In the few months that
> we've had our new management, though, I have seen the difference the
> "chasm" philosophy has made in our individual attitudes and in our
> ability to attract customers.
> So, core group, what do you think of the idea of soliciting members for
> a new "whole product" team for Subversion.

(First, I want to say that I didn't do all that much guidance for core
Subversion's direction, I think we just have a team that agrees on
what it wants.)

As for a "whole product" coordinator: sure, that would be great, but
there's a reason no such person has stepped forward so far. It's a
big, difficult, and thoroughly unsexy job. This person would have to
have many different operating systems available; they couldn't
possibly have time to be a developer in all those related projects, so
they'd have to try to influence those other projects without
necessarily being able to write patches.

As Josh Siegel implied, something this big really has to be funded.
To some degree CollabNet is doing that right now, but not to the
degree that, say, Cygnus did for the GNU toolchain. What Cygnus did
required millions of dollars in staffing, equipment, and management.
But support for that toolchain was precisely what they were selling,
whereas the relationship between the Subversion "whole product" and
what CollabNet is selling is considerably more complex, and so
CollabNet strikes a different balance in what/how it funds Subversion.

I do agree with your analysis of the situation, and if you want to try
to be that "whole product" manager, we'll give you all the support we
can! But I admit I'd question your sanity :-).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 18 19:55:18 2005

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

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