kfogel@collab.net wrote:
> "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 :-).
>
> -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
Received on Sat Feb 19 01:42:00 2005