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

[Steve Dwire <sd...@parkcitysolutions.com>]

-----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

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

[Steve Cohen <sc...@javactivity.org>]

kfogel@collab.net wrote:
> "Steve Dwire" <sd...@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 :-).
> 
> -Karl
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 
> 

First of all, thanks to Steve Dwire, for saying what I was trying to say 
more eloquently than I did.  I certainly will check out this book.

But is it really such a mountain as you, Karl, are making it out to be? 
  Maybe it isn't, if you break it down.  Let the core group define what 
the "whole package" is.  To say that subversion is fully supported on 
any platform, we must have a sufficiently simple (to be defined) way to 
install it on that platform.  The full package probably includes 
subversion itself, subclipse (including javahl or whatever else we need 
to make it work) or some other gui.  Volunteers then sign up to be 
responsible for one platform.  Red Hat 9.  Win2K.  OS-X.  (Maybe this 
only applies to the "off-brand" stuff?) If the volunteer is successful, 
the package gets the "full support" badge.  Otherwise, some lesser 
desgination.

My first venture into open source programming came when I had to use the 
Ant <starteam> task to work with that version control system, which my 
then-current employer was using.  (I know, hiss, boo, brickbat, 
Subversion's better, yes, yes, I agree).  The Ant task was broken.

I complained on a mailing list and the reply came back "This is open 
source.  Why don't you fix it?"  I thought, yeah, I can do that, and for 
the 2 or 3 years that I continued to work for this employer, I was the 
maintainer of Ant's StarTeam task.  I did it because it made my job 
easier.  I got no support from my employer.  I might have been able to, 
but then my employer would have wanted to control my time spent on this 
effort, and the effort was small enough that I judged it not to be worth 
it.  Eventually the Ant team got to trust me and my work.  (I had to 
stop when I no longer worked at a place that had acces to StarTeam and I 
don't know if they ever found a replacement).  But that was a manageable 
chunk of time.  I think there are people out there who might sign up for 
similarly sized tasks.

Of course, more funding would help too.

Anyway, food for thought.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[kf...@collab.net]

"Steve Dwire" <sd...@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 :-).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Daniel Patterson <da...@danpat.net>]

Josh Siegel wrote:
> cygnus did nothing but create a whole product view of the GNU toolset.  
> Before cygnus, the GNU toolset was not accepted in the commerical world 
> other then in a few outposts
> 
> Of course, cygnus was able to charge for "support"...

   And what is stopping someone doing exactly that for Subversion?  The
   license certainly permits it.  CollabNet don't provide "support"
   for Subversion as a standalone product (only when delivered as part
   of SourceCast), so it's not even like you'd even be stealing market
   share.

   An integrated "support" contract for Subversion, TortoiseSVN, RapidSVN
   and the various IDE plugins would be something that would be very
   attractive to corporate customers (when approximately competing tools
   like Rational charge thousands per-head and a significant percentage
   of that per-year in "maintenance"), especially if it wasn't a per-head
   model (people hate having to deal with licensing bruhaha when giving
   the tool to new staff).

   I'm guessing CollabNet haven't done it because it doesn't fit their
   strategy, but there's nothing stopping someone else from taking a
   crack at it.

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Josh Siegel <jo...@stormbirds.org>]

Steve Dwire wrote:

>--------------------------------------------------------------------
>[....]
>  
>
>So, core group, what do you think of the idea of soliciting members for
>a new "whole product" team for Subversion.
>
>--Steve Dwire
>
>  
>
cygnus did nothing but create a whole product view of the GNU toolset.  
Before cygnus, the GNU toolset was not accepted in the commerical world 
other then in a few outposts

Of course, cygnus was able to charge for "support"...

  -josh

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org