The Consulting HOWTO
A Guide to Open Source Consulting
|
|
Gary Lawrence MurphyPresident
and CEO 7 Forest Place |
$Revision:
1.4 $
Copyright © 2000 by Teledynamics Communications Inc
$Date: 2000/03/27 17:46:46 $
Open Source consulting is as varied as the
people who make their living at it; this paper only includes my own
experiences, thoughts and advice on training for and entering this field. It is
intended for practicing consultants curious about open source, and those
interested in consulting as an occupation. Both wonder if this "Linux
thing" is worth their while. The short answer is "yes".
The most current edition of this paper can
be found online at http://www.teledyn.com/help/linux/Consulting. The document is
also available in Postscript,
Rich
Text and Portable
Document Format. Many people have contributed to this work, but I alone am
responsible for what is written, and for what has been omitted. Please direct
all questions, comments and corrections to garym@teledyn.com; it may not be exactly what you need to
know, but it is willing to change.
Table of Contents
Marketing
Open Source Consulting
GNU
Free Documentation License
Copyright
Permission is granted to copy, distribute
and/or modify this document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the Free Software
Foundation. A copy of the license is included in the
section called GNU Free Documentation License. While the text of
this document is covered by the FPL, before you do copy this work, be advised
that many illustrations have been lifted from websites and correct attributions
are not known.
prelude
Why should a mainstream, proprietary systems
consultant make the shift into open source? What might draw a young
entrepreneur into a business based on free software? We all know the the
software is free but support is extra, but is this the whole of the business
model? I hope to show that this a very good model, not just because of the free
beer or the philosophical draw of free speech, but because of a surprise bonus
that gives the free software consultant more to offer than their license-bound
counterparts.
The secret of this surprise bonus is in the
words of Linus Torvalds: "I'm basically a lazy person who likes to get
credit for things other people do." Before I get into that, though, I
should mention that I didn't expect any bonus when I started. I didn't even
really notice when it did happen. It just kinda snuck up and was there. I
expect others may be following me, also out of constraints more than
requirements; if it does sound like where you are going, then the good news is
there is a surprise ending.
Bibliography
[CTM] ClueTrain Manifesto, , Perseus Books, Jan 2000.
[RMS] Philosophy of the GNU
Project, Richard Stallman and al, FSF Website.
[ESR] The Cathedral and the Bazaar, Eric Raymond, O'Reilly,
Oct 1999.
[RBF] Nine Chains to the Moon, Richard Buckminster Fuller,
Southern Illinois University Press, 1963.
[MM] Laws of Media, Eric and Marshall McLuhan, University of
Toronto Press, April 1992.
[JP] The Last
Dinosaur and the Tarpits of Doom, Jeff Prothero, MUQ.ORG Website,
1998?.
[NM] Debunking
the Myth of a Desperate Software Labor Shortage: Testimony to the U.S.
House Judiciary Committee Subcommittee on Immigration, Dr. Norman Matloff,
University of California at Davis Website, March 2000.
[RC] Learning About community currencies ,
Mose, Ratitor's Corner Website, Spring Equinox
1999.
The Open Source Consultant
I have been consulting full time since 1981,
and head of my own sometimes-successful company since 1983. Over those decades,
I had seen other trends in what we now call Open Source Computing. The first
was a small terminal-emulator program for DOS called PC-TALK;
although free software had been common in the MULTICS world, this was, so far
as I know, the first widely distributed example of freeware (or Shareware) for
the personal computer. PC-TALK, and the Telix
that replaced it, introduced "free beer" to the PC, or at least the
idea everyone should have decent software. Neither program was initially open
source, and Telix, like many programs of the
day, did ask for a token donation, but both eventually sent out the source code
if only to cope with the demand for new features. Still, these were very much
like the early FSF programs: The developer pool was
tightly cloistered small groups of friends who listened eagerly to the people
who used their handiwork. Within a very short time, Telix
conquered the BBS-terminal market, defeating even stalwart CrossTalk. This was
my first clue: Users are your best co-developers; you can never have too
many of them.
In DOS days, we just assumed applications
belonged to their developers. Toolkits were another issue. Before long, thanks
to Borland, free and open source toolkits sprouted up, C and C++ libraries for
every conceivable task, and like the applications, the maintainers of these
libraries listened and responded. Suddenly, anyone could contribute to just
about any program by creating a clever toolkit, and these libraries spread with
great speed. This was the days, or rather the nights of the FidoNet, a
poor-man's "Internet" spanning the globe from Europe to central
Australia via low overnight phone rate calls to relay email and software from
one FidoBBS to its next nearest neighbour. Over this new medium, collaboration
and distribution of toolkits and applications was international, extremely
rapid, and absurdly cheap. This was my second clue: Internetworking changes
everything.
At that time, I was cavorting with known
anarchists like the composers John Cage and Udo Kasemets. I had been a fan of
Cage, Bucky Fuller, Marshal McLuhan and William S. Burroughs since my teens; in
retrospect, I was probably a powderkeg in search of a terrorist. As an
unabashed advocate of free and unfettered information sharing, free software
appealed to my young mind, it held an almost Kabbalistic hope: "You may
pay for knowledge, but you should never charge for it.". Community
currencies[RC]
would prevail over the economics of scarcity; I devoted myself to learning,
promoting and participating in the Free Software Revolution.
My interest was not entirely spiritual. In
the 80's, corporate computing was dominated by the IBM's and Microsoft's $1000
development packages. Without apologies, a large impetus to bring free and
low-cost software to my clients was my own financial situation: Without these
low-cost and no-cost tools, I was excluded. Had I been less rebel, I might have
learned Clipper like my peers, and financed my own tools or settled in at that
job AE LaPage offered. Instead, as usual, I thought the crooked path looked more
interesting.
Free Software, and later the GNU Public
License, opened doors which did not otherwise exist. I could parley my Timex
Sinclair into an Osborne and that into a PC because bankers could see sense in
lending based on collateral. For my software tools, I was on my own. Luckily,
with Free Software and a nearly-free global network of friends and colleagues,
I was anything but alone.
I still had to pay the bills. Fortunately,
my clients knew very little about computers, proving once again by induction
how "literacy breeds ignorance". My clients were the people on the
shop floor, investors on the exchange desk, people who could not get past their
"MIS Bottleneck", and artists and composers. In short, they were
craftspeople in their own right who cared more about getting the job done than
about the technology used to do it. This gave me license to explore, and I
thank them for that.
Thanks to my network community of colleagues
and co-developers, I was able to learn by the seat of my pants, pull in remarkable
talents behind the scenes, and consistently deliver more bang for the buck than
my clients expected. One contract lead easily to another. This was my final
clue: "No open source developer is an island".
Thanks to this opportunity of circumstance
and a freedom to choose it, 80% of my work now involves only Free Software. I
have a positive cash flow, and there is no end in sight. I could now actually
now afford to license an 1980's IBM Pascal. Borland, the kind source of my
entry to the free software community of the FidoNet, and even venerable IBM,
author of the barriers to my entry, are now both avid participants in our
Revolution. There's a poetic irony at work here.
The Real "Why" of Open Source
|
|
The origin of the word
"community" comes from the Latin munus, which means the gift, and
cum, which means together, among each other. So community literally means to
give among each other. Therefore I define my community as a group of people
who welcome and honor my gifts, and from whom I can reasonably expect to
receive gifts in return. |
|
|
Bernard Lietaer[RC] |
This is how and why I started. Near poverty,
a need to better myself, an aptitude (whatever that is) for independent
learning, a gracious opportunity to pull it all together, and a thin wire to a
life-line called the FidoNet. From there, a number of chance encounters brought
me out of the DOS/Freeware scene into Unix, the Free Software Foundation and
later into Linux.
I first encountered Richard Stallman in
1987, or maybe 1988. His GNU Manifesto was being traded like an underground
novel on USENET. Eager to participate, I wrote to ask if there was anything
someone with a lowly 286 computer could do. Richard said GNU was never likely
to run on a PC, but they had a dire need for documentation; it's another irony
that today, a large chunk of our revenue comes from assisting Macmillan
Computer Publishing in open source book projects.
Anyway, back to RMS: His Manifesto was a
blueprint for practical community economics, a formal and legal framework,
straight out of Bucky Fuller. It lowered the entry barrier to anyone owning a
Sun workstation, and while a Sparc was impossibly out of my own reach, I was,
at the time, under contract with Cognos
Inc where Sun workstations were plentiful. At Cognos, I found my fellow
engineers were already deep into Free Software computing, but for different reasons.
Cognos, known at the time for their 4GL
Powerhouse software, was a world leader in implementing object oriented
technology. Our editor of choice was EMACS, our windowing system was X, our
compiler of choice was GNU C, and most of our other tools were gems peeled off FSF tapes. Why do this? In 1989, Cognos was Canada's
largest software company, and something like 14th largest in North America. We
could afford over 200 programmers and a Sun 360 for each of them. We could
certainly afford any tools the market could offer. Why base the core of the
business on an absurdly low-cost tape from the Free Software Foundation?
Superior performance of the FSF craftwork is only part of the answer, as was their
adherence to industry standards. For our purposes, there was the demands of our
leading edge research: If we needed a fix, we had both the source and right to
change it, but this was not the whole story. Even the "standing on the
shoulders of giants" was only part of the story. Yes, we could change the
software to suit our purposes, but even more importantly, most often,
someone, somewhere else, someone we did not know and certainly did not pay, had
experienced the same need, had already added that feature or fixed that bug,
and had returned the new code to the general pool of knowledge. Our choice of
Free Software was not just about control of our own destiny or building on
prior work. It was about the amplification of our resources through a global
community. This is where all my clues came together. This is where Open
Source computing changes the game, or at least illustrates a very changed game;
this is how Open Source over the Internet redefines "technical
training", and gives the Open Source Consultant their competitive
advantage.
Three things happened at Cognos, three
things for which I am forever grateful: I was bitten by the Unix bug, I came to
understand Object Oriented Design, I learned first hand about the real
advantages of free software, and my wife left me. You can't buy good fortune
like that.
Terminology
Before I get too far, let me clarify my
terms. Throughout this paper, I use "Open Source Software" and
"Free Software" almost interchangeably. I similarly swap the
trademarks "GNU", "Free Software Foundation" and "Linux".
This is out of bad habit, not ignorance.
By "Open Source", I do not mean
simply the granting access to source code; I mean the spectrum of licenses
endorsed by the Open Source
Initiative (OSI), and those they would endorse
if they read them. This is a more liberal definition of "free
software" than the FSF; you could say that Open
Source is a sphere with GPL at its center, or a
diffusion pattern out from GNU. The licenses inside this sphere share a common
bond of allowing anyone free access to the source code, and granting anyone
the right to redistribute modified versions of that code. More over, and more
importantly, these licenses facilitate an open community exchange of
ideas and development.
Similarly, Linux
is itself a GPL (GNU Public License) project, and
most Linux distributions contain a high percentage of Free
Software Foundation (FSF) software, but I use these terms in the loose and
shallow sense to include all software bundled with an open invitation to copy,
share and modify the programs and the collections. Again, an open invitation to
participate which facilitates an open community.
My intent is not to fuel license wars but to
point out the differences between, for example, the community of Visual Basic,
or Delphi, or Sybase developers, and those of a Linux or Apache. Both are
"communities", but there are stark differences which place the
proprietary group at a distinct disadvantage, especially when mixed with the
Internet. Open source groups, by being open to mass participation, can achieve
a critical mass of online synergy unknown to proprietary communities.
Open Source Consulting
As an occupation, "Open Source
Consulting" can be factored into four stages, four scopes. Two of these,
product support and systems integration, have counterparts in traditional
consulting, but the other two have more to do with the culture and education
specific to open source and especially to the new business and software engineering
climate engendered by the Internet.
·
Technical support and
development for specific open source software packages such as the Apache
webserver or the Linux Kernel.
·
Providing design
guidance and development integrating Open Source programs or hybrid systems of
Open Source and proprietary software.
·
Providing evaluation,
procedural guidance and technical support to businesses who need to participate
in an open source project.
·
Managing and initiating
Open Source projects on behalf of a client.
Applications Support
Under the banner of Linux, this is a
burgeoning field. No surprises here, one basically takes what one knows about
some specific component of a program and applies that knowledge for the benefit
of the client. The most common example is supporting the Apache webserver, or
the Perl/PHP contracting.
There is very little difference between this
work and consulting work with proprietary software such as SAP or Microsoft
products. You make a pitch, agree on a price, build a solution, shake hands,
cash the cheque, and move on. This is honourable work, but take my advice: It
is not profitable in the long run. Highly recommended to put yourself through
college (or buy that Gibson guitar) but not something to fund your retirement.
On the positive side, the entry barrier for
this line of work is absurdly low: You can run the same software on very modest
hardware to simulate and develop, then seamlessly migrate to your client's
platform. You can also usually adapt knowledge gained from other platforms, for
example, there is a growing demand for database expertise in Linux circles and
this is a popular niche for down-sized older programmers looking to ply their
trade in this new industry. All the resources to learn and to deploy these
projects are also freely available, and most often authors or other
contributors and users of those tools will freely assist you, all in the cause
of the Revolution.
This line of work is ideal for the beginner;
it requires a basic level of skill and experience, but this background is not
hard to acquire through volunteer projects, and since your contractors may not
understand the Internet information economy, you can go very far flying by the
seat of your pants, going home each night to sit on IRC to solve your previous
day's business problems; you can easily appear to be far more of an expert than
you actually are. Trust me on this.
Open Source Systems Integration
Integration, and with it systems and network
administration, is the subject of 99% of all the so-called "Training and
Certificate" programs. Again, no surprises, you all know what it means:
You provide the glue that holds many Open Source products together in consort.
The job is similar to single-product technical support, except the scope of the
knowledge and experience required is larger, as is the scope of your Open
Source community involvement. A systems integrator, whether installing and
maintaining servers or amassing open source pieces into new network appliances
or a new Linux distribution, is exponentially more muddled in the Small
Details, but essentially involved in the same learning the materials, suiting
solutions to a task, careful debugging, eyes on the road, hands on the wheel,
and moving on after the final cheque and the handshake.
I include Linux and other free O/S
"distributions" under this heading. A Linux distro is, at its core,
an integration of open source (and sometimes hybrid) software. It involves
quality control, smoothing out the rough edges, sometimes some special glue,
but once done, once it is beyond it's lifespan, the romance is over.
Network appliances are also integrations.
Appliances are specialized distributions set into small, special purpose
machines; basically, an in-house distribution duplicated into the hardware
before the unit is sold, usually for use as a firewall, gateway, mail server,
print server, network monitor, & c. Since Linux will run on everything from
old donated 486 hardware, low cost rackmounts to clusters of high-powered VA
and IBM machines, vendors are eager to partner with anyone who can help them
sell boxes through an appliance application.
Appliances are another opportunity for older
programmers. By integrating Linux with seasoned expertise in business software,
special purpose database appliances such as accounting machines, inventory
control and especially in integrating these into ebusiness applications may
find a ready market.
I won't question there is money to be made
in specific applications support and in the more general systems integration,
but I don't believe you can make it to retirement doing this. These are
hand-to-mouth occupations, lucrative while they are happening, but volatile and
without residual benefits. For the open source consultant, the money is not in
tinkering code but in tinkering with business itself. Business is changing, and
those in the internetworked open source community probably have the best grasp
of the survival skills all businesses will need.
Participatory Open Source
Up to now, the service models I've outlined
are almost identical to their proprietary counterparts. There is a major
difference, though: Open source has built in longevity. Simply integrating and
supporting specific systems is a passive role. When the market changes, and if
your technology is something like the FidoNet, you can find yourself suddenly
stranded. Retraining and re-tooling becomes a way of life, a long series of
seminars and retreats. Most closed-source consultants and businesses using
closed source systems with consider this "the cost of doing
business".
Open source is not so passive. Consultants
can actively counter obsolescence through participation, learning about
and helping to form the changes in the technology as it incrementally evolves
to better suit changing markets. Everyone I know who is supporting open source
doesn't even think about this, they just follow the newsgroups or mailing
lists, follow the revisions and patches, and seem to be on top of their niche.
Unfortunately, unless they teach their clients to do this, they may have
failed. This is the third evolutionary step in Open Source Consulting:
Participating ourselves and leading our clients in to participate in the
software they are using.
Unless there is participation, a company may
have their solution today, but may be left with yesterday's technology; the
tiniest shift in the information ecology could knock them flat. They miss out
on the meaning of the Revolution, and it is more your fault than theirs because
you knew better.
For our clients, participating in
Open Source shifts them from being a consumer of technology to being a source.
We see the famous open source support companies such as RedHat and VALinux
using this approach: The open source people they hire to do develop their
products is folded back into the open source community. They can obtain the
innovations they need for their own products, and, in the process, gain inside
information about the future of those systems, they can stay agile and
anticipate changes, and most importantly, by "giving back", they
ensure support from the community.
For the consultant, participating in Open
Source is how we network. It is so normal, it is almost invisible. By
contributing, we are always learning new skills, and investing in our education
and our reputation. Participation is better than an RRSP for ensuring our
future. For these same reasons, it is essential we relay this to our clients.
We won't convince every client. Our clients
will shy away from active participation. They can see open source as a free
ride and counter with "We have no time. Our application is our competitive
edge. We cannot spare the resources."
The excuses cost more than participation.
Fortunately, with every new Fortune 500 announcing its participation in
projects such as Linux and Apache, the case for involvement is easier to pitch.
When IBM, Motorola and Cognos can boldly proclaim they play the open
source game, our clients can at least entertain the notion they can play too.
Proselytization (P13n)
"Is he suggesting I convince my financial
securities client turn their on-line trading systems Open Source?" You
probably already think I am quite mad. You are right, of course. You're mad
too, otherwise you would not have come here, but that is all milk spilled under
the bridge now. The important and critical point, is that, whether or not your
clients will play the game today, they will tomorrow, and since you are only
now reading about how to become an Open Source consultant, you can't possibly
be set up and ready for business before sunrise. QED.
The benefits of turning core systems and
applications into open source projects is staggering. It is more than
staggering. It is probably inevitable: If they don't do it, a competitor will
and they will be left in second place. In an economy of community, knowledge is
not power, knowledge is water. The community is the power. Without trade,
knowledge sours and perverts, it makes silly mistakes, and costs astronomical
sums to prop up the illusion that all is well. Knowledge Management is a myth,
at best it means "Learning to Talk". With all it's resources,
Microsoft could not build a bug-free Windows
after 9 tries; how could anyone presume to do better? With all it's impossible
mass and tangle of "disorganization", Linux is the De facto
alternative O/S, and it grows exponentially in strength and scope with every
new release. Why? Because it understands social networking, it knows how to
talk and does so on a global scale.
Open Source per se is no guarantee
of superior software quality — a simple browse through FreshMeat will attest to
this — but it is also true that Open Source can do no worse than a
closed-shop "cathedral" approach. The worst that can happen is no one
else is interested in your software, or no one can improve upon your genius.
The gains when the software strikes a common chord, however, are significant;
if your client has, at their heart, a need to provide some service, to fill
some market need, no one can question that their best business plan is to do so
as efficiently as possible.
It's important here to make a design
distinction between what software does and how it works, or between its engine
and its implementation. Every newspaper website may need software to parse the
broadcast news feed into a database, but every one of them will have a unique
way to mine that data into a webpage. The obvious common engine, and the most
critical component, is ensuring the data is received and correctly cross
referenced into the database. This is a good candidate for an open source
component. How that data is mined and rendered into webpages depends on the
style and audience of each paper; at best the means of fetching data and
inserting it into a page should be open source (this is essentially what PHP
does), but the final pages themselves are totally unique.
Another example might be an accounting
package. There is a clear difference between the components that take numbers,
add them, store them and move them about the system, and this is a good
candidate for an open source project (GNUCash is working on this) especially if
individual financial services companies can take this basic engine and create
new and innovative accounting systems using their expertise in accounting as
their competitive edge rather than attempting to be the world's best numerical
processing expert.
A real world example is the
embedded-Linux consortium. Their member list includes top tier companies such
as Motorola and IBM mixed with tiny startups; most members had invested
significant resources developing their own proprietary embedded operating
systems, yet here they are, dumping their own work, lowering their defenses (or
inhibitions) about each other, and working together to adapt Linux to their own
cause. Another is IBM virtually abandoning both AIX and Monteray64 because
they cannot compete with the world. Even Big Blue, who might have a case
for marketing their own O/S to recoup development costs, even they have
eschewed re-inventing the wheel. They choose instead to co-operate and unify
rather than to hoard and divide, and they position themselves to enjoy the
benefits of an economy of a community.
Why Support GNU/Linux?
|
|
"If only sitting was required, all
frogs would be Buddhas" |
I probably do not need to outline the
virtues of the famous open source applications. You all know Linux, Apache,
Sendmail, Perl, and you all know how these have changed the face of business as
we know it. This much you know, but what you may not know is how the very
essence of these projects, the principles behind Open Source, are changing the
ground rules for business itself. It began with a famous offspring of the open
source movement, the Internet.
Networked markets are beginning to
self-organize faster than the companies that have traditionally served them.
Thanks to the web, markets are becoming better informed, smarter, and more
demanding of qualities missing from most business organizations.
To traditional corporations, networked
conversations may appear confused, may sound confusing. But we are organizing
faster than they are. We have better tools, more new ideas, no rules to slow us
down. [CTM]
A new culture prevails in the business
world. We live in an economy where the primary resource is not limited and
regulated, but, freely exchanged, it multiplies as it is traded. "Mergers
and acquisitions" do not warn of multinational dominance in a globalized
economy. These changes are no more than an Industrial mindset grappling with
the problems of global communications; not realizing the Grand Unified
Corporation already exists (it is called "Humanity"), they expand
their castle walls in a fool's quest to streamline communications. I wish them
luck. There are no "internal" communications.
|
Communications is Everything Open source is not a revolution. It is an
evolution, a recognition that knowledge in motion fuels our economy, that
knowledge is only additive and its value accrues only when it is shared. The FSF could demonstrate the potential of a free exchange
of ideas, but it took a critical mass of open communications to complete the
picture: Plain talk freely moving between peers is the secret progenitor
behind the famous offspring of the Internet like Apache and the Linux O/S. If
"Open Source" did not exist, it would not have been necessary to
invent it, it would have happened. |
When the prospective Open Source Consultant
asks "Why should I support GNU/Linux?", this could could be read,
"Why should I add support for GNU/Linux products to my repertoire?".
I propose a deeper meaning. I propose defining support in the political sense,
in the cultural sense of supporting the social forces which are changing the
computing landscape, and changing the basis of commerce.
How Big is Open Source?
Let's take a short aside to re-assure those
who want to know if it is worth their while to service the Open Source
marketplace. Linux may give some clues as to the size and rate of growth of
this movement. Different pundits put projections on the growth of Linux at
different rates, but almost all agree: We are headed for world domination,
perhaps within the next 3 to 4 years. Linux already commands 31% of all
webservers, 24% of all servers, and 5% of all desktops, and this only considers
those units which were sold. (see Figure
1)
IDG and other industry pundits almost
universally find Linux as the only O/S growing in market share, and growing at
an alarming rate
The Growth of Linux
"How do you
extrapolate 'Exponential'?"
Jeff Prothero's 1998 essay called "The
Last Dinosaur" asked "If Linux has been doubling its market share
every six months for the past decade, how should an analyst extrapolate the
curve?". When his paper was first posted, Linux was estimated to command
2.5% of the market; Jeff projected 10% of all desktops by 2000 if the doubling
trend continued, followed by 40% by 2001 and market saturation (aka world
domination) by January 2002.
Our most conservative estimates put us a
little behind those figures, but his essay accurately predicted how the
unthinkable could happen in 1999 when big business discovered a business model
(or many business models) for Open Source. Linux became inevitable: Once just a
few the large enterprises came on board, others were keen to follow (see Figure
2. Jeff's essay concludes ...
"The conservative assumption, then,
is that when Linux reaches 10% of desktop market share, the third-party desktop
software developers will likewise jump on the bandwagon. Understandably: a 10%
market share gain is enough to interest the shareholders. We may expect to see
this avalanche effect to kick in on the desktop market sometime in the year
2000."
Figure 2. IDG:
Charting the Use of Linux
Microsoft's new Windows 2000 is as much a
bonus to Linux after its delivery as it was during the long delays.
More telling than sales and other market
metrics of size and growth are the Internet "mind share" metrics for
Linux. If we can agree that business will be deeply intertwined with the
Internet, then a measure of the buzz over open source may be useful.
Table Table
1 is a simple and unscientific experiment comparing relative search hits on
AltaVista. Over just 14 months we see every O/S losing percentile market share
except Linux, with some slight gains in other Unix systems once the Linux Fever
began in early 2000. What is abundantly clear is how, among all its peers,
Linux is rapidly gaining the mind share of the Internet. Remember what I said
about good ideas on the FidoNet?
Table 1. Comparative
"hits" for AltaVista based on [JP]
|
Keyword |
Jan 10, 1999 |
Oct 29, 1999 |
Mar 10, 2000 |
|
Windows |
2,530,775 |
6,748,317 |
9,997,800 |
|
Linux |
502,053 |
984,844 |
5,876,340 |
|
Solaris |
251,513 |
453,884 |
586,690 |
|
HP/UX |
105,833 |
180,612 |
214,587 |
|
FreeBSD |
81,781 |
180,547 |
671,895 |
|
MacOS |
70,851 |
133,882 |
161,925 |
|
UnixWare |
23,386 |
32,994 |
85,415 |
|
Ultrix |
15,133 |
26,351 |
38,530 |
|
OpenBSD |
11,892 |
13,354 |
52,960 |
Industrial Time Lags
Figuring aside, mass acceptance of new
technology doesn't just happen out of statistical necessity. Are we closing in
on the days of Linux in 'prime time'? I believe it is inevitable, but before
you rush to buy more shares, I'll add a caveat: For very real reasons which may
even be natural laws, world domination may not happen as soon as we'd like.
Figures like Netcraft's Web Survey tell us that, in certain markets,
Linux and Open Source are already the industry norm, and they hold great
promise for the future, but there is still one more principle to consider: You
cannot rush evolution.
Bucky Fuller, famous inventor of the
geodesic dome, spent a lot of time charting the time lag between invention and
mass acceptance. He discovered fixed lag times specific to each
industry. In electronics, it is 18 months. In the building trades, 30 years.[RBF]
Rather than be discouraged, Bucky concluded
an inventor should build their better mousetrap even if the initial response
is dead silence. If it is truly useful, mass adoption will come, but there
is no way to hasten it; it comes in its own time (I hope Michael Cowpland is
listening!). It is important only to realize that process can not start until
the inventor announces the new invention.
Time-lags in Software Engineering
My own informal observation in our industry
shows we are no where near as fast as the electronics industry. We took 4-5
years to accept CPM, 4-5 years for DOS (just in time for the Mac), 4-5 years
for GNU-C and Emacs, 5 years for Windows 3.1, and it has taken just under 5
years for Windows95 (it was introduced in 94 and was still pretty fringe in
1998).
Linux was introduced as a research tool in
1991. By 1996, Bob Young found Linux commanded a fair mind share of that
market. Bob introduced the packaging of Linux for the server/developer market
in 1996, and he's right on schedule with his IPO. Mandrake scored product of
the Year in 1998 which puts the capture of the desktop market at 2003, and
Corel's bid to capture the office desktop close behind in 2004. It's kinda
spooky how these dates fit both the IDC pundits and Jeff's growth-doubling
algorithm.
There are two lessons here. The first is an
illustration how the "Release early, release often" credo only gives
the illusion of hastening mass adoption by pushing ahead the initial
announcement, and the second is that, for those of us vying to service this
industry, these dates give us our time lines. If we want to know what is
feasibly to have widespread by 2003, we need only look back two years in the
Linux support industry for our clues.
Milestones to World Domination
At the ITAC
"Roadwork" conference in 1994, I was talking with an old-timer about
the soon-to-be ubiquitous Internet. At the time, I thought we would see mass
acceptance of the Internet very quickly, 1996 at the latest, yet I was
continually frustrated by the blank stares I'd get when I offered to put a
business online, or even install free email for them. My colleague gave me an
observation which proved itself then, and which proves itself in every new
technology. He said:
When I was a young boy, no one in their
right mind would own an automobile. To own a car, you had to be part
carriage-maker, part small-motor repairman, part bicycle repairman, and be a
little suicidal. Before we could have a car in every driveway, we had to have a
mechanic in every village, gas stations on every corner; if you car was broken,
either someone could fix it quickly, or they could lend you another.
Open Source consulting is
about that infrastructure. It is about putting a mechanic in every village,
about roadways and driving lessons and all the infrastructure an industry needs
to survive. Eazel could put
the next killer desktop out on the market tomorrow, or Cobalt could release the
killer network appliance, but without the corner shops to sell and service
them, without the books, technical support and guidance in every village, they
won't go anywhere.
Consulting Opportunities
If you have been following the growth of the
LinuxJobs page on
LinuxToday, the Linux
jobs on Monster.ca or just reading your local paper, you'll know the score.
Three years ago, you would be hard pressed to find a job offer listing Linux in
the requirements. Today they are everywhere. Employers now report turning to
Linux because, while they have trouble staffing in other platforms, every new
graduate seems to have at least some experience in Linux; as we shall see when
we look at training, even where a graduate may have some academic experience in
another O/S, Linux people tend to have real-world production experience, and
without ever having had a real job.
All that said, employers still report a
shortage of Linux talent and that means a hayday for those who will work on the
advertised projects. Right now, there is a popular myth of a shortage in
computer talent in general, and in Unix programmers and system administrators.
I believe this situation is misleading as many of the advertised jobs are in
working conditions no one in their right mind would take, and since choosing
Linux is good evidence of sanity, QED.
|
The Mythical IT Shortage Despite all media hype, repeated studies
find no shortage of skilled IT workers[NM],
although there is a huge shortage of Dilbert candidates. What the unfilled IT
jobs stats betray is nothing more than a cultural shift in expectations[CTM].
Even our young are less than willing to relocate to a strange new city on
only a 3 or even a 5 month guarantee. With downsizing, ¾ of all IT projects
being canceled before completion and a growing interest in a quality of life
over the size of a paycheck, the paychecks can grow as high as they like and
the jobs will remain vacant. The experiment to support my theory is
easy: Put a job listing on any site you wish and promise full-time
telecommuting with proper infrastructure and remote worker support. Watch the
lineup form. I have repeated this experiment many times over the past 15
years and have watched others repeat it; the results are remarkably
consistent. IMHO companies who require geographic
proximity betray themselves as ignorant (or afraid) of the very technology
they seek to master, and as such, qualified people stay away. When we
investigate the supposed 300,000 seat shortage of skilled programmers, which
we do as a matter of my own professional and academic interest, we find
interesting patterns. ·
Virtual corporations
and offering full-time telecommuting distributed workgroups find all sorts of
top-notch people within a few hours of a mere Usenet posting ·
Many open positions
are suicide missions. *.jobs newsgroups
seethe with these; sometimes I get angry and rant at them. Due to bad
council, these companies had a Project Manager who locked them into
huge-ticket but highly inappropriate technology, and then bailed for a better
offer (or before it hit the fan. Now the company needs a saviour, or a scapegoat.
·
This is very well
documented: Many ads seek to hire new immigrants and new graduates because
these people will work for less and under worse conditions, and are more
desperate for something to show on their resume. This is also true in other
staff-shortage industries such as collection agents and hairdressers. Let an old-timer
pass some advice to the youth reading this: Don't sell yourself short. You
have knowledge even if all you know is how to use the technology to
find your answers. In an information economy, networking knowledge is
more power than you imagine. Yes, you need a job, we all do, but if you work
yourself to death in an underpaid and exploitive job, don't think for a
moment they will even thank you --- they are more likely to dump you in a
wink the day they have a bad quarter. ·
Some just betray
themselves as thinking too highly of themselves. To be fair to them, we
should remember that Narcissus did not know he was looking at his own
reflection when he fell in love with it. Still, in a network world, it is the
honest pitch that finds the mark (if you will pardon the mixed-message
metaphor borrowed from scam artists): A company who portrays itself as just
people, presented honestly, with all their foibles, is more likely to attract
quality talent than a slick marketing affront painting themselves as the
coolest place thing since Andy Warhol. Employers are being naive:
We need to step out of our cubi-cell and proclaim "Everyone! A
meeting!" for no real reason except to shoot the breeze and talk
straight for the first time in our lives. What's more, we need to let
everyone within our charge also speak just as freely and without fear.
Instead, we see too many management styles who call that meeting only to see
their minions drop their tasks and file in under their command. The good ones
feel like kindergarden teachers, and the bad ones ... Face it. It's time we started treating our
employees like graduate students. |
Nonetheless, pollsters predict Linux use
growing at 25% per year, and all of the Linux vendors I know have experienced
huge growth over both of the past two years and no end in sight. This is
creating a terrific sucking sound in around the Linux talent pool as all the
existing vendors, and all of the new vendors, scramble to find any Linux
experts available. For fun, two years ago, I listed my resume with the DICE
service in the US --- I had no real interest in moving to the USA but thought I
would test it out: I had so many calls it became annoying. To be fair, I have
more experience than most, but on the other hand, most of the callers had read
no more than the first mention of Unix.
And we are only at the beginning. Linux is a
small village on the world market. As a village, there are a few vendors of
each type, and many vendors multitasking diverse product lines. As the village
expands, as the installed base grows, opportunities and diversity can only grow
with it. We have only begun to see the business model for technical support and
value added services in open source software, and as the pressure mounts, more
and more businesses are going to realize that Red Hat gets more applicants in a
day than others can find in a month because Red Hat is treating people like
human beings. Open source just may be a powerful carrot that coaxes information
technology shops out of the cotton gin.
This future is not just rosy
for those with ample experience. There is also much work which can be done
*during* your training. Many Unix sites are large sites with several tiers of
sysadmin positions; many current job postings for unix administrators are for
the lower positions, jobs involving a pager and being ready to attend to
critical applications on shift work, but the level of expertise required may be
no more than you might get out of a book like "Linux Systems
Administration Unleashed". The low cost of Linux and BSD also makes these
attractive to very small sites; for example, small ISPs of less than 100
subscribers or small departmental servers for non-profit orgs, and both may let
you "Learn on the job".
The Consultants' Toolbox
|
|
|
We've established the market share of Linux
system and the market requirements for support. I've hopefully also instilled
some sense of necessity for providing the guidance businesses will need in the
new digital economy and how we are uniquely poised as the gurus, the native
guides of that shift. The question now is how to make this happen.
First and foremost, Open Source consulting
is a business, and it is a service business which must adhere to the same
requirements and practice standards of any service business. Professionalism
and integrity, responsibility and good management are common among all service
workers, but I don't need to tell you that. The sections that follow will cover
some of the best-practices we share with other consulting services, and I hope
you will bear with me while I repeat the obvious, but I also want to cover some
of the aspects which are new in our business, and the new opportunities Open
Source grants us to build a new kind of service industry.
Consulting is a People Business
Surprise, surprise. This integral point in
consulting is mundane, but all-pervasive: Consulting is a people business. Your
clients have needs, you have knowledge (and networking) to make this happen,
but before we can put these together, we need to understand each other. To sell
anyone on risking their hard earned cash to someone they have possibly never
met, and probably have no prior experience, there is a lot of reassuring, a lot
of shaking hands, making presentations, writing letters, emails, phone calls
and visits.
Presentation
Before you buy a suit and enroll in Dale
Carnegie, keep in mind that the best presentation of yourself is to present
yourself as you are and not some constructed image of yourself. As we've
discussed, networked markets are not stupid markets. They know about marketing
and media, and they can see through the masks. They also know about
internetworking, and the new market expects a different face to come out of it,
a human face. A case in point was an online Careers website who caused an
explosion in membership on their "resume and jobsearch" portal by
changing the name from Career Central to Cruel World.
At the '99 LinuxExpo in Raleigh, I spoke to
an old-school MIS person who remarked about the general flavour of Linux
presentations, "Everyone says, 'have fun!' I've never been to a conference
where every talk ended this way." Your clients are not accustomed to this,
but make no mistake, they welcome being granted the right to be human.
The re-humanizing of business through the
open source movement is apparent in our presentation materials. No one wants a
Powerpoint presentation and a slick 4 colour proposal, and if you look around
at the Linux expos, notice how even the staid and conservative stalwarts of big
business go out of their way to dress-down. I don't think they know why,
but we do: A networked market does not trust a slick presentation; it expects
and demands an honest, direct and even blemished communication. It wants a
conversation.
Avoid talking down to clients or speaking
obtusely; they are well-informed and understand their market and their
occupation. If they don't understand what you are saying it is not because you
possess some secret arcane knowledge. It is because you failed to explain
yourself. To say that in our language, the Client-Server model must be a
peer-to-peer model. If I gave you an obtuse and clouded API for RPC, you'd call
it a bad design; business communications is exactly the same.
When to say "No (thank you)"
Turning down contracts is one of the most
difficult tasks for the beginner, and this is no easier in the open source
support world than in any other service industry. Sometimes, you just need to
walk away. Newspaper classifieds abound with help-wanted ads for hairdressers
and collection agents, and software contract offers also tend to overflow with
what I call "suicide missions", jobs you have no hope of completing,
and for which the company needs a scape-goat.
The most sure-fire symptom of a suicide
mission is a call for a system designer, for a top level architectural job,
where the requirements list only constraints, typically a checklist of
inappropriate technologies. Most likely, your predecessor presented an
ill-conceived plan, was granted a budget, purchased a lot of disjoint toys, and
then bailed. Another warning light is stock options in lieu of decent wages;
they may very well be legit, but if it runs sour, you're unlikely to ever see
those stock options (unless your sister is a lawyer). It's not up to you to
finance a new company; we have venture capitalists for this.
As much as you may love Open Source software,
as much as you may want to be among the foot soldiers of the Revolution and aid
in the indoctrination of yet another corporate shop, always be mindful of your
own needs. If you fail to care and fuel the engine, the car stops, and this
does no one any good.
Philosophy 101: Project Planning
In preparing your presentation and your
project plan, my best advice is to appeal to the original methodology guru,
Aristotle. In "The Four Causes", we get an ancient philosopher
outlining precisely what is contained in all the volumes of UML guides, but in a characteristically concise and
elegant plan:
·
Aristotle's first cause
for any action begins with the Formal Cause, the plan of what we intend
to accomplish. In software engineering, this is called the "Requirements
Specification" and lays out the business problem that the software is to
solve. In UML, this is the suite of use-cases.
·
Once we know what we
need to accomplish, the Material Cause follows showing the components we
employ to effect the solution. In UML, this is our
set of data structures and the data sources our program must handle as
illustrated by Class and Object diagrams.
·
Given the ground we
must dig, the Efficient Cause enumerates the methods by which the
components interact; in software engineering, the Material and Efficient causes
are generally lumped into a "Design Specification" but this is
probably why there are so many bad specs that fail to put the data components
first. In UML, the Efficient Cause is our
interaction graphs, collaboration and state diagrams
·
The last cause to form
our plan is aptly called the Final Cause and this is the blueprint for
the goal of our action, the implementation specifications, the component and
deployment diagrams
Together, these four Causes guide a
complete picture of the project, and it is worth noting that none of them
include notions of time lines although each does lead to a modular view of a
project that can be sifted for milestones. You may also want to consider a
fifth cause, proposed by the eccentric particle physicist Jack Scarfatti, that
being the Future Cause, but that is material for another paper.
Groundschool
This isn't the web. You can't simply set
yourself up as an open source consultant because you know how to turn on the
computer and boot LILO to a Linux partition. You can, of course, and no
centralized body is ever going to stop you, but I want to implore you not to
do it if only because we have an opportunity here to do so much more than
simply fix broken shell scripts.
Open Source consulting can be so much more
and all it takes to get there is a bit of attention to the whole picture, to
the gestalt of where what we do fits into the scheme of things. This is going
to require some extra work, but copying what was done in the previous
generation of consulting is not going to get us anywhere.
Clarity
A consultant's success rests as much on the
art of conversation as on the art of good systems design. With Open Source, the
tools and products themselves may not have the best end-user manuals, so a
major part of the job will be mediating for that lack of documentation.
Contrary to a popular belief, obscure coding and bad docs are not job security;
they are an excellent way to squander your reputation for integrity. All we
need is one client left stranded with a system of ours to become cut off that
entire industry for a long, long time. Remember: Markets are networked, and
they talk.
With Open Source, we can afford to talk. We
can be honest and open with our time lines and project plans. A schedule based
on Apache Jakarta knows and accepts that the deliverables in Jakarta are beyond
the control of our PERT chart. If we're really
pressed, we can run with what we have, but for the most part, there is a sense
of human realism in Open Source, a sense that things happen when they happen,
and not a moment before. I believe this is a healthier way to run our projects
Open Source also saves us the rigours of
traditional top-down software design and encourages a more rational and organic
approach; we still need good requirements and systems documents, we still need
to apply foresight to our data structures and tailor our algorithms, and we can
still use UML or reverse engineering to map and plan
our work, but we move in smaller and more flexible "release early, release
often" time-scales. Open source, by being victim to global whims of its
community, carries an inherent sense of scheduling fluidity that includes
adaptability as a basic requirement.
|
|
Requirements vs
Constraints |
|
|
Confusing requirements with project
constraints is a common error in creating project specifications; any design
specified to fit its constraints will be bound to those constraints, and
experience tells us our constraints almost always go away. A corollary rule is that, with a few
exceptions, true requirements are never known completely in advance.
Invariably there is a list of things the program must do, but no guidance on
how it is used. Fred Brooks said, "even the best planning is not so
omniscient as to get it right the first time. Hence plan to throw one away;
you will, anyhow." and I agree: No one knows what they really want until
they see what they don't want. Avoiding wasted time on dead-ends and
inappropriate methods is yet another reason to start the conversation, to
"release early and release often". |
Integrity
To move in a world of clients and contracts,
we need integrity. Integrity is our commodity; we must strive to have only
happy customers, even among those we disappoint. Again, clients are networked,
and they talk.
Integrity is also essential within the Open Source
community. This community is very sensitive to your stature within their ranks,
and, for better or worse, there is an implicit order of reputations gained by
actions. We can no longer simply pay for a college course, get our certificate,
hang up a shingle and lord over our domain. Open Source requires
participation, and demands it. To be effective, to stay current and be
supported in your own work, you need the community. Arriving late at the
party, hanging on to proprietary ways world in deference to open source, these
things can lessen your stature. Many large businesses find themselves in this
awkward position; today they are bending over backwards, at great expense, to
undo that damage.
This does not mean we must pledge here and
now to never boot Windows again (even though that is a very good idea), but it
does mean that the sooner we grasp participatory open source philosophy, the
sooner we can put it into practice, and the better off we'll be when we
discover our entire industrial sector is now an Open Source shop. No one minds
if we keep an MSCE certificate on our office wall,
but your survival depends on understand its limitations.
Learning
|
|
When a man teaches something he does
not know to somebody else who has no aptitude for it, and gives him a
certificate of proficiency, the latter has completed the education of a
gentleman. |
|
|
George Bernard Shaw,
"Man and Superman" |
We've talked people skills and reputation
with the community. There is also, of course, a need to know your stuff. How do
we get all these? Fortunately, in open source, the answer is easy. Those of you
who came to this document to learn the secret of cramming your head full of all
the magic needed to be a top notch Linux hacker-for-hire may be a little
disappointed to find this secret forming such a small part of the whole paper.
Yes, there are courses, there are tutorials,
books, lectures and certifications without number, but these are all
extraneous, maybe even superfluous, all of them relics of an old way of doing
things. You already have every thing you need: You have the source code to
study, real production systems you can tinker with to your hearts content on
even the most modest workstation, and you have tens of thousands of mentors.
Unlike every major technology to precede Open Source, everything technical you
need is given freely; half of it is right there on your Linux CD, and the other
half is online 24 hours a day.
It gets better: The two most essential
components for your toolkit, the people skills which arise from experience and
the integrity that accrues exposure is in the very fabric of Open Source
computing. I have said it many times so far and will likely repeat it
again: Participate!
Open Source University
What other technology invites you to
contribute even if the best you can do is to run the software and report where
it fails? What other technical field abounds with volunteer projects eager to
count you among the core engineering team? Even in the Linux kernel, we know we
have Linus, and we have Alan Cox, but of the other "core developers",
who even knows the number of them let alone being able to list their names? And
this week's list will be different from next week's list.
Participation is as easy as deciding what
interests you, as easy as finding some software that you need, or very
nearly to what you need by, doing a search on FreshMeat or SourceForge, and
jumping right in (being careful, of course, to follow protocol and make an
effort to fit into the community; these are the people skills). Yes, you can
pay $1500 for a 4-day crash course, or you can pay yourself that $1500 to take
two weeks off to sit and dissect, and hopefully fix KVoice
or Mozilla or Kernel SMP
support. How could any college teach you better than first-hand experience
working with top engineers on a real-world project? Linux is the world's
largest post-graduate university with a full-time co-op program, and its free.
Syllabus
You will already know what technical skills
you need: You do what interests you, and keep in mind that confidence comes after
success, never before. The very best training is in pure play, in taking
systems apart, breaking them, fixing them, breaking them again. My first true
lesson in Unix system administration came the day I tried to move my /lib directory to another partition — I quickly
discovered the extreme dependence of all other basic commands on those files,
and also learned how to boot my machine with the install disk, mount the drive,
and fix the problem.
My other favourite training ground was the
break-neck speed of the development kernel; by only updating my software within
hours of a new release, I encountered more hard problems than I might have in
years of academic study, and while I gained the accolade of a "CVS surfer" from colleagues, I learned a broad
repertoire of problems and fixes. 90% of consulting is simply recognizing the
problem and executing the solution.
Intrinsic to all of this, though, was the
network of kind colleagues and patient project members who did not mind 50
repeats of the same question when a kernel release upset some core system tool.
Once again, the tool-box of the open source consultant does not end at their
own desktop, it includes the world.
Chickens and Eggs
In Japanese, the word taiken means
"knowledge gained first-hand from direct hands-on experience". We see
career colleges giving tag-line lip service to how well they simulate hands-on
training, but every employer knows there is no substitute for taiken,
for real experience. A consultant can never have enough.
In the old way of doing things, a new
graduate gets stuck with the koan of "no experience, no work; no work, no
experience". Open Source has solved this problem so perfectly that no one
even thinks about it anymore; top employers like IBM simply raid top open
source projects for participants with the best reputation.
The beauty of this "school" is it
welcomes and accommodates everyone. There are simple shell scripts to fix,
there are intensely technical kernel components to extend and debug, and no one
stands over you to demand that you work on any particular bit or on any
schedule. If you hate debugging but thrive on cutting edge research, there is
room for you. If you like the deduction/reduction game of difficult debugging,
there is room for you. If you have oodles of low-level database experience,
Postgres welcomes you, and if you dig the depths of high-performance computing,
the Trillian Project
would like to meet you. Even if you can barely code the Fibbonacci sequence,
there is room for you. Best of all, we all know that peer-group discussion is a
major component of any education; any distance education that fails to simulate
the hallways and cafeteria as well as the classrooms and lab is doomed, and in
Open Source, there is no end to discussion. There are thousands of mailing
lists, newsgroups, IRC channels, online lectures, and conferences like this
one. Open Source software lives and breathes life-long learning.
Those who came here to learn
about learning enough to become a Linux guru can leave now. I'm done.
Setting up Shop
This section is not so much about Open
Source as it is just about the dull parts of consulting and running your own
shop. For the consultants who were looking to move into open source, this
section is old hat. For those on the other side of the fence, the technicians
and engineers who want to branch out on their own, this part is for you.
If you are like I was when I started, I had
a pretty good head for the technology, and virtually no business sense at all.
Since consulting is a business, it makes sense to learn a bit about the
consulting business itself. From my own experience, I can also say that this
area of my work is still my weakest, in part because I am still torn between
what I think I am supposed do (aping the mainstream consultants) and
what I know I must do to survive in the new economy. We don't want to
make the mistake of following the dinosaurs into the tar pits, but that does
not mean we cannot learn anything from their experience.
Accounting and Incorporation
Most of you probably know more about tax
laws and finance than I do. I'm hopeless with cash and make no apologies. About
all I know about money is that, in my country, most of it vanishes into the
government unless you are very careful. One thing I do know, from bitter
experience: Don't wait until you are saddles with a $25k tax bill to
incorporate. It is simple, cheap to do, and saves a lot of heartache later.
Take some advice from an old-timer: Find yourself a corporation lawyer, at
least one partner, and incorporate.
|
|
Naming your business |
|
|
While you are at it, you'll be asked to
name your new corporation. I implore you, do not do as I did; follow the lead
of Marc Ewing or Jeff Bezos and choose a name which has nothing whatsoever to
do with either your business or with Linux, GNU or any specific item or
service. Corporations (hopefully) live a long, long time and you stand a
better chance of brand recognition with a neutral name than with one tied to
the wrong industry |
Somehow related to all this tax stuff is
accounting. The short advice is "Just do it" and even better advice
is "Marry someone who will do it for you", which is what I did.
Unlike a vendor who has tangible inventory and real flows of boxes in and out
of the shop, the consultant must be very careful to document their activities or
face the wrath of the tax man. Drive to the mall to pick up a parcel? Log it.
Donate time on a local community project? Log it. Track your time, even the
time you spend administering your own desktop, and track it as finely as you
can; if you hated doing this when you were working for someone else, you will
hate it just as much doing it for yourself, but at least you will understand
why your employer was so adamant about it.
|
|
Linux Accounting
Software |
|
|
Not to sell anything, and by the time
you're done here there will probably be alternatives, but for most
consultants' needs, open source programs such as the Starnix's BANAL will help you avoid keeping a
"ghetto" Windows box just to run accounting software. GNUCash is not there yet,
but is one to watch, and if you are not adverse to paying for software, there
are several good packages; Proven
Choice Dk is cheap, quite usable, and even handles Canadian tax and GST. |
Consulting Rates
|
|
What I need is a job that doesn't
interfere with my work. |
We all want to work on open source and it
sure would be a bonus to be paid for it, but the software engineer is already
one of the most exploited occupations. It does no one any good perpetuate this
by selling yourself short. Under-cutting other consultants by gross amounts
only makes us all look bad, and operating at a loss is not very good for
business. Our costs in open source support are significantly less than
for our proprietary-bound colleagues. We have no license costs, minimal
training fees, significantly lower hardware and infrastructure costs, and, if
you are well networked and respected in the Open Source community, you gain
hefty labour and knowledge amplification benefits. The exact rates you charge
depend on your local market, the industry you serve and your own expenses, and
lets face it, your rates will also depend on whether or not you like the work;
my best advice is to be reasonable, but be flexible. Factor your experience and
your reputation, and price accordingly.
An important consideration is your downtime
and in-house costs: If you estimate you can support your family on $40/hr, keep
in mind that you will only score a fully paid 40hr week during the peak of a
contract; you need to factor in down time, retraining costs (which includes subsidizing
your other work on open source projects), the time you spend in research, in
systems administration of your shop, and especially your time between
contracts. Depending on your industrial sector and your geography, you may see
as much as 30% of your time is revenue neutral; with just this consideration,
that $40 has jumped to $60.
My only rule of thumb in pricing your
services is to avoid fixed price quotes unless you have unequivocal
project specifications; even if you do see such specifications, suspect them as
being pure fantasy. We point to Linux as the epitome of a large project written
in a reactive (rather than pro-active) mode, as something adapted and extended
incrementally and only to meet the demands of the next set of engineering problems,
but in truth all software is written like this. To think otherwise is
wishful thinking backed up by smoke and mirrors. I have been consulting for two
decades, and I have seen an exact specification only once (at Mitel
Semiconductors). Give estimates, place caps, but avoid hard promises. Push for
subscription pricing rather than piece work.
Subscription services are not always
possible, especially with government funded projects, Canada Council grants and
other fixed-expense advance payments, but even where an ongoing hourly rates is
acceptable, it should also not give you carte blanche with your clients'
money. Be realistic and be honest. You may think you can do it in X days or weeks, but unless you have been keeping
excellent logs and have done the identical task many times, you really don't
know. Far better to break your contract into milestones with deliverables, and
give checkpoints along the way; the main reason for the mythic requirements
specifications and and project schedules is not to know when you are done so
much as to know how far you are from completion.
Project Estimates
Of all the components in consulting, the one
I find most difficult is cost estimates. For the newcomer, it is practically
impossible to consider all the factors, and all too easy to underestimate the
costs of simple things like a comma where a colon should go, or a single equals
where it should have been double. Project notebooks can provide clues to your
own patterns of costs in design, development and maintenance, but in this
business, these are most often just that, clues.
All of our work since 1983 has been things
never done before, most often never done by anyone, at the very least, never
done before by me. Prior project notes are useful for many things, but of
limited use in estimating. Sometimes I envy people whose trade allows them to
repeat the same hit single over and over. Still, however fluid the technology
may be, there are some rules of thumb which are slightly more scientific than
Hofstaedter's Law ("It always takes longer than you expect, even if you
consider Hofstaedter's Law")
|
|
Here's a professional tip for project
estimates: I have been using the "Fahrenheit/Celsius Rule" for 19
years and while my clients often don't like the figures, the method has not
yet failed me. Take your best estimate. Double it. Take away 10% and add 32.
Don't laugh. It works. Trust me. |
Seriously, though, as a consultant, it is up
to you to explain the reality to your clients. If there is pure research
involved, separate it from the estimate and put a star beside it. Be honest and
up front. If you can't estimate the time to completion, give some ranges, but
mostly just chart out those dates you can deliver; one of those dates can even
be the date of the more accurate estimate. Your clients will have finite
resources and need to know when cost overruns are no longer worth the expense;
since that is the purpose, if you also keep to that purpose, you are both
working to the same goal.
Contracts and Boilerplates
The short answer on boilerplate contracts is
"Forget it." That said, though, there is no need to reinvent the
wheel and considering your contract is your only link to your payment, it's
worth while to consider your contracts carefully.
Intellectual Property
A common clause in corporate contracts
concerns the intellectual property ownership of all materials developed over
the course of the project. This will often require the return of all notebooks,
software and other materials upon project completion. This clause is one to
watch for as it is most often unnecessary or contrary to the open source
licenses in the tools you are using.
Related to this, there is often a clause
which forbids applying the same technology for a competitor, and in some
instances forbids applying the same technology for any other clients; for any
product-oriented consulting (such as Apache webservers or servlets) this is
also not feasible; most often these clauses can be changed by mutual agreement
with your client, and I find a good compromise where such competitive advantage
is important is to place a time limit on sharing such knowledge with direct
competitors.
Quality Control
Without a dedicated staff devoted to quality
control, an independent consultant is at a disadvantage trying to guarantee
industrial-strength quality control. By "Quality Control", I mean the
usual quality assurance metrics and procedures that ensure a piece of software
does what it was designed to do, and tells where it fails, how it behaves under
stress, and all that jazz. This is essential in any serious software
engineering.
The first level of QA
is the test suite, and this is probably practiced by most if not all software
developers. The program has requirement specs, you step through those specs in
a controlled sequence of operations and verify that your program does what it
was supposed to do.
Software Verification
Verifying software can be as meticulous as
you like, and depending on the business requirements, there may be almost no
budget for this stage, or it may be the most critical. Fortunately, the same
advantage we have in free development tools also applies to software verification:
Branch testing, load testing, profiling and automated regression tests are all
possible using free software, and most of these tools can be found on the GNU
archives at the FSF.
Versioning
The very best method to track your work is
through automated software versioning using RCS or CVS or some similar versioning software. While most of our
projects are single development streams with a small number of developers,
versioning gives us a paper trail of all changes. If there is an dispute over
an invoice or the authorization for some change, it is in the logs. If a future
change upsets some other component of the system, it can be rolled back. When
the software moves back into the client's shop, the CVS
is already set up, primed and ready to move to their server or to be migrated
into an open source archive.
Project Notebooks
As much as notes may accumulate on your
computer, there is no substitute for a bound book of real tangible pages
inscribed with a pen. Programmer notebooks have proved essential in my trade
and I am thankful to Cognos for forcing me to adopt the habit.
Because it is a bound book, the programmer's
notebook becomes a repository for all those bits of paper that accompany a
project. It is a random access volume for phone numbers, passwords, meeting
minutes, email addresses, all available for years to come regardless of changes
in digital storage technology. It is portable, water resistant and can be used
as a kneepad for your laptop. Even project books I thought I would never open
again have resurfaced full of previously explored ideas and decided avenues.
Because it is inscribed,
because it is an expressive medium, your notebook is also a journal and
personal diary, a trail of your becoming. This can be a useful ghost to have.
Marketing Open Source Consulting
|
|
Don't be worried about the fact that
you're just a computer geek and you don't know squat about marketing. Being a
geek is a big advantage in figuring out how to use the web for marketing, and
the basics that you need to know about marketing you can learn from this
page, maybe reading a book, asking around, and also just by trying some
things out and learning from experience. |
|
|
The way things are going, by the time you
read this, selling yourself as a consultant on open source systems will
probably be a moot point. Gone are the days when we had to pause to explain
what Apache was or why Linux should be considered for an enterprise solution.
In fact, two year ago I would have told you to leave the part about being
"open source" until you have already closed the deal, or even until
after the project was delivered and installed. Today, like it or not, open
source and especially Linux are brand names with a powerful media draw.
What this means is, just as we saw with
"webpage designers", we can expect every stray dog to start touting
Linux support in their repertoire. This is not a totally bad thing, and the
market will soon sort them out (although I have been waiting on them to sort
out the web-designers for over 6 years), but when I say "Marketing Open
Source Consulting" I hope to inspire more than offers to configure virtual
hosts on an Apache server.
The Open Source Pitch
I don't have to tell you the performance
stats and other facts and figures which bolster a choice of an open source
project over a proprietary competitor. We all know the drill: Control your
destiny, amplify your workforce, standards based, just plain better (JPB), &c &c &c. No, making the case for Open
Source is not even as simple as when I stopped a large ISP's architecture
meeting dead by announcing how, since BIND, Perl and Sendmail were
all "Open Source", any argument which says we can't use Open Source
because of "company policy" must imply that we cannot use the
Internet. No, there is more to it than this.
Every successful new technology has a fixed
time-lag that determines the time to market; this gives us time to ponder, and
a reason not to burn ourselves pulling on a sunrise. Every new technology also
has social and cultural effects, and when we propose open source to solve a
business problem, we need to explain these effects; acceptance of all new
technologies, from fire to ENIAC, have followed this pattern.
In 1992, Eric and Marshall McLuhan provided
a roadmap of these effects[MM].
Their "Laws of Media" offers a convenient checklist for focusing our
plan:
·
New technology retrieves
features lost in preceding methods. For open source, this is our sense of free
exchange in ideas, a practice which was the norm in the earlier
"toggle-switches" computing world, the norm in the ancient days of
craft, and was also the norm in the early days of Unix. Open source retrieves
the buzz we thrived upon at University (before corporate sponsorships quelled
it).
·
To take over the
mantle, new methods enhance what is good about the current methods. C
enhanced assembler by being just as terse and nearly as efficient, but adding
portability. Object Oriented extended structured programming by forcing the
data as the essential component of design. Free software adds similar
enhancements to the way things are done, the most obvious being the
amplification of our talent through global networking. Open source is more just
than consistent with a networked world, it is a manifestation of it; global
open network amplification exceeds the performance of proprietary workgroup
communities.
·
In the same way the
function call largely replaced the goto,
Open source obsolesces barriers to innovation and communications. It
removes secrecy, the org chart, the project timeline and, to a large extent,
the legal department. The old ways of closed-door development and intellectual
property have little meaning in a networked and hyperlinked bazaar. They were
myths to begin with. [CTM]
·
Finally, a reversal
occurs when we get too much of a good thing. Too much freedom becomes a
constraint, too much collaboration becomes a solo effort. I leave this as an
exercise to the reader to uncover elements of open source which will lead to
its undoing and herald its successor.
Advertising, Affiliates and Partnerships
As Mike Crawford noted, we may not have the
means to blast glossy full page ads in Computing Canada, the Globe and Mail or
even the Linux Journal, but if we understand internetworking, we have something
much better. A small business working on a Linux product can become known
(through hosting and participating in global projects), meet allies and
business partners, and even work together in formal associations to achieve the
same operational scale as the large consulting houses.
While I commend them for what they have done
to create essential online reference sites for Linux and also what they have
all done to directly improve Linux, this is where I believe companies such as
SCO, RedHat, Corel, and even LinuxCare
have failed to grasp the new economy. They are still stuck in the old-world
mindset of acquire and control, the mindset of mergers in a vain attempt to
encompass the world with their intranet. Before anyone gets upset, I realize
all of these companies have individual members who are deeply involved at the
community level, but where I see them failing is that, in attempting to paint
themselves as a unified, hierarchically controlled enterprise effort like an
Anderson Consulting or an IBM Global Services, they are missing out. I believe
this is why not one of them has shown a workable business model for technical
support.
Consultant Networks
There is an alternative, and one I see as
comparable to mammals vs dinosaurs. This is the affiliate network of
independent operators, bound by their own working standards, mutual support and
bound by Internet technologies. Having representatives on five continents is
not for putting a local face on a west-coast consultancy — global networks
should be used to distribute activity across time zones, across cultures, and
across perspectives. Remember, knowledge, like money, increases only through exchange
A true affiliate network of consulting is
not a new idea, but it is one that has not quite appeared. The earliest Linux
affiliate network was the simple Consultants-HOWTO which was nothing more than
a random directory. This was followed, very recently, by each of the new Linux
portal/directory sites creating new directories, not unlike the "Builders
and Contractors" booklet put out by my local Grey-Bruce Homebuilders
Association.
Bynari Global Initiative
In August of 1999, Tom Adelstein founded Bynari International and began
the first steps towards a global network of affiliated consulting companies; at
the time of my writing, this network already handle real collaborative work in
the Texas-Mexico-SouthAmerican area, and has created channels for contract
referrals and equipment/software acquisition in many countries. In Canada, our
own branch network of Bynari
Canada links consultants and support companies from coast to coast across 5
provinces and in both official languages.
Bynari has a way to go before it can truly
say it has "harnessed the bazaar" for global technical support, but
it is less than a year old. Compared to the monolithic one-brand/one-company
approaches of its more famous competitors, Bynari is the only technical support
affiliation aiming for the bazaar; the others are still firmly entrenched in
their Cathedrals.
I expect there are other affiliate networks
similar to Bynari working on this same (very obvious) idea. I also expect each
and every practicing open source consultant has an informal network of
colleagues they routinely call when tasks are either too big or out of their
area of expertise. Because of their open and fluid rules of association, there
is probably also no reason why any or all of these groups could not collaborate
Affiliate Programs
I want to mention affiliate programs because
these can be similar to consulting networks, although most often with some
restrictions, and very often affiliate programs connect with a consultant in a
star topology, like a wheel of swinging seats at a carnival, all revolving
around The Product.
Affiliate programs are business-to-business
partnerships where the vendor of one service promises enhanced support and/or
some degree of profit sharing to its affiliates. A well known example is the
Amazon program that pays a 5% commission on books its affiliates sell; whether
for books, software, hardware or office supplies, there is no shortage of these
deals. These programs should not be dismissed as they do offer a low-cost means
to diversify and generate extra revenue by recommending products you would
normally recommend anyway, but they are missing the point.
|
Affiliate Communities? The affiliate program I am watching today
is the emerging VALinux
Underground program. On the surface, this is similar to those offered by
Cobalt and virtually every other hardware vendor: VA will provide detailed
technical support on their hardware and will include your products in their
own catalogs and directories to fill out their offering; Silicon Graphics did
this for years with their IndyZone2
program. The reason I am so interested in this one
is because VALinux is not typically clueless about internetworking. I am
expecting their affiliate program to become more like their SourceForge and
Server51: Rather than a star-topology where all the seats spin out from VA to
each isolated consultant, I am expecting an omni-topology of internetworked
peers, a swirling relativistic mass where every seat is the best seat in the
house. If Larry Augustin is listening: Don't worry, I haven't patented the
idea. |
Work is where it finds you
So far I have only been talking about how to
handle the contracts which come your way or which may have found you through
the grapevine of your colleagues and peers. This is not such a bad scenario,
though, as I have found in my two decades that almost all really good contracts
arise from just this sort of informal referral network. The only danger is that
your network of friends can become saturated with workers, and depending on
your geography, it may not be as easy to find paying contracts to feed them all.
Here again, the internetworking side effect
of open source is our best ally; if you have used the Internet to train and
hone your Linux computing skills, you have probably also picked up enough
skills to locate contract opportunities and to respond to those calls. The fact
that you are responding with an open source answer is almost irrelevant.
Consultant's Webpages
The headhunters and HR departments will all
tell you that Internet has taken over the contract and job search market. More
than ever before, when people are looking for new hires or outsource companies,
they are moving away from the search companies and simply plunking some
keywords into their favourite search engine. There has never been a better
rationale for finally getting your act together and building a website, and if
you have a website, you now need to ensure it is up to snuff with Meta tags and
in ensuring the resumes of all your principles are there online.
Consultant Directories
Most often, potential customers are not
going to find you. Sadly they will find those who paid the most payola for top
placement on the search engine page or for an ad space on that site, and
because of this, they may give up looking. What they will find, though, is
another artifact of internetworking: The directories and vertical portal sites,
by nature of their critical mass of content, will probably make it into those
first-page search results long before you will. The main lesson in using the
web for any kind of advertising is to "find yourself", go looking for
your sort of service and then try to insinuate yourself into those sites which
you do find.
RFQ and Proposals
As you look for your
specialty niche online, especially if you leave out the open source keywords,
you are likely to find many of the new "Request for Proposals"
portals. One example is OnVia's
Quote Requests. This service which matches requests for services to vendors
and service companies based on a few broad categories; precious few actually ask
for Linux or Apache, but we have had some success in matching what we do to the
business requirements, for example, in applying Linux eqlplus for low-cost,
highspeed internet access in remote rural regions.
Before Completion
In the years since my first introduction to
free software, things have never been better, but they've also never been as
frustrating. All indications are we have only just begun to see the full impact
of open source on the computing industry because we have only just started to
see the effects of the Internet on business — these two market forces cannot be
divided — but we have also only just begun to see the first baby steps of the
brave new enterprises who recognize what is happening to the world around them.
That leaves a large majority still struggling to fit the new order into old
molds. Yes, we have lucrative opportunities in crafting servers, desktops and
embedded applications, we have new opportunities with Fortune 500's,
governments, small businesses and startups, and an overwhelming opportunity to
replace and adapt an aging infrastructure into new "eBusiness"
applications, but we are also seeing a cultural friction of old proprietary
idea-mufflers as they scrape along the pavement.
Over the coming years, I expect culture
shock. I expect more new developers who would take tickets to "Hair"
over "Cats" or "Phantom of the Opera". I already see more
Linux jobs than could be staffed by a conference full of developers, but too
many are grabbing at straws, hoping against hope that Linux alone will salve
their wounds, and firmly stuck in a self-limiting Industrial Age mindset of
control. They are ready and poised only to take a free ride on free software,
still believing that their participation could only be a revenue drain and a
security risk. I think many of those jobs are sitting unfilled because no one
with any sense wants them.
Psychologist and NLP
co-inventor Richard Bandler said, "When we do something and it works, we
do it again. When it no longer works, we do it again ... HARDER"
I expect some great clawing at old ways of
doing. Sad and maddenly frustrating as it is, it is business as usual. This is
the same friction I saw in the shift from mainframes to minis, then from minis
to desktops, and again from private networks to Internet. As consultants, we
can only point to those free and open community players rising to the top of
the IPO heap while even the giant control freaks flounder clueless, wondering
why the old ways won't work anymore.
For those who have lasted with me this long,
I have only one last parting bit of advice from an old timer to the next
generation. Whether I am right or wrong about the philosophical changes about
to sweep business-as-usual, please remember this: All roads are short roads.
Enjoy.
GNU Free Documentation License
Version 1.1, March
2000
Copyright (C) 2000 Free Software Foundation,
Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is
permitted to copy and distribute verbatim copies of this license document, but
changing it is not allowed.
Preamble
The purpose of this License is to make a
manual, textbook, or other written document "free" in the sense of
freedom: to assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or non-commercially.
Secondarily, this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for modifications
made by others.
This License is a kind of
"copyleft", which means that derivative works of the document must
themselves be free in the same sense. It complements the GNU General Public
License, which is a copyleft license designed for free software.
We have designed this License in order to
use it for manuals for free software, because free software needs free
documentation: a free program should come with manuals providing the same
freedoms that the software does. But this License is not limited to software
manuals; it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
Applicability and Definitions
This License applies to any manual or other
work that contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. The "Document", below,
refers to any such manual or work. Any member of the public is a licensee, and
is addressed as "you".
A "Modified Version" of the
Document means any work containing the Document or a portion of it, either
copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named
appendix or a front-matter section of the Document that deals exclusively with
the relationship of the publishers or authors of the Document to the Document's
overall subject (or to related matters) and contains nothing that could fall
directly within that overall subject. (For example, if the Document is in part
a textbook of mathematics, a Secondary Section may not explain any mathematics.)
The relationship could be a matter of historical connection with the subject or
with related matters, or of legal, commercial, philosophical, ethical or
political position regarding them.
The "Invariant Sections" are
certain Secondary Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document is released under
this License.
The "Cover Texts" are certain
short passages of text that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is released under this
License.
A "Transparent" copy of the
Document means a machine-readable copy, represented in a format whose
specification is available to the general public, whose contents can be viewed
and edited directly and straightforwardly with generic text editors or (for
images composed of pixels) generic paint programs or (for drawings) some widely
available drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input to text
formatters. A copy made in an otherwise Transparent file format whose markup
has been designed to thwart or discourage subsequent modification by readers is
not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent
copies include plain ASCII without markup, Texinfo input format, LaTeX input
format, SGML or XML using a publicly available DTD, and standard-conforming
simple HTML designed for human modification. Opaque formats include PostScript,
PDF, proprietary formats that can be read and edited only by proprietary word
processors, SGML or XML for which the DTD and/or processing tools are not
generally available, and the machine-generated HTML produced by some word
processors for output purposes only.
The "Title Page" means, for a
printed book, the title page itself, plus such following pages as are needed to
hold, legibly, the material this License requires to appear in the title page.
For works in formats which do not have any title page as such, "Title
Page" means the text near the most prominent appearance of the work's
title, preceding the beginning of the body of the text.
Verbatim Copying
You may copy and distribute the Document in
any medium, either commercially or non-commercially, provided that this
License, the copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the copies
you make or distribute. However, you may accept compensation in exchange for
copies. If you distribute a large enough number of copies you must also follow
the conditions in the
section called Copying in Quantity.
You may also lend copies, under the same
conditions stated above, and you may publicly display copies.
Copying in Quantity
If you publish printed copies of the
Document numbering more than 100, and the Document's license notice requires
Cover Texts, you must enclose the copies in covers that carry, clearly and
legibly, all these Cover Texts: Front-Cover Texts on the front cover, and
Back-Cover Texts on the back cover. Both covers must also clearly and legibly
identify you as the publisher of these copies. The front cover must present the
full title with all words of the title equally prominent and visible. You may
add other material on the covers in addition. Copying with changes limited to
the covers, as long as they preserve the title of the Document and satisfy
these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are
too voluminous to fit legibly, you should put the first ones listed (as many as
fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies
of the Document numbering more than 100, you must either include a
machine-readable Transparent copy along with each Opaque copy, or state in or
with each Opaque copy a publicly-accessible computer-network location containing
a complete Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no charge
using public-standard network protocols. If you use the latter option, you must
take reasonably prudent steps, when you begin distribution of Opaque copies in
quantity, to ensure that this Transparent copy will remain thus accessible at
the stated location until at least one year after the last time you distribute
an Opaque copy (directly or through your agents or retailers) of that edition
to the public.
It is requested, but not required, that you
contact the authors of the Document well before redistributing any large number
of copies, to give them a chance to provide you with an updated version of the
Document.
Modifications
You may copy and distribute a Modified
Version of the Document under the conditions of the
section called Verbatim Copying and the
section called Copying in Quantity above, provided that you release
the Modified Version under precisely this License, with the Modified Version
filling the role of the Document, thus licensing distribution and modification
of the Modified Version to whoever possesses a copy of it. In addition, you
must do these things in the Modified Version:
·
A. Use in the Title
Page (and on the covers, if any) a title distinct from that of the Document,
and from those of previous versions (which should, if there were any, be listed
in the History section of the Document). You may use the same title as a
previous version if the original publisher of that version gives permission.
·
B. List on the Title
Page, as authors, one or more persons or entities responsible for authorship of
the modifications in the Modified Version, together with at least five of the
principal authors of the Document (all of its principal authors, if it has less
than five).
·
C. State on the Title
page the name of the publisher of the Modified Version, as the publisher.
·
D. Preserve all the
copyright notices of the Document.
·
E. Add an appropriate
copyright notice for your modifications adjacent to the other copyright
notices.
·
F. Include, immediately
after the copyright notices, a license notice giving the public permission to
use the Modified Version under the terms of this License, in the form shown in
the Addendum below.
·
G. Preserve in that
license notice the full lists of Invariant Sections and required Cover Texts
given in the Document's license notice.
·
H. Include an unaltered
copy of this License.
·
I. Preserve the section
entitled "History", and its title, and add to it an item stating at
least the title, year, new authors, and publisher of the Modified Version as
given on the Title Page. If there is no section entitled "History" in
the Document, create one stating the title, year, authors, and publisher of the
Document as given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
·
J. Preserve the network
location, if any, given in the Document for public access to a Transparent copy
of the Document, and likewise the network locations given in the Document for previous
versions it was based on. These may be placed in the "History"
section. You may omit a network location for a work that was published at least
four years before the Document itself, or if the original publisher of the
version it refers to gives permission.
·
K. In any section
entitled "Acknowledgements" or "Dedications", preserve the
section's title, and preserve in the section all the substance and tone of each
of the contributor acknowledgements and/or dedications given therein.
·
L. Preserve all the
Invariant Sections of the Document, unaltered in their text and in their
titles. Section numbers or the equivalent are not considered part of the
section titles.
·
M. Delete any section
entitled "Endorsements". Such a section may not be included in the Modified
Version.
·
N. Do not re-title any
existing section as "Endorsements" or to conflict in title with any
Invariant Section.
If the Modified Version includes new
front-matter sections or appendices that qualify as Secondary Sections and
contain no material copied from the Document, you may at your option designate
some or all of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice. These
titles must be distinct from any other section titles.
You may add a section entitled
"Endorsements", provided it contains nothing but endorsements of your
Modified Version by various parties--for example, statements of peer review or
that the text has been approved by an organization as the authoritative
definition of a standard.
You may add a passage of up to five words as
a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to
the end of the list of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through
arrangements made by) any one entity. If the Document already includes a cover
text for the same cover, previously added by you or by arrangement made by the
same entity you are acting on behalf of, you may not add another; but you may
replace the old one, on explicit permission from the previous publisher that
added the old one.
The author(s) and publisher(s) of the
Document do not by this License give permission to use their names for
publicity for or to assert or imply endorsement of any Modified Version.
Combining Documents
You may combine the Document with other
documents released under this License, under the terms defined in the
section called Modifications above for modified versions, provided
that you include in the combination all of the Invariant Sections of all of the
original documents, unmodified, and list them all as Invariant Sections of your
combined work in its license notice.
The combined work need only contain one copy
of this License, and multiple identical Invariant Sections may be replaced with
a single copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by adding at the
end of it, in parentheses, the name of the original author or publisher of that
section if known, or else a unique number. Make the same adjustment to the
section titles in the list of Invariant Sections in the license notice of the
combined work.
In the combination, you must combine any
sections entitled "History" in the various original documents,
forming one section entitled "History"; likewise combine any sections
entitled "Acknowledgements", and any sections entitled
"Dedications". You must delete all sections entitled
"Endorsements."
Collections of Documents
You may make a collection consisting of the
Document and other documents released under this License, and replace the
individual copies of this License in the various documents with a single copy
that is included in the collection, provided that you follow the rules of this
License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such
a collection, and distribute it individually under this License, provided you
insert a copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that document.
Aggregation with Independent Works
A compilation of the Document or its
derivatives with other separate and independent documents or works, in or on a
volume of a storage or distribution medium, does not as a whole count as a
Modified Version of the Document, provided no compilation copyright is claimed
for the compilation. Such a compilation is called an "aggregate", and
this License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they are not
themselves derivative works of the Document.
If the Cover Text requirement of the
section called Copying in Quantity is applicable to these copies of
the Document, then if the Document is less than one quarter of the entire
aggregate, the Document's Cover Texts may be placed on covers that surround
only the Document within the aggregate. Otherwise they must appear on covers
around the whole aggregate.
Translation
Translation is considered a kind of
modification, so you may distribute translations of the Document under the
terms of the
section called Modifications. Replacing Invariant Sections with
translations requires special permission from their copyright holders, but you
may include translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a translation of
this License provided that you also include the original English version of
this License. In case of a disagreement between the translation and the
original English version of this License, the original English version will
prevail.
Termination
You may not copy, modify, sub-license, or
distribute the Document except as expressly provided for under this License.
Any other attempt to copy, modify, sub-license or distribute the Document is
void, and will automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this License will
not have their licenses terminated so long as such parties remain in full
compliance.
Future Revisions of this License
The Free Software Foundation may publish
new, revised versions of the GNU Free Documentation License from time to time.
Such new versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See http:///www.gnu.org/copyleft/.
Each version of the License is given a
distinguishing version number. If the Document specifies that a particular
numbered version of this License "or any later version" applies to
it, you have the option of following the terms and conditions either of that
specified version or of any later version that has been published (not as a
draft) by the Free Software Foundation. If the Document does not specify a
version number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
Addendum
How to use this
License for your documents
To use this License in a document you have
written, include a copy of the License in the document and put the following
copyright and license notices just after the title page:
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute
and/or modify this document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the Free Software
Foundation; with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy
of the license is included in the section entitled "GNU Free Documentation
License".
If you have no Invariant Sections, write
"with no Invariant Sections" instead of saying which ones are
invariant. If you have no Front-Cover Texts, write "no Front-Cover
Texts" instead of "Front-Cover Texts being LIST"; likewise for
Back-Cover Texts.
If your document contains nontrivial
examples of program code, we recommend releasing these examples in parallel
under your choice of free software license, such as the GNU General Public
License, to permit their use in free software.