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 [email protected]

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 [email protected] (mailto:[email protected]); it may not be exactly what you need to know, but it is willing to change.

1

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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 Consulting HOWTO

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.

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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 Consulting HOWTO

•

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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

The Consulting HOWTO

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