open source consultancy

One of my guilty pleasures is reading the Joel on Software forums. In general, the participants are pretty bright, and they tend to have a decently broad technical background (web 2.0 experts mingle with low-level asm/C guys like me).

There was an interesting thread titled Pushing open source, where the guy thinks about pushing more open source in his consultancy business.

I haven’t written anything substantial in a while (in any form, whether email, code, blog, or misc stuffas), so I ripped out an off-the-cuff ~1000 word reply. I figured I might as well rip myself off and repost it here for my loyal readers (har har har, all 2 of you that might make it through this nerd paean).

Anyhow, enjoy (or skip). [Also, note that I botched the joke in the postscript; real induction says that if n=1 is true and the n+1 case is true, then n is true; oh well, it's been too long since I took maths.]

To the OP:

Your first post intrigued me, and I thought that you had found a nice niche to play in. I think your initial instinct to approach the problem from a TCO point of view was correct, but it looks like you learned that evaluating TCO is trickier than it looks.

The key thing to keep in mind is that your clients want to run a _business_ and don’t care at all what the enabling technology might be.

So if you can _seamlessly_ drop in a FOSS solution to replace a more expensive MSFT solution, you’re set. If your client experiences _any_ transactional cost in having to learn something new, or get annoyed by some new interop problems, game over, you’ve lost. Well, technically, _you_ haven’t lost, but at least you’ve given FOSS a black eye of sorts and helped contribute to the FUD that FOSS is inferior software.

[As someone who is paid to work on FOSS software (linux kernel engineer), I'd prefer not to see this happen ;) ]

Anyhow, if you accept my premise that 100% seamless transition at lower financial cost to the client is your goal, then your best bet is to find a standardized part of the stack and replace just that bit.

The easiest example that comes to mind is a mail server. If your client is currently running Exchange (for mail only, I’ll get back to this in a sec), then you have a pretty good chance at being able to drop in a Postfix install without anyone noticing. The hardware requirements are likely lower, and certainly the software license can’t be beat.

Unfortunately, if your client wants the shared calendar feature of Exchange, you’re hosed. There is no good FOSS replacement (especially one that Outlook can work well with); you’ve introduced some “switching pain” and game over.

Another possible replacement might be replacing an Active Directory server and/or file server with a samba server. Or maybe ripping out their costly firewall and dropping in pf or the like.

Because of the “switching pain” I talked about earlier, Postgres/MySQL probably aren’t 100% drop-in replacements for MS SQL server due to slightly different SQL syntaxes. The last thing you want to do is piss off your client’s developers who will only see your change as a hindrance to their productivity.

I would describe the tactic above as “phase 1″, where your client is completely “normal” and just wants the cheapest solution. Phase 1 allows you to swap out expensive parts with cheap parts that are as good (or better ;) without anyone noticing.

What you do with Phase 1 will depend on your long term goals. You could use it as a competitive advantage over the other consultants in the area, and make cheaper bids on jobs. Or, you could keep your bid the same, and simply pocket the difference as profit. [NB, I don't really see that as an unethical move; you are selling a client a total solution, not a bunch of individual parts, but that is a discussion for a separate thread.]

Now, if you are ambitious, the part that’s interesting to me is implementing Phase N.

In this step, you’re allowed to impose a “switching pain”, with the goal of an eventual lower TCO. Again, it’s a selective replacement of parts of the solution with FOSS bits that are likely to work well. Postgres/MySQL are likely candidates here, since SQL is close enough to a standard that switching away _from_ MS SQL Server is probably doable. Another potential _might_ be Zimbra to implement a shared calendaring solution, but I’m just a kernel guy who knows enough about userspace to be dangerous, so take that last one with a boulder of salt. ;)

Of course, Phase N will require a progressive client who is willing to experiment a little and take risks with the end goal of lower TCO. And don’t fool yourself, there _will_ be risks if they go down this route. Their SQL might be impossible to port or a million other little gotchas.

I imagine if you have a client with whom you could successfully implement Phase N, they might be experimental enough to try Phase N+1, where you escape out of the server room and onto the desktop. Of course, Phase N+1 has nuances — maybe you deploy the Windows version of OpenOffice.org before replacing their entire desktop with Ubuntu, but you get the point.

You mentioned that you’re not totally familiar with the FOSS stack, so I guess that implementing the strategy I outline above might be hard at first. But getting over the steepish learning curve is worth it.

This is especially true because I haven’t yet mentioned the best part for you: once you become _good_ at deploying and managing those FOSS solutions, you’ll find that mastering their complexity truly results in more power for you. In general, the FOSS apps tend to be scriptable, extensible, and automate-able (a neologism I just made up). Moreso than typical MSFT apps. [Note, I said "in general", there are probably counter-examples of course, but in the large, I believe I'm correct.]

So _your_ TCC (total cost of consultancy) drops, giving you a lot more flexibility over your topline. You can choose to pass those cost savings on or keep topline revenue constant, in which case I just described the fabled “Step 2: ???”, and you get to celebrate Step 3: Profit!1!

Anyhow, that’s what I managed to think of in-between bites of dinner. There are probably some holes, but overall, I think the strategy is sound.

Hope this helps.

-Alex

ps, if you were paying attention, you’ll notice that if you ever _do_ manage to successfully implement Phase N+1, then you will have proven via induction that FOSS can take over the world. ;) cheers!