The Consulting HOWTO
A Guide to Open Source Consulting
|
|
Gary Lawrence MurphyPresident
and CEO 7 Forest Place |
$Revision:
1.4 $
Copyright © 2000 by Teledynamics Communications Inc
$Date: 2000/03/27 17:46:46 $
Open Source consulting is as varied as the
people who make their living at it; this paper only includes my own
experiences, thoughts and advice on training for and entering this field. It is
intended for practicing consultants curious about open source, and those
interested in consulting as an occupation. Both wonder if this "Linux
thing" is worth their while. The short answer is "yes".
The most current edition of this paper can
be found online at http://www.teledyn.com/help/linux/Consulting. The document is
also available in Postscript,
Rich
Text and Portable
Document Format. Many people have contributed to this work, but I alone am
responsible for what is written, and for what has been omitted. Please direct
all questions, comments and corrections to garym@teledyn.com; it may not be exactly what you need to
know, but it is willing to change.
Table of Contents
Marketing
Open Source Consulting
GNU
Free Documentation License
Copyright
Permission is granted to copy, distribute
and/or modify this document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the Free Software
Foundation. A copy of the license is included in the
section called GNU Free Documentation License. While the text of
this document is covered by the FPL, before you do copy this work, be advised
that many illustrations have been lifted from websites and correct attributions
are not known.
prelude
Why should a mainstream, proprietary systems
consultant make the shift into open source? What might draw a young
entrepreneur into a business based on free software? We all know the the
software is free but support is extra, but is this the whole of the business
model? I hope to show that this a very good model, not just because of the free
beer or the philosophical draw of free speech, but because of a surprise bonus
that gives the free software consultant more to offer than their license-bound
counterparts.
The secret of this surprise bonus is in the
words of Linus Torvalds: "I'm basically a lazy person who likes to get
credit for things other people do." Before I get into that, though, I
should mention that I didn't expect any bonus when I started. I didn't even
really notice when it did happen. It just kinda snuck up and was there. I
expect others may be following me, also out of constraints more than
requirements; if it does sound like where you are going, then the good news is
there is a surprise ending.
Bibliography
[CTM] ClueTrain Manifesto, , Perseus Books, Jan 2000.
[RMS] Philosophy of the GNU
Project, Richard Stallman and al, FSF Website.
[ESR] The Cathedral and the Bazaar, Eric Raymond, O'Reilly,
Oct 1999.
[RBF] Nine Chains to the Moon, Richard Buckminster Fuller,
Southern Illinois University Press, 1963.
[MM] Laws of Media, Eric and Marshall McLuhan, University of
Toronto Press, April 1992.
[JP] The Last
Dinosaur and the Tarpits of Doom, Jeff Prothero, MUQ.ORG Website,
1998?.
[NM] Debunking
the Myth of a Desperate Software Labor Shortage: Testimony to the U.S.
House Judiciary Committee Subcommittee on Immigration, Dr. Norman Matloff,
University of California at Davis Website, March 2000.
[RC] Learning About community currencies ,
Mose, Ratitor's Corner Website, Spring Equinox
1999.
The Open Source Consultant
I have been consulting full time since 1981,
and head of my own sometimes-successful company since 1983. Over those decades,
I had seen other trends in what we now call Open Source Computing. The first
was a small terminal-emulator program for DOS called PC-TALK;
although free software had been common in the MULTICS world, this was, so far
as I know, the first widely distributed example of freeware (or Shareware) for
the personal computer. PC-TALK, and the Telix
that replaced it, introduced "free beer" to the PC, or at least the
idea everyone should have decent software. Neither program was initially open
source, and Telix, like many programs of the
day, did ask for a token donation, but both eventually sent out the source code
if only to cope with the demand for new features. Still, these were very much
like the early FSF programs: The developer pool was
tightly cloistered small groups of friends who listened eagerly to the people
who used their handiwork. Within a very short time, Telix
conquered the BBS-terminal market, defeating even stalwart CrossTalk. This was
my first clue: Users are your best co-developers; you can never have too
many of them.
In DOS days, we just assumed applications
belonged to their developers. Toolkits were another issue. Before long, thanks
to Borland, free and open source toolkits sprouted up, C and C++ libraries for
every conceivable task, and like the applications, the maintainers of these
libraries listened and responded. Suddenly, anyone could contribute to just
about any program by creating a clever toolkit, and these libraries spread with
great speed. This was the days, or rather the nights of the FidoNet, a
poor-man's "Internet" spanning the globe from Europe to central
Australia via low overnight phone rate calls to relay email and software from
one FidoBBS to its next nearest neighbour. Over this new medium, collaboration
and distribution of toolkits and applications was international, extremely
rapid, and absurdly cheap. This was my second clue: Internetworking changes
everything.
At that time, I was cavorting with known
anarchists like the composers John Cage and Udo Kasemets. I had been a fan of
Cage, Bucky Fuller, Marshal McLuhan and William S. Burroughs since my teens; in
retrospect, I was probably a powderkeg in search of a terrorist. As an
unabashed advocate of free and unfettered information sharing, free software
appealed to my young mind, it held an almost Kabbalistic hope: "You may
pay for knowledge, but you should never charge for it.". Community
currencies[RC]
would prevail over the economics of scarcity; I devoted myself to learning,
promoting and participating in the Free Software Revolution.
My interest was not entirely spiritual. In
the 80's, corporate computing was dominated by the IBM's and Microsoft's $1000
development packages. Without apologies, a large impetus to bring free and
low-cost software to my clients was my own financial situation: Without these
low-cost and no-cost tools, I was excluded. Had I been less rebel, I might have
learned Clipper like my peers, and financed my own tools or settled in at that
job AE LaPage offered. Instead, as usual, I thought the crooked path looked more
interesting.
Free Software, and later the GNU Public
License, opened doors which did not otherwise exist. I could parley my Timex
Sinclair into an Osborne and that into a PC because bankers could see sense in
lending based on collateral. For my software tools, I was on my own. Luckily,
with Free Software and a nearly-free global network of friends and colleagues,
I was anything but alone.
I still had to pay the bills. Fortunately,
my clients knew very little about computers, proving once again by induction
how "literacy breeds ignorance". My clients were the people on the
shop floor, investors on the exchange desk, people who could not get past their
"MIS Bottleneck", and artists and composers. In short, they were
craftspeople in their own right who cared more about getting the job done than
about the technology used to do it. This gave me license to explore, and I
thank them for that.
Thanks to my network community of colleagues
and co-developers, I was able to learn by the seat of my pants, pull in remarkable
talents behind the scenes, and consistently deliver more bang for the buck than
my clients expected. One contract lead easily to another. This was my final
clue: "No open source developer is an island".
Thanks to this opportunity of circumstance
and a freedom to choose it, 80% of my work now involves only Free Software. I
have a positive cash flow, and there is no end in sight. I could now actually
now afford to license an 1980's IBM Pascal. Borland, the kind source of my
entry to the free software community of the FidoNet, and even venerable IBM,
author of the barriers to my entry, are now both avid participants in our
Revolution. There's a poetic irony at work here.
The Real "Why" of Open Source
|
|
The origin of the word
"community" comes from the Latin munus, which means the gift, and
cum, which means together, among each other. So community literally means to
give among each other. Therefore I define my community as a group of people
who welcome and honor my gifts, and from whom I can reasonably expect to
receive gifts in return. |
|
|
Bernard Lietaer[RC] |
This is how and why I started. Near poverty,
a need to better myself, an aptitude (whatever that is) for independent
learning, a gracious opportunity to pull it all together, and a thin wire to a
life-line called the FidoNet. From there, a number of chance encounters brought
me out of the DOS/Freeware scene into Unix, the Free Software Foundation and
later into Linux.
I first encountered Richard Stallman in
1987, or maybe 1988. His GNU Manifesto was being traded like an underground
novel on USENET. Eager to participate, I wrote to ask if there was anything
someone with a lowly 286 computer could do. Richard said GNU was never likely
to run on a PC, but they had a dire need for documentation; it's another irony
that today, a large chunk of our revenue comes from assisting Macmillan
Computer Publishing in open source book projects.
Anyway, back to RMS: His Manifesto was a
blueprint for practical community economics, a formal and legal framework,
straight out of Bucky Fuller. It lowered the entry barrier to anyone owning a
Sun workstation, and while a Sparc was impossibly out of my own reach, I was,
at the time, under contract with Cognos
Inc where Sun workstations were plentiful. At Cognos, I found my fellow
engineers were already deep into Free Software computing, but for different reasons.
Cognos, known at the time for their 4GL
Powerhouse software, was a world leader in implementing object oriented
technology. Our editor of choice was EMACS, our windowing system was X, our
compiler of choice was GNU C, and most of our other tools were gems peeled off FSF tapes. Why do this? In 1989, Cognos was Canada's
largest software company, and something like 14th largest in North America. We
could afford over 200 programmers and a Sun 360 for each of them. We could
certainly afford any tools the market could offer. Why base the core of the
business on an absurdly low-cost tape from the Free Software Foundation?
Superior performance of the FSF craftwork is only part of the answer, as was their
adherence to industry standards. For our purposes, there was the demands of our
leading edge research: If we needed a fix, we had both the source and right to
change it, but this was not the whole story. Even the "standing on the
shoulders of giants" was only part of the story. Yes, we could change the
software to suit our purposes, but even more importantly, most often,
someone, somewhere else, someone we did not know and certainly did not pay, had
experienced the same need, had already added that feature or fixed that bug,
and had returned the new code to the general pool of knowledge. Our choice of
Free Software was not just about control of our own destiny or building on
prior work. It was about the amplification of our resources through a global
community. This is where all my clues came together. This is where Open
Source computing changes the game, or at least illustrates a very changed game;
this is how Open Source over the Internet redefines "technical
training", and gives the Open Source Consultant their competitive
advantage.
Three things happened at Cognos, three
things for which I am forever grateful: I was bitten by the Unix bug, I came to
understand Object Oriented Design, I learned first hand about the real
advantages of free software, and my wife left me. You can't buy good fortune
like that.
Terminology
Before I get too far, let me clarify my
terms. Throughout this paper, I use "Open Source Software" and
"Free Software" almost interchangeably. I similarly swap the
trademarks "GNU", "Free Software Foundation" and "Linux".
This is out of bad habit, not ignorance.
By "Open Source", I do not mean
simply the granting access to source code; I mean the spectrum of licenses
endorsed by the Open Source
Initiative (OSI), and those they would endorse
if they read them. This is a more liberal definition of "free
software" than the FSF; you could say that Open
Source is a sphere with GPL at its center, or a
diffusion pattern out from GNU. The licenses inside this sphere share a common
bond of allowing anyone free access to the source code, and granting anyone
the right to redistribute modified versions of that code. More over, and more
importantly, these licenses facilitate an open community exchange of
ideas and development.
Similarly, Linux
is itself a GPL (GNU Public License) project, and
most Linux distributions contain a high percentage of Free
Software Foundation (FSF) software, but I use these terms in the loose and
shallow sense to include all software bundled with an open invitation to copy,
share and modify the programs and the collections. Again, an open invitation to
participate which facilitates an open community.
My intent is not to fuel license wars but to
point out the differences between, for example, the community of Visual Basic,
or Delphi, or Sybase developers, and those of a Linux or Apache. Both are
"communities", but there are stark differences which place the
proprietary group at a distinct disadvantage, especially when mixed with the
Internet. Open source groups, by being open to mass participation, can achieve
a critical mass of online synergy unknown to proprietary communities.
Open Source Consulting
As an occupation, "Open Source
Consulting" can be factored into four stages, four scopes. Two of these,
product support and systems integration, have counterparts in traditional
consulting, but the other two have more to do with the culture and education
specific to open source and especially to the new business and software engineering
climate engendered by the Internet.
·
Technical support and
development for specific open source software packages such as the Apache
webserver or the Linux Kernel.
·
Providing design
guidance and development integrating Open Source programs or hybrid systems of
Open Source and proprietary software.
·
Providing evaluation,
procedural guidance and technical support to businesses who need to participate
in an open source project.
·
Managing and initiating
Open Source projects on behalf of a client.
Applications Support
Under the banner of Linux, this is a
burgeoning field. No surprises here, one basically takes what one knows about
some specific component of a program and applies that knowledge for the benefit
of the client. The most common example is supporting the Apache webserver, or
the Perl/PHP contracting.
There is very little difference between this
work and consulting work with proprietary software such as SAP or Microsoft
products. You make a pitch, agree on a price, build a solution, shake hands,
cash the cheque, and move on. This is honourable work, but take my advice: It
is not profitable in the long run. Highly recommended to put yourself through
college (or buy that Gibson guitar) but not something to fund your retirement.
On the positive side, the entry barrier for
this line of work is absurdly low: You can run the same software on very modest
hardware to simulate and develop, then seamlessly migrate to your client's
platform. You can also usually adapt knowledge gained from other platforms, for
example, there is a growing demand for database expertise in Linux circles and
this is a popular niche for down-sized older programmers looking to ply their
trade in this new industry. All the resources to learn and to deploy these
projects are also freely available, and most often authors or other
contributors and users of those tools will freely assist you, all in the cause
of the Revolution.
This line of work is ideal for the beginner;
it requires a basic level of skill and experience, but this background is not
hard to acquire through volunteer projects, and since your contractors may not
understand the Internet information economy, you can go very far flying by the
seat of your pants, going home each night to sit on IRC to solve your previous
day's business problems; you can easily appear to be far more of an expert than
you actually are. Trust me on this.
Open Source Systems Integration
Integration, and with it systems and network
administration, is the subject of 99% of all the so-called "Training and
Certificate" programs. Again, no surprises, you all know what it means:
You provide the glue that holds many Open Source products together in consort.
The job is similar to single-product technical support, except the scope of the
knowledge and experience required is larger, as is the scope of your Open
Source community involvement. A systems integrator, whether installing and
maintaining servers or amassing open source pieces into new network appliances
or a new Linux distribution, is exponentially more muddled in the Small
Details, but essentially involved in the same learning the materials, suiting
solutions to a task, careful debugging, eyes on the road, hands on the wheel,
and moving on after the final cheque and the handshake.
I include Linux and other free O/S
"distributions" under this heading. A Linux distro is, at its core,
an integration of open source (and sometimes hybrid) software. It involves
quality control, smoothing out the rough edges, sometimes some special glue,
but once done, once it is beyond it's lifespan, the romance is over.
Network appliances are also integrations.
Appliances are specialized distributions set into small, special purpose
machines; basically, an in-house distribution duplicated into the hardware
before the unit is sold, usually for use as a firewall, gateway, mail server,
print server, network monitor, & c. Since Linux will run on everything from
old donated 486 hardware, low cost rackmounts to clusters of high-powered VA
and IBM machines, vendors are eager to partner with anyone who can help them
sell boxes through an appliance application.
Appliances are another opportunity for older
programmers. By integrating Linux with seasoned expertise in business software,
special purpose database appliances such as accounting machines, inventory
control and especially in integrating these into ebusiness applications may
find a ready market.
I won't question there is money to be made
in specific applications support and in the more general systems integration,
but I don't believe you can make it to retirement doing this. These are
hand-to-mouth occupations, lucrative while they are happening, but volatile and
without residual benefits. For the open source consultant, the money is not in
tinkering code but in tinkering with business itself. Business is changing, and
those in the internetworked open source community probably have the best grasp
of the survival skills all businesses will need.
Participatory Open Source
Up to now, the service models I've outlined
are almost identical to their proprietary counterparts. There is a major
difference, though: Open source has built in longevity. Simply integrating and
supporting specific systems is a passive role. When the market changes, and if
your technology is something like the FidoNet, you can find yourself suddenly
stranded. Retraining and re-tooling becomes a way of life, a long series of
seminars and retreats. Most closed-source consultants and businesses using
closed source systems with consider this "the cost of doing
business".
Open source is not so passive. Consultants
can actively counter obsolescence through participation, learning about
and helping to form the changes in the technology as it incrementally evolves
to better suit changing markets. Everyone I know who is supporting open source
doesn't even think about this, they just follow the newsgroups or mailing
lists, follow the revisions and patches, and seem to be on top of their niche.
Unfortunately, unless they teach their clients to do this, they may have
failed. This is the third evolutionary step in Open Source Consulting:
Participating ourselves and leading our clients in to participate in the
software they are using.
Unless there is participation, a company may
have their solution today, but may be left with yesterday's technology; the
tiniest shift in the information ecology could knock them flat. They miss out
on the meaning of the Revolution, and it is more your fault than theirs because
you knew better.
For our clients, participating in
Open Source shifts them from being a consumer of technology to being a source.
We see the famous open source support companies such as RedHat and VALinux
using this approach: The open source people they hire to do develop their
products is folded back into the open source community. They can obtain the
innovations they need for their own products, and, in the process, gain inside
information about the future of those systems, they can stay agile and
anticipate changes, and most importantly, by "giving back", they
ensure support from the community.
For the consultant, participating in Open
Source is how we network. It is so normal, it is almost invisible. By
contributing, we are always learning new skills, and investing in our education
and our reputation. Participation is better than an RRSP for ensuring our
future. For these same reasons, it is essential we relay this to our clients.
We won't convince every client. Our clients
will shy away from active participation. They can see open source as a free
ride and counter with "We have no time. Our application is our competitive
edge. We cannot spare the resources."
The excuses cost more than participation.
Fortunately, with every new Fortune 500 announcing its participation in
projects such as Linux and Apache, the case for involvement is easier to pitch.
When IBM, Motorola and Cognos can boldly proclaim they play the open
source game, our clients can at least entertain the notion they can play too.
Proselytization (P13n)
"Is he suggesting I convince my financial
securities client turn their on-line trading systems Open Source?" You
probably already think I am quite mad. You are right, of course. You're mad
too, otherwise you would not have come here, but that is all milk spilled under
the bridge now. The important and critical point, is that, whether or not your
clients will play the game today, they will tomorrow, and since you are only
now reading about how to become an Open Source consultant, you can't possibly
be set up and ready for business before sunrise. QED.
The benefits of turning core systems and
applications into open source projects is staggering. It is more than
staggering. It is probably inevitable: If they don't do it, a competitor will
and they will be left in second place. In an economy of community, knowledge is
not power, knowledge is water. The community is the power. Without trade,
knowledge sours and perverts, it makes silly mistakes, and costs astronomical
sums to prop up the illusion that all is well. Knowledge Management is a myth,
at best it means "Learning to Talk". With all it's resources,
Microsoft could not build a bug-free Windows
after 9 tries; how could anyone presume to do better? With all it's impossible
mass and tangle of "disorganization", Linux is the De facto
alternative O/S, and it grows exponentially in strength and scope with every
new release. Why? Because it understands social networking, it knows how to
talk and does so on a global scale.
Open Source per se is no guarantee
of superior software quality — a simple browse through FreshMeat will attest to
this — but it is also true that Open Source can do no worse than a
closed-shop "cathedral" approach. The worst that can happen is no one
else is interested in your software, or no one can improve upon your genius.
The gains when the software strikes a common chord, however, are significant;
if your client has, at their heart, a need to provide some service, to fill
some market need, no one can question that their best business plan is to do so
as efficiently as possible.
It's important here to make a design
distinction between what software does and how it works, or between its engine
and its implementation. Every newspaper website may need software to parse the
broadcast news feed into a database, but every one of them will have a unique
way to mine that data into a webpage. The obvious common engine, and the most
critical component, is ensuring the data is received and correctly cross
referenced into the database. This is a good candidate for an open source
component. How that data is mined and rendered into webpages depends on the
style and audience of each paper; at best the means of fetching data and
inserting it into a page should be open source (this is essentially what PHP
does), but the final pages themselves are totally unique.
Another example might be an accounting
package. There is a clear difference between the components that take numbers,
add them, store them and move them about the system, and this is a good
candidate for an open source project (GNUCash is working on this) especially if
individual financial services companies can take this basic engine and create
new and innovative accounting systems using their expertise in accounting as
their competitive edge rather than attempting to be the world's best numerical
processing expert.
A real world example is the
embedded-Linux consortium. Their member list includes top tier companies such
as Motorola and IBM mixed with tiny startups; most members had invested
significant resources developing their own proprietary embedded operating
systems, yet here they are, dumping their own work, lowering their defenses (or
inhibitions) about each other, and working together to adapt Linux to their own
cause. Another is IBM virtually abandoning both AIX and Monteray64 because
they cannot compete with the world. Even Big Blue, who might have a case
for marketing their own O/S to recoup development costs, even they have
eschewed re-inventing the wheel. They choose instead to co-operate and unify
rather than to hoard and divide, and they position themselves to enjoy the
benefits of an economy of a community.
Why Support GNU/Linux?
|
|
"If only sitting was required, all
frogs would be Buddhas" |
I probably do not need to outline the
virtues of the famous open source applications. You all know Linux, Apache,
Sendmail, Perl, and you all know how these have changed the face of business as
we know it. This much you know, but what you may not know is how the very
essence of these projects, the principles behind Open Source, are changing the
ground rules for business itself. It began with a famous offspring of the open
source movement, the Internet.
Networked markets are beginning to
self-organize faster than the companies that have traditionally served them.
Thanks to the web, markets are becoming better informed, smarter, and more
demanding of qualities missing from most business organizations.
To traditional corporations, networked
conversations may appear confused, may sound confusing. But we are organizing
faster than they are. We have better tools, more new ideas, no rules to slow us
down. [CTM]
A new culture prevails in the business
world. We live in an economy where the primary resource is not limited and
regulated, but, freely exchanged, it multiplies as it is traded. "Mergers
and acquisitions" do not warn of multinational dominance in a globalized
economy. These changes are no more than an Industrial mindset grappling with
the problems of global communications; not realizing the Grand Unified
Corporation already exists (it is called "Humanity"), they expand
their castle walls in a fool's quest to streamline communications. I wish them
luck. There are no "internal" communications.
|
Communications is Everything Open source is not a revolution. It is an
evolution, a recognition that knowledge in motion fuels our economy, that
knowledge is only additive and its value accrues only when it is shared. The FSF could demonstrate the potential of a free exchange
of ideas, but it took a critical mass of open communications to complete the
picture: Plain talk freely moving between peers is the secret progenitor
behind the famous offspring of the Internet like Apache and the Linux O/S. If
"Open Source" did not exist, it would not have been necessary to
invent it, it would have happened. |
When the prospective Open Source Consultant
asks "Why should I support GNU/Linux?", this could could be read,
"Why should I add support for GNU/Linux products to my repertoire?".
I propose a deeper meaning. I propose defining support in the political sense,
in the cultural sense of supporting the social forces which are changing the
computing landscape, and changing the basis of commerce.
How Big is Open Source?
Let's take a short aside to re-assure those
who want to know if it is worth their while to service the Open Source
marketplace. Linux may give some clues as to the size and rate of growth of
this movement. Different pundits put projections on the growth of Linux at
different rates, but almost all agree: We are headed for world domination,
perhaps within the next 3 to 4 years. Linux already commands 31% of all
webservers, 24% of all servers, and 5% of all desktops, and this only considers
those units which were sold. (see Figure
1)
IDG and other industry pundits almost
universally find Linux as the only O/S growing in market share, and growing at
an alarming rate
The Growth of Linux
"How do you
extrapolate 'Exponential'?"
Jeff Prothero's 1998 essay called "The
Last Dinosaur" asked "If Linux has been doubling its market share
every six months for the past decade, how should an analyst extrapolate the
curve?". When his paper was first posted, Linux was estimated to command
2.5% of the market; Jeff projected 10% of all desktops by 2000 if the doubling
trend continued, followed by 40% by 2001 and market saturation (aka world
domination) by January 2002.
Our most conservative estimates put us a
little behind those figures, but his essay accurately predicted how the
unthinkable could happen in 1999 when big business discovered a business model
(or many business models) for Open Source. Linux became inevitable: Once just a
few the large enterprises came on board, others were keen to follow (see Figure
2. Jeff's essay concludes ...
"The conservative assumption, then,
is that when Linux reaches 10% of desktop market share, the third-party desktop
software developers will likewise jump on the bandwagon. Understandably: a 10%
market share gain is enough to interest the shareholders. We may expect to see
this avalanche effect to kick in on the desktop market sometime in the year
2000."
Figure 2. IDG:
Charting the Use of Linux
Microsoft's new Windows 2000 is as much a
bonus to Linux after its delivery as it was during the long delays.
More telling than sales and other market
metrics of size and growth are the Internet "mind share" metrics for
Linux. If we can agree that business will be deeply intertwined with the
Internet, then a measure of the buzz over open source may be useful.
Table Table
1 is a simple and unscientific experiment comparing relative search hits on
AltaVista. Over just 14 months we see every O/S losing percentile market share
except Linux, with some slight gains in other Unix systems once the Linux Fever
began in early 2000. What is abundantly clear is how, among all its peers,
Linux is rapidly gaining the mind share of the Internet. Remember what I said
about good ideas on the FidoNet?
Table 1. Comparative
"hits" for AltaVista based on [JP]
|
Keyword |
Jan 10, 1999 |
Oct 29, 1999 |
Mar 10, 2000 |
|
Windows |
2,530,775 |
6,748,317 |
9,997,800 |
|
Linux |
502,053 |
984,844 |
5,876,340 |
|
Solaris |
251,513 |
453,884 |
586,690 |
|
HP/UX |
105,833 |
180,612 |
214,587 |
|
FreeBSD |
81,781 |
180,547 |
671,895 |
|
MacOS |
70,851 |
133,882 |
161,925 |
|
UnixWare |
23,386 |
32,994 |
85,415 |
|
Ultrix |
15,133 |
26,351 |
38,530 |
|
OpenBSD |
11,892 |
13,354 |
52,960 |
Industrial Time Lags
Figuring aside, mass acceptance of new
technology doesn't just happen out of statistical necessity. Are we closing in
on the days of Linux in 'prime time'? I believe it is inevitable, but before
you rush to buy more shares, I'll add a caveat: For very real reasons which may
even be natural laws, world domination may not happen as soon as we'd like.
Figures like Netcraft's Web Survey tell us that, in certain markets,
Linux and Open Source are already the industry norm, and they hold great
promise for the future, but there is still one more principle to consider: You
cannot rush evolution.
Bucky Fuller, famous inventor of the
geodesic dome, spent a lot of time charting the time lag between invention and
mass acceptance. He discovered fixed lag times specific to each
industry. In electronics, it is 18 months. In the building trades, 30 years.[RBF]
Rather than be discouraged, Bucky concluded
an inventor should build their better mousetrap even if the initial response
is dead silence. If it is truly useful, mass adoption will come, but there
is no way to hasten it; it comes in its own time (I hope Michael Cowpland is
listening!). It is important only to realize that process can not start until
the inventor announces the new invention.
Time-lags in Software Engineering
My own informal observation in our industry
shows we are no where near as fast as the electronics industry. We took 4-5
years to accept CPM, 4-5 years for DOS (just in time for the Mac), 4-5 years
for GNU-C and Emacs, 5 years for Windows 3.1, and it has taken just under 5
years for Windows95 (it was introduced in 94 and was still pretty fringe in
1998).
Linux was introduced as a research tool in
1991. By 1996, Bob Young found Linux commanded a fair mind share of that
market. Bob introduced the packaging of Linux for the server/developer market
in 1996, and he's right on schedule with his IPO. Mandrake scored product of
the Year in 1998 which puts the capture of the desktop market at 2003, and
Corel's bid to capture the office desktop close behind in 2004. It's kinda
spooky how these dates fit both the IDC pundits and Jeff's growth-doubling
algorithm.
There are two lessons here. The first is an
illustration how the "Release early, release often" credo only gives
the illusion of hastening mass adoption by pushing ahead the initial
announcement, and the second is that, for those of us vying to service this
industry, these dates give us our time lines. If we want to know what is
feasibly to have widespread by 2003, we need only look back two years in the
Linux support industry for our clues.
Milestones to World Domination
At the ITAC
"Roadwork" conference in 1994, I was talking with an old-timer about
the soon-to-be ubiquitous Internet. At the time, I thought we would see mass
acceptance of the Internet very quickly, 1996 at the latest, yet I was
continually frustrated by the blank stares I'd get when I offered to put a
business online, or even install free email for them. My colleague gave me an
observation which proved itself then, and which proves itself in every new
technology. He said:
When I was a young boy, no one in their
right mind would own an automobile. To own a car, you had to be part
carriage-maker, part small-motor repairman, part bicycle repairman, and be a
little suicidal. Before we could have a car in every driveway, we had to have a
mechanic in every village, gas stations on every corner; if you car was broken,
either someone could fix it quickly, or they could lend you another.
Open Source consulting is
about that infrastructure. It is about putting a mechanic in every village,
about roadways and driving lessons and all the infrastructure an industry needs
to survive. Eazel could put
the next killer desktop out on the market tomorrow, or Cobalt could release the
killer network appliance, but without the corner shops to sell and service
them, without the books, technical support and guidance in every village, they
won't go anywhere.
Consulting Opportunities
If you have been following the growth of the
LinuxJobs page on
LinuxToday, the Linux
jobs on Monster.ca or just reading your local paper, you'll know the score.
Three years ago, you would be hard pressed to find a job offer listing Linux in
the requirements. Today they are everywhere. Employers now report turning to
Linux because, while they have trouble staffing in other platforms, every new
graduate seems to have at least some experience in Linux; as we shall see when
we look at training, even where a graduate may have some academic experience in
another O/S, Linux people tend to have real-world production experience, and
without ever having had a real job.
All that said, employers still report a
shortage of Linux talent and that means a hayday for those who will work on the
advertised projects. Right now, there is a popular myth of a shortage in
computer talent in general, and in Unix programmers and system administrators.
I believe this situation is misleading as many of the advertised jobs are in
working conditions no one in their right mind would take, and since choosing
Linux is good evidence of sanity, QED.
|
The Mythical IT Shortage Despite all media hype, repeated studies
find no shortage of skilled IT workers[NM],
although there is a huge shortage of Dilbert candidates. What the unfilled IT
jobs stats betray is nothing more than a cultural shift in expectations[CTM].
Even our young are less than willing to relocate to a strange new city on
only a 3 or even a 5 month guarantee. With downsizing, ¾ of all IT projects
being canceled before completion and a growing interest in a quality of life
over the size of a paycheck, the paychecks can grow as high as they like and
the jobs will remain vacant. The experiment to support my theory is
easy: Put a job listing on any site you wish and promise full-time
telecommuting with proper infrastructure and remote worker support. Watch the
lineup form. I have repeated this experiment many times over the past 15
years and have watched others repeat it; the results are remarkably
consistent. IMHO companies who require geographic
proximity betray themselves as ignorant (or afraid) of the very technology
they seek to master, and as such, qualified people stay away. When we
investigate the supposed 300,000 seat shortage of skilled programmers, which
we do as a matter of my own professional and academic interest, we find
interesting patterns. ·
Virtual corporations
and offering full-time telecommuting distributed workgroups find all sorts of
top-notch people within a few hours of a mere Usenet posting ·
Many open positions
are suicide missions. *.jobs newsgroups
seethe with these; sometimes I get angry and rant at them. Due to bad
council, these companies had a Project Manager who locked them into
huge-ticket but highly inappropriate technology, and then bailed for a better
offer (or before it hit the fan. Now the company needs a saviour, or a scapegoat.
·
This is very well
documented: Many ads seek to hire new immigrants and new graduates because
these people will work for less and under worse conditions, and are more
desperate for something to show on their resume. This is also true in other
staff-shortage industries such as collection agents and hairdressers. Let an old-timer
pass some advice to the youth reading this: Don't sell yourself short. You
have knowledge even if all you know is how to use the technology to
find your answers. In an information economy, networking knowledge is
more power than you imagine. Yes, you need a job, we all do, but if you work
yourself to death in an underpaid and exploitive job, don't think for a
moment they will even thank you --- they are more likely to dump you in a
wink the day they have a bad quarter. ·
Some just betray
themselves as thinking too highly of themselves. To be fair to them, we
should remember that Narcissus did not know he was looking at his own
reflection when he fell in love with it. Still, in a network world, it is the
honest pitch that finds the mark (if you will pardon the mixed-message
metaphor borrowed from scam artists): A company who portrays itself as just
people, presented honestly, with all their foibles, is more likely to attract
quality talent than a slick marketing affront painting themselves as the
coolest place thing since Andy Warhol. Employers are being naive:
We need to step out of our cubi-cell and proclaim "Everyone! A
meeting!" for no real reason except to shoot the breeze and talk
straight for the first time in our lives. What's more, we need to let
everyone within our charge also speak just as freely and without fear.
Instead, we see too many management styles who call that meeting only to see
their minions drop their tasks and file in under their command. The good ones
feel like kindergarden teachers, and the bad ones ... Face it. It's time we started treating our
employees like graduate students. |
Nonetheless, pollsters predict Linux use
growing at 25% per year, and all of the Linux vendors I know have experienced
huge growth over both of the past two years and no end in sight. This is
creating a terrific sucking sound in around the Linux talent pool as all the
existing vendors, and all of the new vendors, scramble to find any Linux
experts available. For fun, two years ago, I listed my resume with the DICE
service in the US --- I had no real interest in moving to the USA but thought I
would test it out: I had so many calls it became annoying. To be fair, I have
more experience than most, but on the other hand, most of the callers had read
no more than the first mention of Unix.
And we are only at the beginning. Linux is a
small village on the world market. As a village, there are a few vendors of
each type, and many vendors multitasking diverse product lines. As the village
expands, as the installed base grows, opportunities and diversity can only grow
with it. We have only begun to see the business model for technical support and
value added services in open source software, and as the pressure mounts, more
and more businesses are going to realize that Red Hat gets more applicants in a
day than others can find in a month because Red Hat is treating people like
human beings. Open source just may be a powerful carrot that coaxes information
technology shops out of the cotton gin.
This future is not just rosy
for those with ample experience. There is also much work which can be done
*during* your training. Many Unix sites are large sites with several tiers of
sysadmin positions; many current job postings for unix administrators are for
the lower positions, jobs involving a pager and being ready to attend to
critical applications on shift work, but the level of expertise required may be
no more than you might get out of a book like "Linux Systems
Administration Unleashed". The low cost of Linux and BSD also makes these
attractive to very small sites; for example, small ISPs of less than 100
subscribers or small departmental servers for non-profit orgs, and both may let
you "Learn on the job".
The Consultants' Toolbox
|
|
|
We've established the market share of Linux
system and the market requirements for support. I've hopefully also instilled
some sense of necessity for providing the guidance businesses will need in the
new digital economy and how we are uniquely poised as the gurus, the native
guides of that shift. The question now is how to make this happen.
First and foremost, Open Source consulting
is a business, and it is a service business which must adhere to the same
requirements and practice standards of any service business. Professionalism
and integrity, responsibility and good management are common among all service
workers, but I don't need to tell you that. The sections that follow will cover
some of the best-practices we share with other consulting services, and I hope
you will bear with me while I repeat the obvious, but I also want to cover some
of the aspects which are new in our business, and the new opportunities Open
Source grants us to build a new kind of service industry.
Consulting is a People Business
Surprise, surprise. This integral point in
consulting is mundane, but all-pervasive: Consulting is a people business. Your
clients have needs, you have knowledge (and networking) to make this happen,
but before we can put these together, we need to understand each other. To sell
anyone on risking their hard earned cash to someone they have possibly never
met, and probably have no prior experience, there is a lot of reassuring, a lot
of shaking hands, making presentations, writing letters, emails, phone calls
and visits.
Presentation
Before you buy a suit and enroll in Dale
Carnegie, keep in mind that the best presentation of yourself is to present
yourself as you are and not some constructed image of yourself. As we've
discussed, networked markets are not stupid markets. They know about marketing
and media, and they can see through the masks. They also know about
internetworking, and the new market expects a different face to come out of it,
a human face. A case in point was an online Careers website who caused an
explosion in membership on their "resume and jobsearch" portal by
changing the name from Career Central to Cruel World.
At the '99 LinuxExpo in Raleigh, I spoke to
an old-school MIS person who remarked about the general flavour of Linux
presentations, "Everyone says, 'have fun!' I've never been to a conference
where every talk ended this way." Your clients are not accustomed to this,
but make no mistake, they welcome being granted the right to be human.
The re-humanizing of business through the
open source movement is apparent in our presentation materials. No one wants a
Powerpoint presentation and a slick 4 colour proposal, and if you look around
at the Linux expos, notice how even the staid and conservative stalwarts of big
business go out of their way to dress-down. I don't think they know why,
but we do: A networked market does not trust a slick presentation; it expects
and demands an honest, direct and even blemished communication. It wants a
conversation.
Avoid talking down to clients or speaking
obtusely; they are well-informed and understand their market and their
occupation. If they don't understand what you are saying it is not because you
possess some secret arcane knowledge. It is because you failed to explain
yourself. To say that in our language, the Client-Server model must be a
peer-to-peer model. If I gave you an obtuse and clouded API for RPC, you'd call
it a bad design; business communications is exactly the same.
When to say "No (thank you)"
Turning down contracts is one of the most
difficult tasks for the beginner, and this is no easier in the open source
support world than in any other service industry. Sometimes, you just need to
walk away. Newspaper classifieds abound with help-wanted ads for hairdressers
and collection agents, and software contract offers also tend to overflow with
what I call "suicide missions", jobs you have no hope of completing,
and for which the company needs a scape-goat.
The most sure-fire symptom of a suicide
mission is a call for a system designer, for a top level architectural job,
where the requirements list only constraints, typically a checklist of
inappropriate technologies. Most likely, your predecessor presented an
ill-conceived plan, was granted a budget, purchased a lot of disjoint toys, and
then bailed. Another warning light is stock options in lieu of decent wages;
they may very well be legit, but if it runs sour, you're unlikely to ever see
those stock options (unless your sister is a lawyer). It's not up to you to
finance a new company; we have venture capitalists for this.
As much as you may love Open Source software,
as much as you may want to be among the foot soldiers of the Revolution and aid
in the indoctrination of yet another corporate shop, always be mindful of your
own needs. If you fail to care and fuel the engine, the car stops, and this
does no one any good.
Philosophy 101: Project Planning
In preparing your presentation and your
project plan, my best advice is to appeal to the original methodology guru,
Aristotle. In "The Four Causes", we get an ancient philosopher
outlining precisely what is contained in all the volumes of UML guides, but in a characteristically concise and
elegant plan:
·
Aristotle's first cause
for any action begins with the Formal Cause, the plan of what we intend
to accomplish. In software engineering, this is called the "Requirements
Specification" and lays out the business problem that the software is to
solve. In UML, this is the suite of use-cases.
·
Once we know what we
need to accomplish, the Material Cause follows showing the components we
employ to effect the solution. In UML, this is our
set of data structures and the data sources our program must handle as
illustrated by Class and Object diagrams.
·
Given the ground we
must dig, the Efficient Cause enumerates the methods by which the
components interact; in software engineering, the Material and Efficient causes
are generally lumped into a "Design Specification" but this is
probably why there are so many bad specs that fail to put the data components
first. In UML, the Efficient Cause is our
interaction graphs, collaboration and state diagrams
·
The last cause to form
our plan is aptly called the Final Cause and this is the blueprint for
the goal of our action, the implementation specifications, the component and
deployment diagrams
Together, these four Causes guide a
complete picture of the project, and it is worth noting that none of them
include notions of time lines although each does lead to a modular view of a
project that can be sifted for milestones. You may also want to consider a
fifth cause, proposed by the eccentric particle physicist Jack Scarfatti, that
being the Future Cause, but that is material for another paper.
Groundschool
This isn't the web. You can't simply set
yourself up as an open source consultant because you know how to turn on the
computer and boot LILO to a Linux partition. You can, of course, and no
centralized body is ever going to stop you, but I want to implore you not to
do it if only because we have an opportunity here to do so much more than
simply fix broken shell scripts.
Open Source consulting can be so much more
and all it takes to get there is a bit of attention to the whole picture, to
the gestalt of where what we do fits into the scheme of things. This is going
to require some extra work, but copying what was done in the previous
generation of consulting is not going to get us anywhere.
Clarity
A consultant's success rests as much on the
art of conversation as on the art of good systems design. With Open Source, the
tools and products themselves may not have the best end-user manuals, so a
major part of the job will be mediating for that lack of documentation.
Contrary to a popular belief, obscure coding and bad docs are not job security;
they are an excellent way to squander your reputation for integrity. All we
need is one client left stranded with a system of ours to become cut off that
entire industry for a long, long time. Remember: Markets are networked, and
they talk.
With Open Source, we can afford to talk. We
can be honest and open with our time lines and project plans. A schedule based
on Apache Jakarta knows and accepts that the deliverables in Jakarta are beyond
the control of our PERT chart. If we're really
pressed, we can run with what we have, but for the most part, there is a sense
of human realism in Open Source, a sense that things happen when they happen,
and not a moment before. I believe this is a healthier way to run our projects
Open Source also saves us the rigours of
traditional top-down software design and encourages a more rational and organic
approach; we still need good requirements and systems documents, we still need
to apply foresight to our data structures and tailor our algorithms, and we can
still use UML or reverse engineering to map and plan
our work, but we move in smaller and more flexible "release early, release
often" time-scales. Open source, by being victim to global whims of its
community, carries an inherent sense of scheduling fluidity that includes
adaptability as a basic requirement.
|
|
Requirements vs
Constraints |
|
|
Confusing requirements with project
constraints is a common error in creating project specifications; any design
specified to fit its constraints will be bound to those constraints, and
experience tells us our constraints almost always go away. A corollary rule is that, with a few
exceptions, true requirements are never known completely in advance.
Invariably there is a list of things the program must do, but no guidance on
how it is used. Fred Brooks said, "even the best planning is not so
omniscient as to get it right the first time. Hence plan to throw one away;
you will, anyhow." and I agree: No one knows what they really want until
they see what they don't want. Avoiding wasted time on dead-ends and
inappropriate methods is yet another reason to start the conversation, to
"release early and release often". |
Integrity
To move in a world of clients and contracts,
we need integrity. Integrity is our commodity; we must strive to have only
happy customers, even among those we disappoint. Again, clients are networked,
and they talk.
Integrity is also essential within the Open Source
community. This community is very sensitive to your stature within their ranks,
and, for better or worse, there is an implicit order of reputations gained by
actions. We can no longer simply pay for a college course, get our certificate,
hang up a shingle and lord over our domain. Open Source requires
participation, and demands it. To be effective, to stay current and be
supported in your own work, you need the community. Arriving late at the
party, hanging on to proprietary ways world in deference to open source, these
things can lessen your stature. Many large businesses find themselves in this
awkward position; today they are bending over backwards, at great expense, to
undo that damage.
This does not mean we must pledge here and
now to never boot Windows again (even though that is a very good idea), but it
does mean that the sooner we grasp participatory open source philosophy, the
sooner we can put it into practice, and the better off we'll be when we
discover our entire industrial sector is now an Open Source shop. No one minds
if we keep an MSCE certificate on our office wall,
but your survival depends on understand its limitations.
Learning
|
|
When a man teaches something he does
not know to somebody else who has no aptitude for it, and gives him a
certificate of proficiency, the latter has completed the education of a
gentleman. |
|
|
George Bernard Shaw,
"Man and Superman" |
We've talked people skills and reputation
with the community. There is also, of course, a need to know your stuff. How do
we get all these? Fortunately, in open source, the answer is easy. Those of you
who came to this document to learn the secret of cramming your head full of all
the magic needed to be a top notch Linux hacker-for-hire may be a little
disappointed to find this secret forming such a small part of the whole paper.
Yes, there are courses, there are tutorials,
books, lectures and certifications without number, but these are all
extraneous, maybe even superfluous, all of them relics of an old way of doing
things. You already have every thing you need: You have the source code to
study, real production systems you can tinker with to your hearts content on
even the most modest workstation, and you have tens of thousands of mentors.
Unlike every major technology to precede Open Source, everything technical you
need is given freely; half of it is right there on your Linux CD, and the other
half is online 24 hours a day.
It gets better: The two most essential
components for your toolkit, the people skills which arise from experience and
the integrity that accrues exposure is in the very fabric of Open Source
computing. I have said it many times so far and will likely repeat it
again: Participate!
Open Source University
What other technology invites you to
contribute even if the best you can do is to run the software and report where
it fails? What other technical field abounds with volunteer projects eager to
count you among the core engineering team? Even in the Linux kernel, we know we
have Linus, and we have Alan Cox, but of the other "core developers",
who even knows the number of them let alone being able to list their names? And
this week's list will be different from next week's list.
Participation is as easy as deciding what
interests you, as easy as finding some software that you need, or very
nearly to what you need by, doing a search on FreshMeat or SourceForge, and
jumping right in (being careful, of course, to follow protocol and make an
effort to fit into the community; these are the people skills). Yes, you can
pay $1500 for a 4-day crash course, or you can pay yourself that $1500 to take
two weeks off to sit and dissect, and hopefully fix KVoice
or Mozilla or Kernel SMP
support. How could any college teach you better than first-hand experience
working with top engineers on a real-world project? Linux is the world's
largest post-graduate university with a full-time co-op program, and its free.
Syllabus
You will already know what technical skills
you need: You do what interests you, and keep in mind that confidence comes after
success, never before. The very best training is in pure play, in taking
systems apart, breaking them, fixing them, breaking them again. My first true
lesson in Unix system administration came the day I tried to move my /lib directory to another partition — I quickly
discovered the extreme dependence of all other basic commands on those files,
and also learned how to boot my machine with the install disk, mount the drive,
and fix the problem.
My other favourite training ground was the
break-neck speed of the development kernel; by only updating my software within
hours of a new release, I encountered more hard problems than I might have in
years of academic study, and while I gained the accolade of a "CVS surfer" from colleagues, I learned a broad
repertoire of problems and fixes. 90% of consulting is simply recognizing the
problem and executing the solution.
Intrinsic to all of this, though, was the
network of kind colleagues and patient project members who did not mind 50
repeats of the same question when a kernel release upset some core system tool.
Once again, the tool-box of the open source consultant does not end at their
own desktop, it includes the world.
Chickens and Eggs
In Japanese, the word taiken means
"knowledge gained first-hand from direct hands-on experience". We see
career colleges giving tag-line lip service to how well they simulate hands-on
training, but every employer knows there is no substitute for taiken,
for real experience. A consultant can never have enough.
In the old way of doing things, a new
graduate gets stuck with the koan of "no experience, no work; no work, no
experience". Open Source has solved this problem so perfectly that no one
even thinks about it anymore; top employers like IBM simply raid top open
source projects for participants with the best reputation.
The beauty of this "school" is it
welcomes and accommodates everyone. There are simple shell scripts to fix,
there are intensely technical kernel components to extend and debug, and no one
stands over you to demand that you work on any particular bit or on any
schedule. If you hate debugging but thrive on cutting edge research, there is
room for you. If you like the deduction/reduction game of difficult debugging,
there is room for you. If you have oodles of low-level database experience,
Postgres welcomes you, and if you dig the depths of high-performance computing,
the Trillian Project
would like to meet you. Even if you can barely code the Fibbonacci sequence,
there is room for you. Best of all, we all know that peer-group discussion is a
major component of any education; any distance education that fails to simulate
the hallways and cafeteria as well as the classrooms and lab is doomed, and in
Open Source, there is no end to discussion. There are thousands of mailing
lists, newsgroups, IRC channels, online lectures, and conferences like this
one. Open Source software lives and breathes life-long learning.
Those who came here to learn
about learning enough to become a Linux guru can leave now. I'm done.
Setting up Shop
This section is not so much about Open
Source as it is just about the dull parts of consulting and running your own
shop. For the consultants who were looking to move into open source, this
section is old hat. For those on the other side of the fence, the technicians
and engineers who want to branch out on their own, this part is for you.
If you are like I was when I started, I had
a pretty good head for the technology, and virtually no business sense at all.
Since consulting is a business, it makes sense to learn a bit about the
consulting business itself. From my own experience, I can also say that this
area of my work is still my weakest, in part because I am still torn between
what I think I am supposed do (aping the mainstream consultants) and
what I know I must do to survive in the new economy. We don't want to
make the mistake of following the dinosaurs into the tar pits, but that does
not mean we cannot learn anything from their experience.
Accounting and Incorporation
Most of you probably know more about tax
laws and finance than I do. I'm hopeless with cash and make no apologies. About
all I know about money is that, in my country, most of it vanishes into the
government unless you are very careful. One thing I do know, from bitter
experience: Don't wait until you are saddles with a $25k tax bill to
incorporate. It is simple, cheap to do, and saves a lot of heartache later.
Take some advice from an old-timer: Find yourself a corporation lawyer, at
least one partner, and incorporate.
|
|
Naming your business |
|
|
While you are at it, you'll be asked to
name your new corporation. I implore you, do not do as I did; follow the lead
of Marc Ewing or Jeff Bezos and choose a name which has nothing whatsoever to
do with either your business or with Linux, GNU or any specific item or
service. Corporations (hopefully) live a long, long time and you stand a
better chance of brand recognition with a neutral name than with one tied to
the wrong industry |
Somehow related to all this tax stuff is
accounting. The short advice is "Just do it" and even better advice
is "Marry someone who will do it for you", which is what I did.
Unlike a vendor who has tangible inventory and real flows of boxes in and out
of the shop, the consultant must be very careful to document their activities or
face the wrath of the tax man. Drive to the mall to pick up a parcel? Log it.
Donate time on a local community project? Log it. Track your time, even the
time you spend administering your own desktop, and track it as finely as you
can; if you hated doing this when you were working for someone else, you will
hate it just as much doing it for yourself, but at least you will understand
why your employer was so adamant about it.
|
|
Linux Accounting
Software |
|
|
Not to sell anything, and by the time
you're done here there will probably be alternatives, but for most
consultants' needs, open source programs such as the Starnix's BANAL will help you avoid keeping a
"ghetto" Windows box just to run accounting software. GNUCash is not there yet,
but is one to watch, and if you are not adverse to paying for software, there
are several good packages; Proven
Choice Dk is cheap, quite usable, and even handles Canadian tax and GST. |
Consulting Rates
|
|
What I need is a job that doesn't
interfere with my work. |
We all want to work on open source and it
sure would be a bonus to be paid for it, but the software engineer is already
one of the most exploited occupations. It does no one any good perpetuate this
by selling yourself short. Under-cutting other consultants by gross amounts
only makes us all look bad, and operating at a loss is not very good for
business. Our costs in open source support are significantly less than
for our proprietary-bound colleagues. We have no license costs, minimal
training fees, significantly lower hardware and infrastructure costs, and, if
you are well networked and respected in the Open Source community, you gain
hefty labour and knowledge amplification benefits. The exact rates you charge
depend on your local market, the industry you serve and your own expenses, and
lets face it, your rates will also depend on whether or not you like the work;
my best advice is to be reasonable, but be flexible. Factor your experience and
your reputation, and price accordingly.
An important consideration is your downtime
and in-house costs: If you estimate you can support your family on $40/hr, keep
in mind that you will only score a fully paid 40hr week during the peak of a
contract; you need to factor in down time, retraining costs (which includes subsidizing
your other work on open source projects), the time you spend in research, in
systems administration of your shop, and especially your time between
contracts. Depending on your industrial sector and your geography, you may see
as much as 30% of your time is revenue neutral; with just this consideration,
that $40 has jumped to $60.
My only rule of thumb in pricing your
services is to avoid fixed price quotes unless you have unequivocal
project specifications; even if you do see such specifications, suspect them as
being pure fantasy. We point to Linux as the epitome of a large project written
in a reactive (rather than pro-active) mode, as something adapted and extended
incrementally and only to meet the demands of the next set of engineering problems,
but in truth all software is written like this. To think otherwise is
wishful thinking backed up by smoke and mirrors. I have been consulting for two
decades, and I have seen an exact specification only once (at Mitel
Semiconductors). Give estimates, place caps, but avoid hard promises. Push for
subscription pricing rather than piece work.
Subscription services are not always
possible, especially with government funded projects, Canada Council grants and
other fixed-expense advance payments, but even where an ongoing hourly rates is
acceptable, it should also not give you carte blanche with your clients'
money. Be realistic and be honest. You may think you can do it in X days or weeks, but unless you have been keeping
excellent logs and have done the identical task many times, you really don't
know. Far better to break your contract into milestones with deliverables, and
give checkpoints along the way; the main reason for the mythic requirements
specifications and and project schedules is not to know when you are done so
much as to know how far you are from completion.
Project Estimates
Of all the components in consulting, the one
I find most difficult is cost estimates. For the newcomer, it is practically
impossible to consider all the factors, and all too easy to underestimate the
costs of simple things like a comma where a colon should go, or a single equals
where it should have been double. Project notebooks can provide clues to your
own patterns of costs in design, development and maintenance, but in this
business, these are most often just that, clues.
All of our work since 1983 has been things
never done before, most often never done by anyone, at the very least, never
done before by me. Prior project notes are useful for many things, but of
limited use in estimating. Sometimes I envy people whose trade allows them to
repeat the same hit single over and over. Still, however fluid the technology
may be, there are some rules of thumb which are slightly more scientific than
Hofstaedter's Law ("It always takes longer than you expect, even if you
consider Hofstaedter's Law")
|
|
Here's a professional tip for project
estimates: I have been using the "Fahrenheit/Celsius Rule" for 19
years and while my clients often don't like the figures, the method has not
yet failed me. Take your best estimate. Double it. Take away 10% and add 32.
Don't laugh. It works. Trust me. |
Seriously, though, as a consultant, it is up
to you to explain the reality to your clients. If there is pure research
involved, separate it from the estimate and put a star beside it. Be honest and
up front. If you can't estimate the time to completion, give some ranges, but
mostly just chart out those dates you can deliver; one of those dates can even
be the date of the more accurate estimate. Your clients will have finite
resources and need to know when cost overruns are no longer worth the expense;
since that is the purpose, if you also keep to that purpose, you are both
working to the same goal.
Contracts and Boilerplates
The short answer on boilerplate contracts is "Forget it." That said, though, t