>>>>> "Paul" == Paul Rohr <paul@abisource.com> writes:
Paul> At 02:59 PM 6/8/99 +0900, Stephen J. Turnbull wrote:
>> Aside: you will find that economists are not very good at
>> defining how to get to "win"; we generally try to describe what
>> you'll see when you reach the mountaintop rather than provide a
>> map to the top.
Paul> Darn! But that map to the top is what matters to me! :-)
Paul> Guess that's why I'm not much of an economist.
Right. Businessmen should know some economics, IMO. But the reason
is not that the analysis is useful; it's not, for your purposes
(unless you're really naive). The reason you might want to study some
economics is that when you learn what the assumptions are that lead to
those discouraging projections, you can find violations of the
assumptions in reality. When you do, you win. If you're first, you
win big. (Assuming that you take the right side of the bet, of course
;-)
Paul> My personal belief is that office suites are a perfect test
Paul> case for FSBs, which is why I do what I do. Huge market,
Paul> commoditized product, an entrenched proprietary monopoly,
Paul> few credible proprietary alternatives, etc. If that's not
Paul> ambitious, I don't know what is.
Yes, it's ambitious.
Paul> However, the kind of "win" you're interested in requires a
Paul> bigger investment of time and resources than a handful of
Paul> individuals can provide. Thus, as a businessperson I face
Paul> choices across the following spectrum:
"Handful of individuals" is the key. You no longer are dependent on a
handful of individuals for your development needs. Now, _every user
is a developer_. Some people are pure developers on your project,
some people are part-time developers with deep skills, and some people
are 99.44% user, but "enough eyeballs...".
I don't see much possibility for a huge win in the general market
based on big features designed by your core group; MSFT would have to
simultaneously really screw up, somehow. Possible, but the timing is
unlikely.
What I do think might be interesting is a business model based on a
user-preference database. One problem with most free software is that
"all the defaults suck" (for everybody). But that's a special case of
the general proposition about software that "each default sucks" (for
somebody). One thing that I hate about all menuing systems is that
unlike my Japanese input methods, most-recently-used and historically-
commonly-used choices do not float to the top of the menu. I think
unused tools should disappear from the button bar and relegated to
subsidiary menus. And so on.
Now, there are three issues here. One is an easy way to customize;
MSFT products have that. Second is an efficient way to customize a
lot of things at once, "customization themes". Here's one place where
you can tap the user base: get them to send your their configs. Build
up a statistical model. And the final one would be the kind of
automatic reconfiguration that Asian language input methods do. And
that would provide the statistical variation that would make the user
contributions interesting.
MSFT _could_ do this, but I think their model and psychology motivate
against it. I also think that few customers would cooperate. If an
FSB could manage it---and it's the interesting kind of project that
might pique somebody's interest---it would also have a tool that cries
out for generalization. I think that kind of thing would be very
attractive to tens of thousands of technical writers, for example, who
are always having to work around this or that MSFT design decision, by
writing macros or changing options or whatever. And if the theme idea
were readily available to programmers, perhaps written in a language
that could be easily customized (like X resource files), it could be
very attractive to large sites with specialized needs.
Now, this particular example is obviously rather far-fetched, but it's
an example of a way that you can leverage the developer-developer kind
of externality (this is what fascinates me as an economist, this is,
like, new in history) that open source produces (here, it's basically
just user goodwill). What I don't know how to predict is what will
happen as people with real skills start to join these networks; I
think the enormous amount of Lisp that has been contributed to GNU
Emacs over the years is something that FSBs should try to figure out
how to emulate. Russ Nelson once wrote on this list that he'd gotten
few contributions over the years; maybe packet drivers are just a
tough sell. But even device drivers can generate a lot of
contributions, somehow, for Linux or *BSD.
If you can figure out how to design an open-architecture Word-a-like
with an extension language with all the graphical features available
to relatively unsophisticated users, but with the power of OLE or
CORBA or whatever available to people writing applications in C or so,
what wouldn't be possible?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."