On the topic of who our target market for arch 2.0 should be,
Peter Conrad asks:
Peter> why [....] "small, especially new" and "free"? I'd expect arch
Peter> to be able to handle *any* kind of software
Peter> project. Personally, I'd sort some of the ultra-large projects
Peter> into the "nice-to-have" category, though.
It's true that I adovcate for a target market that includes some very
large customers -- GNU/Linux distribution providers -- and some very
small customers -- small, especially new free software projects.
This could be dubbed the "strategy of new purchasers" which I'll
explain by analogy.
The Strategy of New Purchasers: Who is Shopping for What?
Consider a capital equipment product -- say, office photocopiers.
A serious photocopier is expensive to buy. It lasts for years with
only minor service and upgrades. It eventually depreciates to the
point where it has to be replaced.
Now consider a large office that already has many photocopiers and
imagine that you, Acme Widgets, has just come out with a radical new
kind of copier. Your new copier works on very different principles
and has all kinds of unprecedented new features. It's also less
expensive to buy and operate. Alas, your new copier is a different
size, a different interface, takes different toner cartridges, and
has different cooling requirements.
That big office that already has lots of copiers is unlikely to buy
from you. They certainly aren't going to throw out all of their
existing, perfectly adequate copiers. They may have to replace one
or two of them from time to time but they'll want the replacements
to be very similar (so, for example, they only have to stock one
kind of toner cartridge and so they don't have to retrain the
maintenance staff).
The big office is not, anytime soon, going to be a "new purchaser".
On the other hand, someone setting up a brand new office for the
first time: they are going to be a new purchaser. They have no
investment in the old style of copier. You can compete with your
new product on the basis of price and features. Legacy systems are
not much of a concern.
A large office *can* sometimes be a new purchaser. If photocopying
is not just something the large office does a bit of but is somehow
really central to their business, replacing the entire fleet of
copiers with something better might be an option. Those extra few
pages per minute might well be worth the initial investment in
switching over.
The strategy of new purchasers leads to two conclusions:
1. If you want to bring a radically new product to
market, skip the customers who are just occaisionally
replacing the older model competition and aim for
customers buying their first product and customers
who are genuinely committed to junking their old
product to make a large purchase of new equipment.
2. If you don't mind coming to market with a product
that's only a little bit different from the older
product -- a drop-in replacement -- then aim for the
customers already heavily invested in the older
product.
Now, a revision control deployment is like a piece of capital
equipment. People spend a bunch up front to get it going. Then they
expect to spend just a little, for a long time, maintaining it. They
may eventually have to junk the system and replace it, but they're
likely to resist that as long as they can.
So if you want to target established, big software projects that
currently use, say, CVS -- then come to market with a product that is
not very different. Improved and/or cheaper is nice but the major
constraint is that your new product should be a drop-in replacement.
So: write Subversion.
On the other hand, if you really want to come to market with a
radically better product -- say you want to write Arch 2.0 -- then
focus initially on customers you know are going to make new purchases.
In this case, that'll include small, especially new projects.
I would argue that distribution vendors are also going to be
increasingly among the new purchasers and that they have emerging
feature requirements that really cry out for radical new approaches to
revision control. So they're an example of large customers who
should be in the target market.
Meanwhile, what about established big projects like GCC, Apache,
Gnome, etc.? They're predictably (especially in retrospect :-)
going to make conservative purchases only. For now, that
market goes to CVS and Subversion.
History gives us an example of a large project that had to make
a large purchase: the Linux kernel project. The project was
heavily invested in Linus' scripts and habits (no serious revision
control at all). That led to a crisis ("Linus doesn't scale!").
That allowed BitMover to apply the new purchaser strategy, winning
Linus as an important first customer.
Later, after becoming heavily invested in BitKeeper, the Linux kernel
project hit a second crisis when the BitKeeper license was withdrawn.
Because Linus was heavily invested, he didn't become, at that time, a
new purchaser. He looked around for a solution that would be the
least disruptive a change from his investment in BitKeeper. Finding
none, he built one! Remember that when it started life, `git' was
incredibly feature-poor. It's main virtues were that it was
inexpensive (Linus wrote it very quickly) and that it could be
deployed in a way that didn't undo Linus' investment in BitKeeper too
badly. Git was closer to the SVN strategy than the Arch strategy only
git was more in response to BitKeeper (as used by the Linux Kernel
project).
(This does point out another aspect of the "strategy of new
purchasers" for those who want to sell to those who are already
heavily invested (i.e., not new purchasers): SVN took the direction of
offering an arguably incrementally better replacement for CVS at
arguably roughly the same price. Git took the direction of exploiting
a crisis: offering a feature-regressed replacement for BitKeeper at a
lower price. When a dominant suppliers abruptly exits the market, the
void that remains creates an opportunity even for initially inferior
replacement parts.)
-t
This post is licensed under the Creative Commons Attribution-NoDerivs
2.5 License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nd/2.5/ or send a letter to
Creative Commons, 543 Howard Street, 5th Floor, San Francisco,
California, 94105, USA.
_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
