Opensource Consulting Howto (Spring 2000)

The Consulting HOWTO
A Guide to Open Source Consulting

Gary Lawrence Murphy
President and CEO
Teledynamics Communications Inc (http://www.teledyn.com)
7 Forest Place
Sauble Beach
Ontario
Canada
garym@teledyn.com
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. 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
(mailto:garym@teledyn.com); it may not be exactly what you need to know, but it is
willing to change.
1
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.
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.
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
2
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
3
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 (http://www.cognos.com) 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
4
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) (http://www.opensource.org), 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
5
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.
6
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
7
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
8
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.
9
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.
10
ClueTrain Manifesto: (http://www.cluetrain.com)

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)
11
Figure 1. IDG Press Releases
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

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.”
12
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
13
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
14
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
(http://www.eazel.com) 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 (http://jobs.linuxtoday.com) page on
LinuxToday, the Linux jobs on Monster.ca (http://www.teledyn.com/help/linux/Jobs) 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.
15
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 16
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.
17
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,
18
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
19
• 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.
20
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. Nicolas Wirth said, “Write two programs, throw the
one first away.” and I say “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
21
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
22
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
(http://www.linuxia64.com/) 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.
23
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 (http://www.starnix.com/banal/) will help you avoid keeping a “ghetto” Windows box
24
just to run accounting software. GNUCash (http://www.gnucash.org) 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 (http://www.provenacct.com) 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
25
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”)
Tip: 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.
26
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.
27
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.
Mike Crawford “Market Yourself”
(http://www.goingware.com/tips/marketing.html)
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.
28
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
29
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 (http://www.linuxcare.com) 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 (http://www.bynari.net) 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 (http://ca.bynari.net) links consultants and support companies
30
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
(http://www.valinux.com) 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 IndyZone 2 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.
31
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 (http://www.onvia.ca). 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.
32
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

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.
33
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
34
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
35
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
36
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
37
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.
38
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
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
39
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.
Bibliography
[CTM] ClueTrain Manifesto (http://www.amazon.com/exec/obidos/ASIN/0738202444/teledynamicsA/), ,
Perseus Books, Jan 2000.
[RMS] Philosophy of the GNU Project (http://www.gnu.org/philosophy), Richard Stallman and al, FSF
Website.
[ESR] The Cathedral and the Bazaar

(http://www.amazon.com/exec/obidos/ASIN/1565927249/teledynamicsA/), Eric Raymond,
O’Reilly, Oct 1999.
[RBF] Nine Chains to the Moon

(http://www.amazon.com/exec/obidos/ASIN/0385011490/teledynamicsA/), Richard Buckminster
Fuller, Southern Illinois University Press, 1963.
[MM] Laws of Media (http://www.amazon.com/exec/obidos/ASIN/0802077153/teledynamicsA/), Eric

and Marshall McLuhan, University of Toronto Press, April 1992.
[JP] The Last Dinosaur and the Tarpits of Doom (http://www.muq.org/~cynbe/rants/lastdino.htm), Jeff
Prothero, MUQ.ORG Website, 1998?.
[NM] Debunking the Myth of a Desperate Software Labor Shortage

(http://heather.cs.ucdavis.edu/itaa.real.html): 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 (http://www.ratical.org/ratitorsCorner/03.20.99.html),

Mose, Ratitor’s Corner Website, Spring Equinox 1999.
40

Opensource Consulting Howto (Spring 2000)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Opensource Consulting Howto (Spring 2000)

Uploaded by

Copyright:

Available Formats

The Consulting HOWTO

A Guide to Open Source Consulting

The Open Source Consultant

The Real “Why” of

Open Source Consulting

Open Source Systems Integration

Participatory Open Source

cannot spare the resources.”

“If only sitting was required, all frogs

ClueTrain Manifesto: (http://www.cluetrain.com)

How Big is Open Source?

Figure 1. IDG Press Releases

The Growth of Linux

Figure 2. IDG: Charting the Use of Linux

Table 1. Comparative “hits” for AltaVista based on [JP]

Industrial Time Lags

Time-lags in Software Engineering

Milestones to World Domination

The Mythical IT Shortage

Consulting is a People Business

you’d call it a bad design; business communications is exactly the same.

When to say “No (thank you)”

Philosophy 101: Project Planning

certificate of proficiency, the latter has

Open Source University

Chickens and Eggs

Accounting and Incorporation

Contracts and Boilerplates

The Open Source Pitch

Advertising, Affiliates and Partnerships

Bynari Global Initiative

from coast to coast across 5 provinces and in both official languages.

Work is where it finds you

RFQ and Proposals

GNU Free Documentation License

Applicability and Definitions

Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy

Aggregation with Independent Works

Future Revisions of this License

[ESR] The Cathedral and the Bazaar

[RBF] Nine Chains to the Moon

[MM] Laws of Media (http://www.amazon.com/exec/obidos/ASIN/0802077153/teledynamicsA/), Eric

[NM] Debunking the Myth of a Desperate Software Labor Shortage

[RC] Learning About community currencies (http://www.ratical.org/ratitorsCorner/03.20.99.html),

You might also like