Open Source Consulting

Applications Support

Under the banner of Linux, this is a burgeoning field. No surprises here, one basically takes what one knows about some specific component of a program and applies that knowledge for the benefit of the client. The most common example is supporting the Apache webserver, or the Perl/PHP contracting.

There is very little difference between this work and consulting work with proprietary software such as SAP or Microsoft products. You make a pitch, agree on a price, build a solution, shake hands, cash the cheque, and move on. This is honourable work, but take my advice: It is not profitable in the long run. Highly recommended to put yourself through college (or buy that Gibson guitar) but not something to fund your retirement.

On the positive side, the entry barrier for this line of work is absurdly low: You can run the same software on very modest hardware to simulate and develop, then seamlessly migrate to your client's platform. You can also usually adapt knowledge gained from other platforms, for example, there is a growing demand for database expertise in Linux circles and this is a popular niche for down-sized older programmers looking to ply their trade in this new industry. All the resources to learn and to deploy these projects are also freely available, and most often authors or other contributors and users of those tools will freely assist you, all in the cause of the Revolution.

This line of work is ideal for the beginner; it requires a basic level of skill and experience, but this background is not hard to acquire through volunteer projects, and since your contractors may not understand the Internet information economy, you can go very far flying by the seat of your pants, going home each night to sit on IRC to solve your previous day's business problems; you can easily appear to be far more of an expert than you actually are. Trust me on this.

Open Source Systems Integration

Integration, and with it systems and network administration, is the subject of 99% of all the so-called "Training and Certificate" programs. Again, no surprises, you all know what it means: You provide the glue that holds many Open Source products together in consort. The job is similar to single-product technical support, except the scope of the knowledge and experience required is larger, as is the scope of your Open Source community involvement. A systems integrator, whether installing and maintaining servers or amassing open source pieces into new network appliances or a new Linux distribution, is exponentially more muddled in the Small Details, but essentially involved in the same learning the materials, suiting solutions to a task, careful debugging, eyes on the road, hands on the wheel, and moving on after the final cheque and the handshake.

I include Linux and other free O/S "distributions" under this heading. A Linux distro is, at its core, an integration of open source (and sometimes hybrid) software. It involves quality control, smoothing out the rough edges, sometimes some special glue, but once done, once it is beyond it's lifespan, the romance is over.

Network appliances are also integrations. Appliances are specialized distributions set into small, special purpose machines; basically, an in-house distribution duplicated into the hardware before the unit is sold, usually for use as a firewall, gateway, mail server, print server, network monitor, & c. Since Linux will run on everything from old donated 486 hardware, low cost rackmounts to clusters of high-powered VA and IBM machines, vendors are eager to partner with anyone who can help them sell boxes through an appliance application.

Appliances are another opportunity for older programmers. By integrating Linux with seasoned expertise in business software, special purpose database appliances such as accounting machines, inventory control and especially in integrating these into ebusiness applications may find a ready market.

I won't question there is money to be made in specific applications support and in the more general systems integration, but I don't believe you can make it to retirement doing this. These are hand-to-mouth occupations, lucrative while they are happening, but volatile and without residual benefits. For the open source consultant, the money is not in tinkering code but in tinkering with business itself. Business is changing, and those in the internetworked open source community probably have the best grasp of the survival skills all businesses will need.

Participatory Open Source

Up to now, the service models I've outlined are almost identical to their proprietary counterparts. There is a major difference, though: Open source has built in longevity. Simply integrating and supporting specific systems is a passive role. When the market changes, and if your technology is something like the FidoNet, you can find yourself suddenly stranded. Retraining and re-tooling becomes a way of life, a long series of seminars and retreats. Most closed-source consultants and businesses using closed source systems with consider this "the cost of doing business".

Open source is not so passive. Consultants can actively counter obsolescence through participation, learning about and helping to form the changes in the technology as it incrementally evolves to better suit changing markets. Everyone I know who is supporting open source doesn't even think about this, they just follow the newsgroups or mailing lists, follow the revisions and patches, and seem to be on top of their niche. Unfortunately, unless they teach their clients to do this, they may have failed. This is the third evolutionary step in Open Source Consulting: Participating ourselves and leading our clients in to participate in the software they are using.

