Date: Thu, 29 Aug 2002 19:57:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rich Morin <rdm@cfcl.com> Cc: freebsd-chat@freebsd.org Subject: Re: What can FreeBSD learn from Mac OS X? Message-ID: <3D6EDF31.45216C70@mindspring.com> References: <p05111b0eb9944f21ee6f@[192.168.254.205]>
next in thread | previous in thread | raw e-mail | index | archive | help
Rich Morin wrote:
> No, I don't just mean marketing. The Cylogistics / Daemon News folks
> are already doing good work in that direction; if I have any marketing
> aspirations/energy, I'll just give them a hand.
>
> What I mean by "productizing" is something like the distinction made by
> Fred Brooks ("The Mythical Man-month": required reading! :-) between
> "programs" and "program products".
Geoffrey Moore (formerly of Regis McKenna) said it best in his book
"Crossing the Chasm":
One of the most useful marketing constructs to become
integrated into high-tech marketing in the past few years
is the concept of a whole product, an idea described in
detail in Theodore Levitt's _The Marketing Imagination_,
and one that plays a significant role in Bill Davidow's
_Marketing High Technology_. The concept is very
strightforward: There is a gap between the marketing
promise made to the customer--the compelling vlaue
proposition--and the ability of the shipped product to
fulfill that promise. For the gap to be overcome, the
product must be augmented by a variety of services and
ancillary products to become the whole product.
The formal model is diagrammed by Levitt as follows:
The Whole Product Model
,-----------------------------.
| ,-------------------------. |
| | ,---------------------. | |
| | | ,-----------------. | | |
| | | | | | | |
| | | | Generic Product | | | |
| | | `-----------------' | | |
| | | Expected Product | | |
| | `---------------------' | |
| | Augmented Product | |
| `-------------------------' |
| Potential Product |
`-----------------------------'
The model identifies four different perceptions of the
product, as follows:
1. _Generic Product_: This is what is shipped in the
box and what is covered by the purchasing contract.
2. _Expected Product_: This is the product that the
consumer thought che was buying when she bought the
generic product. It is the _minimum_ configuration
of products and services necessary to have any
chance of achieving the buying objective.
For example, people who are buying personal
computers for the first time _expect_ to get a
monitor with their purchase--how else could you use
the comuter?--but in fact, in most cases, it is not
part of the generic product.
3. _Augmented Product_: This is the product fleshed
out to provide the _maximum_ chance of achieving
the buying objective.
In the case of a personal computer, this would
include a variety of products, such as software, a
hard disk drive, and a printer, as well as a
variety of services, such as a customer hot line,
advanced training, and readily accessible service
centers.
4. _Potential Product_: This represents the product's
room for growth as more and more ancillary products
come on the market and as customer-specific
enhancements to the system are made.
Crossing the Chasm
Geoffrey Moore
Harper Business
ISBN: 0-88730-717-5
FreeBSD started out shipping a _Generic Product_, and it still ships
the same generic product. RedHat (as an example) *almost* ships an
_Expected Product_. Microsoft *almost* ships an _Augmented Product_
(they live and die by the 80/20 rule).
[ ... examples of the difference between a _Generic Product_ and an
_Expected Product_ ... ]
> I don't see the FreeBSD Project being able to use the same methods as
> as Apple does; its goals and market are too different. There may be a way,
> however, to get some of the benefits without buying the whole package.
I don't think FreeBSD can really compete at this level, period. It's
a volunteer project. It requires the resources and the market drivers
of a RedHat or similar company.
There are two *serious* barriers to entry for any company that would
try to fulfill this role for FreeBSD, and a myriad of smaller barriers.
The two *serious* barriers are: (1) ability to use the trademark without
repercussions (example: "White Hat FreeBSD"), while differentiating the
_Generic PRoduct_ by providing an _Expected_ or _Augmented Product_ for
a particular market, and (2) control over over the elements of the
distribution which are based on guaranteed access to commit priviledges
and/or the brute force position of of core team membership.
RedHat has it much easier in this regard, in that all they really have
to deal with in terms of negotiated interest is the kernel itself, and
they can do some pretty eggregious things along the way, and the
trademark holder (Linux) will not (or at least has not so far) slapped
them down.
> What I would _like_ is a situation where an administrator can be safe in
> using a given version of FreeBSD, plus occasional binary patches, for a
> year or even longer. In order for this to work, however, there would
> need to be multiple, overlapping streams of releases, as:
[ ... product lifecycle maintenance ... ]
A picture of this for Mozilla is at:
http://mozilla.org/roadmap/branching-2002-08-01.png
The point about this, though, is that product lifecycle maintenance is
an un-sexy job, and volunteer projects, outside their inital founding,
rarely tackle unsexy jobs, unless they are considered challenging, and
appeal to the nature of the volunteers. The closest FreeBSD has to
this wa Jordan, and, despite the fact that he did not lack for the
raw materials, he could only juggle so many cats at a time before he
risked bleeding to death. 8-).
[ ... lifecycle schedule timeline, fixed to calendar dates distributed
over a 24 month period ... ]
> It appears that the number of dotdot release per month, under this scheme,
> would creep up to an average of about 2.5. Because only critical bug
> fixes would be included, the amount of work to prepare each patch should
> be relatively small (as compared, say, to a "dot" release :-).
This is actually a significant amount of work, until you have a base
distribution which tolerates updates gladly.
> Anyway, that's one suggestion... Now for a question: would anyone pay
> Real Money (TM) for these sorts of dotdot releases? It wouldn't have to
> be a lot, just enough to pay for the work involved. If so, Daemon News
> or some other party might have a business opportunity...
I think that such a scheme is necessary, but not sufficient, for the
creation of a _Whole Product_. There are other aspects of the product
which would need to be addressed, as well, to, minimally, move it from
a _Generic Product_ to an _Expected Product_.
One issue here is that not all work could be safely donated back
to the project initially, in this business model, if the R&D costs
were to be amortized over a long enough period that the sales would
both pay for R&D, other fixed overhead, operating costs, and profit
to pay back investors.
One answer might be a time converted license, such as that which was
on the Soft Updates code, where you can burn your own CD's of the
augnemented code, but you could not sell such CD's yourself, unless
you paid a license fee.
This is generally unsatisfying from a community perspective, since
you are unlikely to be able to find a FreeBSD you can burn to a CDROM
and sell, if the developement becomes the mainstream FreeBSD; there
is an implicit marriage to a single vendor, along with other problems
that would likely result in a serious backlash.
But donation of the code is what is required; if it's not a part of
the standard FreeBSD, the terms and conditions on the use of the
trademark means that you have to ship an unadulterated (un_augmented_)
"Disc #1", which means that your support costs go through the roof,
as people boot the wrong CDROM, and get the standard install, rather
than your graphical install that would not work on anything without
SVGA or better display capabilities, a keyboard, and a mouse (as an
example).
Even so, there's no guarantee that the changes you want to make will
even be accepted back into the source tree, after review, even if you
are a core team member or a Julian Elisher or other highly respected
contributor.
This leaves you in the same position you are with any GPL'ed product:
no means of amortizing your R&D costs, or needing to fork another
distribution off to get around the otherwise insurmountable issues.
It's a difficult problem to solve, without some movement on the
other side.. e.g. The FreeBSD Foundation Inc. taking posession of the
FreeBSD trademark, and setting perpetual license terms on its use
would be one solution; getting NetBSD or OpenBSD to adopt those terms,
and picking one of them instead would be another; I'm sure there are
others. The problem is not insurmountable, but it would probably take
a lot of work to avoid turning the attempt into another BSDI.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D6EDF31.45216C70>