I've been working on a business model which has the potential to build
and support a large scale service industry. I see free software and
services as a viable alternative to proprietary efforts to control the
residential networking and automation market, and have posted a free
business plan to show how this may be accomplished.
I've been thinking about a business model based on free software,
similar to what Frank Hecker calls
"Software Franchising" (Setting Up
Shop). And I've been thinking about how this business model could be
applied to a specific, relatively large and growing business area:
residential networking.
My idea is to build a Linux computer (appliance, gateway, server) and
network into every new house. This
system could be adapted to existing housing (probably more emphasis on
wireless than on structured wiring),
apartments, etc. This system would connect to the Internet, and
internally could interface to telephone, audio,
video, HVAC, security system, lighting controls, and pretty much
anything else that the user fancies (and can
trust).
Everything I've mentioned exists now, and there are dozens of companies
actively trying to foist such systems
upon the public. Their progress is being slowed by many factors,
including (in no particular order):
incompatible technology, high price, poor reliability, lack of training
and understanding, and bad software.
What all of these problems cry out for is service.
People who think about free software business models gravitate naturally
to service, because that's what's left
after you free the software. However, if you start from the need to
offer a service business, what does free
software offer you? For starters: code that is built to need; that
adheres to common, non-proprietary
standards; that is open to document and understand; that is widely used,
broadly tested, and more robust; that
costs much less to develop, and next to nothing to universally deploy.
So whatever else we need, free
software is a necessary part of the solution.
We can identify several other parts to solving the service problem:
- Some activities, such as information dissemination, are very
scalable, so a single huge organization
has a marked advantage.
- Other activities, such as installation, are one-on-one, not
scalable. Here the advantage goes to
individual owner-operators, who have the strongest motivation.
- The large organization can lower costs by pooling buying power and
playing off competition.
- Small, local operators are more flexible, which can provide a better
fit to their customers needs.
- Marketing would be most cost-effective through a single brand name.
When one looks at the industry building new houses, the most striking
thing is how diverse it is. In the US,
there are no less than 128,000 general contractors building new
single-family houses. Those contractors in
turn choose from many thousands of subconstractors: electricians,
plumbers, masons, sheetrockers, and
many other trades. The general contractors and sub-contractors are
effectively service businesses, plugged
into a market which produces over 1.2M single-family houses per year
(averaging $203K each).
Given this industry, the ideal solution nearly jumps out at you: one big
organization in the middle, sharing
information and software, and acting as an industry-wide coop; and
independent affiliates signed up from the
100,000's of small businesses already serving the industry. (As an added
bonus, those same small
businesses also work on existing houses and small businesses.) The two
levels are bound together by a
franchised brand, by investment of affiliates in the central
organization, and by open communications. The
combination should be both an integrating force in the industry, and an
unbeatable value for customers.
So, given that the technology is pretty much ready, that the market is
pretty much ripe, and that the business
model is obvious, why isn't anyone doing something about this? I think
part of the answer is that the
businessfolk among us are much too much in love with ideas like high
margins, high leverage, get rich quick.
While there are ways to squeeze a little extra margin out of this
business (e.g., brand management), the basic
fact is that one of the great strengths of the free software movement is
the willingness to do it for much less.
Another great strength is our affinity for working in the open. I've
written up a draft of a business plan for
developing and applying free software business models to the residential
networking industry, and I've put it
up on the web here. As
far as I'm concerned, this business plan is free game for anyone who
wants to run
with it. (Although it should be noted that, in theory, whoever is
broadest and most all-inclusive with it will be
the most successful.)
One relatively novel concept in the business plan is the proposal to
establish a pro-active development fund
independent of service revenues. One problem with most well-known free
software business models is that
they refocus price away from the software, so they tend to provide
negligible funding for new development.
A second thing that should be noted is that while Linux advocates joke
about world domination, the
opportunity to control the home network and to provide the home Internet
connection is uniquely strategic. (If
that isn't clear, Bill Gates will be unhappy to explain it to you.) What
makes this possible is, of course, the
trust that comes from free and open systems, and from service
professionals who build their business on free
and open foundations.
Similar business models could be applied to any service industry where
there is a strong technical
component. For instance:
- VAR channels, both for generic Linux services and for specific
widely distributed vertical markets.
- Local assembled computers (my so-called Linux Craftsmen Guild
proposal).
- Web page designers.
Details are left as reader exercises. It will be interesting to see
whether others resort to posting open business
plans. In my case, this is necessitated by the scale and complexity of
the industry, especially in comparison
to my own mediocre business skills. It is often said that in business
nothing happens until someone sells
something. That is certainly true here.
There is high propensity for "free software" folk to be engineers, of a sort, but to focus on the software side
rather than the hardware side. Those that are engineers are likely oriented towards "computing," with far less
interest in digital hardware, let alone brick, mortar, nails, and paint.
Further, many of us have no formal "engineering" background; we're software guys, not hardware guys.
Throw in a third consideration: If the requirement is to have a good understanding of "business
modelling," that dictates an even "softer" focus, of the "business major" rather than "hard technology."
(And brick and mortar start fading from sight way off in the distance...)
I'm sort of a cross between the latter two categories; joint majored in computer science and accounting. And
while I'm reasonably comfortable playing with SCSI hardware, keep hammers away from me!
It seems to me that there's an unfortunately fatal flaw in your business plan; it depends on there being
voluntary spending on something that doesn't clearly provide benefit:
We believe that the free/open source software approach is the right one, but propose to "grease the skids" a bit by raising
money which can be used to focus and support development.
The way we propose to do this is to encourage franchises, affiliates, and end-users to tack an optional Development Funding
Contribution on to their bills -- much like a tip in a restaurant. These funds would be managed separately from XC service
funds, and dedicated to development work.
It's not going to be viable just based on an "optional contribution;" that needs to be something for which the contributor
sees an immediate and tangible benefit that is clearly caused by the contribution.
Unfortunately, I think your plan is much too complex. Vastly so. If the idea is to be viable, there needs to be an
economic model that justifies how it will be viable that can be described in a couple of sentences.
A full business plan does indeed need all the details, but if the critical parts can't be outlined in a sentence or two,
then it's probably got a horde of details that are secondary in importance. The section that outlines Income
describes a horde of small business options that are nice but that do not directly follow from the basic
economic model of the enterprise. In effect, all I see as a main theme is that "XC" would be in the
business of selling franchises and rights to trademarks and such; that doesn't forcibly connect to
free software, and it needs to.
There may be an approach that makes XC viable, some reason that makes it important for
people to give XC money in return for whatever it is that XC does; my sense is that you need to head back
to the "drawing board" and search for that important thing. The details may be useful in finding
where the important thing is; until then, I suggest that the details may be distractions from
the presentation. Many represent things that might happen once XC becomes a "dominant force;" if they don't
cause that "domination," they're secondary.
Thanks to cbbrowne for the comments. I posted this
on Advogato simply because this is the forum that I'm most familiar
with. Any suggestions as to better targeted forums would be appreciated.
I'd like to reply to two points that were raised:
- That voluntary development funding contributions are a fatal flaw in
the plan. To be so, they'd have to be critical to success (cause
domination).
I presented the contributions as an accelerator. In their absence,
software
would still be developed like we usually do it: as a side-effect of
usage
and service. I see much of this coming from affiliates and hobbyists,
with
XC more in a coordinating role. While is is true that better software is
needed to penetrate larger markets, I think that the software that is
already available puts us well ahead of the power curve. (BTW, there is
another reason for breaking development funding out into a separate
line item, which is educational and provides a pretext for selling the
free software development methodology.)
- The need for a simple statement of what causes domination: I believe
that there is a pent-up demand for something like this, especially in
the
house building and selling industries, which are very competitive, but
also among home buyers. This demand biases the industry to participate.
The XC approach works with the existing businesses in the industry to
support them in adding services to meet this demand. It does this by
building a shared knowledge and methods base, which collects the best
solutions that the industry has to offer, and propagates them throughout
the affiliate community. This forms a virtuous circle: greater
expertise,
lower costs, broader market share and growth, more demand, etc.
One source of the complexity of the plan is that it represents an
elaborate
balancing act. For instance, in order to grow the market, one needs to
cut
costs. Common costs, like software and purchasing, are straightforward,
but cutting costs by increasing competition cuts into affiliate margins,
which could indeed become a fatal flaw. On the other hand, exclusivity
to protect affiliate margins slows growth and invites outside
competition,
which could also be disastrous. So I've tried to design in some gears
and
levers for effecting this balance, and that is certainly a source of
some
complexity, and no doubt also a source of errors.
My assumption of demand is another potentially serious weak spot. I
suspect that at least some aspects of home automation will turn out to
have negligible demand, and that others may be adequately satisfied
with less powerful, less expensive solutions.
One more possibly important thing occurs to me: while the nominal
business model is franchising (something that is sold down), I tend to
think of this more as a cooperative (something that is built up).
However, I've always assumed that to make it happen one has to sell
down, since the target community is not well disposed to building up.
Maybe that assumption is counterproductive?