Unless there is participation, a company may have their solution today, but may be left with yesterday's technology; the tiniest shift in the information ecology could knock them flat. They miss out on the meaning of the Revolution, and it is more your fault than theirs because you knew better.

For our clients, participating in Open Source shifts them from being a consumer of technology to being a source. We see the famous open source support companies such as RedHat and VALinux using this approach: The open source people they hire to do develop their products is folded back into the open source community. They can obtain the innovations they need for their own products, and, in the process, gain inside information about the future of those systems, they can stay agile and anticipate changes, and most importantly, by "giving back", they ensure support from the community.

For the consultant, participating in Open Source is how we network. It is so normal, it is almost invisible. By contributing, we are always learning new skills, and investing in our education and our reputation. Participation is better than an RRSP for ensuring our future. For these same reasons, it is essential we relay this to our clients.

We won't convince every client. Our clients will shy away from active participation. They can see open source as a free ride and counter with "We have no time. Our application is our competitive edge. We cannot spare the resources."

The excuses cost more than participation. Fortunately, with every new Fortune 500 announcing its participation in projects such as Linux and Apache, the case for involvement is easier to pitch. When IBM, Motorola and Cognos can boldly proclaim they play the open source game, our clients can at least entertain the notion they can play too.

Proselytization (P13n)

"Is he suggesting I convince my financial securities client turn their on-line trading systems Open Source?" You probably already think I am quite mad. You are right, of course. You're mad too, otherwise you would not have come here, but that is all milk spilled under the bridge now. The important and critical point, is that, whether or not your clients will play the game today, they will tomorrow, and since you are only now reading about how to become an Open Source consultant, you can't possibly be set up and ready for business before sunrise. QED.

The benefits of turning core systems and applications into open source projects is staggering. It is more than staggering. It is probably inevitable: If they don't do it, a competitor will and they will be left in second place. In an economy of community, knowledge is not power, knowledge is water. The community is the power. Without trade, knowledge sours and perverts, it makes silly mistakes, and costs astronomical sums to prop up the illusion that all is well. Knowledge Management is a myth, at best it means "Learning to Talk". With all it's resources, Microsoft could not build a bug-free Windows after 9 tries; how could anyone presume to do better? With all it's impossible mass and tangle of "disorganization", Linux is the De facto alternative O/S, and it grows exponentially in strength and scope with every new release. Why? Because it understands social networking, it knows how to talk and does so on a global scale.

Open Source per se is no guarantee of superior software quality — a simple browse through FreshMeat will attest to this — but it is also true that Open Source can do no worse than a closed-shop "cathedral" approach. The worst that can happen is no one else is interested in your software, or no one can improve upon your genius. The gains when the software strikes a common chord, however, are significant; if your client has, at their heart, a need to provide some service, to fill some market need, no one can question that their best business plan is to do so as efficiently as possible.

It's important here to make a design distinction between what software does and how it works, or between its engine and its implementation. Every newspaper website may need software to parse the broadcast news feed into a database, but every one of them will have a unique way to mine that data into a webpage. The obvious common engine, and the most critical component, is ensuring the data is received and correctly cross referenced into the database. This is a good candidate for an open source component. How that data is mined and rendered into webpages depends on the style and audience of each paper; at best the means of fetching data and inserting it into a page should be open source (this is essentially what PHP does), but the final pages themselves are totally unique.

Another example might be an accounting package. There is a clear difference between the components that take numbers, add them, store them and move them about the system, and this is a good candidate for an open source project (GNUCash is working on this) especially if individual financial services companies can take this basic engine and create new and innovative accounting systems using their expertise in accounting as their competitive edge rather than attempting to be the world's best numerical processing expert.

A real world example is the embedded-Linux consortium. Their member list includes top tier companies such as Motorola and IBM mixed with tiny startups; most members had invested significant resources developing their own proprietary embedded operating systems, yet here they are, dumping their own work, lowering their defenses (or inhibitions) about each other, and working together to adapt Linux to their own cause. Another is IBM virtually abandoning both AIX and Monteray64 because they cannot compete with the world. Even Big Blue, who might have a case for marketing their own O/S to recoup development costs, even they have eschewed re-inventing the wheel. They choose instead to co-operate and unify rather than to hoard and divide, and they position themselves to enjoy the benefits of an economy of a community.