-----Original Message-----
From: Steve Cohen [mailto:scohen@javactivity.org]
[snip]
When you say it doesn't mean anything about the Subversion software
though, I disagree. Subversion is the whole package, not just its core.
As difficult as that may be for you to accept, I think you need to
accept it. You will be judged by it, just as CVS is judged by its
Eclipse support.
[snip]
--------------------------------------------------------------------
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.
--Steve Dwire
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 18 16:55:57 2005