Why the change of heart? My intention was never to make a fortune with the report, my main priority was covering my costs and time spent. And after 24 hours, I’ve achieved that. I have had several press requests for the full report, and requests from clients to be allowed to use the report both with press and with their clients.

This solution is the best for all involved, I think – I have covered my costs, the community (and everyone else) gets their hands on the report with analysis as soon as possible, and my clients are happy to have the report available under a license which allows them to use it freely.

You can download the full report now for free.

By looking at the modules in the GNOME 2.30 release, made last March, we aim to answer many of those questions, and give deeper insight into the motivations of participants in the project.

GNOME activity over time, horizontal bars are release dates

Here are our key findings:

• GNOME has a rhythm – there is a measurable increase in activity before release time, and after the annual GNOME conference GUADEC
• While over 70% of GNOME developers identify themselves as volunteers, over 70% of the commits to the GNOME releases are made by paid contributors
  

  GNOME committer self-identification - volunteer/professional

• Red Hat are the biggest contributor to the GNOME project and its core dependencies. Red Hat employees have made almost 17% of all commits we measured, and 11 of the top 20 GNOME committers of all time are current or past Red Hat employees. Novell and Collabora are also on the podium.
• A number of top company contributors are consultancy/services companies specialising in the GNOME platform – Collabora, CodeThink, Openismus, Lanedo and Fluendo are in the top 20 companies. As many of these companies grew initially through work on Maemo, this is a sign of the success of Nokia’s strategy around the GNOME stack.

One of the interesting things that we have done for the census is to look at who is maintaining modules by looking at commits over the past two years, and use this data to identify areas of the platform which see lots of collaboration, areas where the maintenance burden is left to volunteers, and areas where individual companies assume most of the maintenance burden.

There are a number of modules in the platform which see a considerable amount of co-opetition, including Evolution, Evolution Data Server, DBus and GStreamer. Most modules in the platform, however, are either maintained to a large extent by volunteer developers, or see the vast majority of their contributions from one company.

I see this information being useful for companies interested in using the GNOME platform for their products, companies seeking custom application development, potential large-scale customers of desktop Linux or customers buying high-level support who want to know who employs more module maintainers or committers to the project.

The GNOME maintenance map, with modules coloured according to the company maintaining them

Update: The release has now been published under a Creative Commons licence on October 1st 2010.

GNOME activity over time, horizontal bars are release dates

But that ship has long since sailed. No company has every described themselves as “an Open Core company” to anyone except VCs, as shorthand for their business model. In the software business, Open Core has no-one defending it, and it has no brand value. In fact, in free software circles, Open Core has been a pejorative phrase almost since it was coined – fauxpen source, popularised by Tarus Balog, cites Open Core as a synonym, and pretty much every mention of it which I have found has not been by a vendor referring to themselves, but by an analyst or commentator referring to a class of business models.

In one sense, that’s what is amusing about this – the valuable brand, Open Source, is the one everyone uses,  and vendors who sell Open Core products find themselves in the unenviable position of having to defend calling themselves “an Open Source company” to what they doubtless consider zealots, but there is no other brand they can use which gives the same marketing benefits while providing sufficient differentiation with Open Source.

I don’t consider the OSI or other people decrying this use of the Open Source brand as zealots, they are simply protecting their brand against dilution.

Matt argues that Open Core products don’t deliberately cripple their free software offering (at least, the good ones don’t), they merely “sell value-added features that are designed to be of value to paying customers”. I would argue that is simply a restatement. Regardless, I accept that there are some features which a proportion of the user base will be prepared to pay for, and which most of the rest of the user base won’t care about. If you can ensure that the proportion of your user base which cares about the feature but is not prepared to pay for it is small, then you have the potential for license revenues without damaging your reputation too much.

As you increase the number of features which users need to pay for, however, you will find that the number of people who care about at least one commercial feature who are not prepared to pay for it will become significant. You only have to look at the SugarForge (a nice initiative in community enablement, by the way) to see that the lack of reporting and sales forecasting in SugarCRM’s community edition is something which a lot of people are interested in – the most active & popular community projects are related to those features. Does the decision to omit those features from the core product represent hobbling? Does the presence of modules that implement those features in the Forge show the victory of the Open Source way? Both, perhaps?

SugarCRM is far from the worst Open Core vendor in this space, so I don’t want it to come across as though I’m picking on them. OpenBravo also does a good job of enabling its community to fend for itself. Others don’t fare so well, and in private will admit that their community edition is “not suitable for production environments”. While this may just be a sales tactic to get people to pay for support, the message that this sends to potential customers is “Open Source might be OK to test out & play around with, but when you want to get serious you’d better pony up or you might have trouble”. Not exactly inspiring confidence in the Open Source way there…

Open core, Open core,  more Open core… the debate goes on and on, with Monty the latest to weigh in.

When you get down to it this is a fight over branding – which is why the issue is so important to the OSI folks (who are all about the brand). I don’t actually care that much how SugarCRM, Jahia, Alfresco et al make the software they sell to their customers. As a customer I’m asking a whole different set of questions to “is this product open source?” I want to know how good the service and support is, how good the product is, and above all, does it solve the problem I have at a price point I’m comfortable with. The license doesn’t enter into consideration.

So if that’s the case (and I believe it is), why the fighting? Because of the Open Source brand, and all the warm-and-fuzzies that procures. “Open solutions” are the flavour of the decade, and as a small ISV building a global brand, being known as Open Source is a positive marketing attribute. The only problem is that the warm-and-fuzzies implied by Open source – freedom to change supplier or improve the software, freedom to try the software before purchasing, the existence of a diverse community of people with knowledge, skills and willingness to help a user in difficulty – don’t exist in the Open Core world. The problem is that for the most part, the Open Core which you can obtain under the OSI-approved license is not that useful.

Yesterday on Twitter, I said “Open Core is annoying because the “open core” bit is pretty much useless. It doesn’t do exactly what it says on the tin.”

Now, I wasn’t expecting that to be particularly controversial, but I got some push-back on this. Dan Fabulich replied “Ridiculous. Like the free version of MySQL is useless?” Which leads me to think of Inigo Montoya on the top of the Cliffs on MoherInsanity turning to Vizzini and saying “You keep using that word. I do not think it means what you think it means.”

With all this talk of Open Core, clearly some confusion has crept in. Perhaps it’s on my part. So allow me to elaborate what I understand by “Open Core”.

First, companies can’t be Open Core. Products are Open Core. So whereas Monty considers that from 2006 on, MySQL was not an “Open Source company”, I would contend that MySQL Server has always been, and continues to be, Free Software, and an Open Source product. That is, not Open Core.

Open Core for me means you provide a free software product, improve it, and don’t release the improvements under the free software license. In my mind, Mac OS X is not “Open Core” just because it’s based on the NetBSD kernel, it is proprietary software.

Perhaps it would be useful to give some examples of what is Open Core:

• Jahia is Open Core – significant features and stabilisation work are present in the Enterprise Edition are not available at all in the Community Edition
• SugarCRM is obviously Open Core. Key features related to reporting, workflow, administration and more are only present in the commercial editions
• JasperSoft BI Suite is Open Core. Lots of useful features are only available to people buying the product.

The key here is that support contracts and extra features are only available if you also pay licensing fees. To take the oft-cited example of InnoDB hot back-up tool for MySQL, you can purchase this and use it with the GPL licensed MySQL Server – supporting my claim that MySQL is not Open Core.

This is why I say that Open Core products “don’t do exactly what it says on the tin” – the features you see advertised on the project’s website are not available to you along with software freedom.

I have talked to companies who deliberately avoid adding “spit & polish” to the community edition to encourage people to trade up for things like better documentation, attractive templates and easy installation – and don’t provide an easy way for the community edition users to share their own work. Other products have an open source engine that doesn’t do much except sit there, and all useful functionality is available as paid modules. Yes, a persistent, skilled, patient developer can take the Open Source version of the product and make it do something useful. For the most part, however, if you want to actually use the software without becoming an expert in its internals, you’ll need some of the commercial upgrades.

There is another name for this which is even more pejorative, Crippleware. Deliberately hobbled software. And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretense that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom. It’s disingenuous, and it is indeed brand dilution.

That said, let me repeat – I have no problem with companies doing this. I have no problem with them advertising their GPL-licensed stuff as Open Source. I would just like to see more of these companies providing a little bit of independence and autonomy to their user community. But then, that’s potentially not in their long-term interest – even if it is difficult to imagine a situation where the community-maintained version outstrips the “Enterprise” edition in features and stability.

Who knew that educating people in simple sabotage (defined as sabotage not requiring in-depth training or materials) could have so much in common with communicating free software values? I read the OSS Simple Sabotage Field Manual (pdf) which has been doing the rounds of management and security blogs recently, and one article on “motivating saboteurs” caught my eye enough to share:

Personal Motives

• The ordinary citizen very probably has no immediate personal motive for committing simple sabotage. Instead, he must be made to anticipate indirect personal gain, such as might come with enemy evacuation or destruction of the ruling gov­ernment group. Gains should be stated as specifically as possible for the area addressed: simple sabotage will hasten the day when Commissioner X and his deputies Y and Z will be thrown out, when particu­larly obnoxious decrees and restrictions will be abolished, when food will arrive, and so on. Abstract verbalizations about personal liberty, freedom of the press, and so on, will not be convincing in most parts of the world. In many areas they will not even be comprehensible.
• Since the effect of his own acts is limited, the saboteur may become discouraged unless he feels that he is a member of a large, though unseen, group of saboteurs operating against the enemy or the government of his own country and elsewhere. This can be conveyed indirectly: suggestions which he reads and hears can include observations that a particular technique has been successful in this or that district. Even if the technique is not applicable to his surroundings, another’s success will encourage him to attempt similar acts. It also can be conveyed directly: statements praising the effectiveness of simple sabotage can be contrived which will be pub­lished by white radio, freedom stations, and the sub­versive press. Estimates of the proportion of the population engaged in sabotage can be disseminated. Instances of successful sabotage already are being broadcast by white radio and freedom stations, and this should be continued and expanded where com­patible with security.
• More important than (a) or (b) would be to create a situation in which the citizen-saboteur acquires a sense of responsibility and begins to educate others in simple sabotage.

Now doesn’t that sound familiar? Trying to convince people that free software is good for them because of the freedom doesn’t work directly – you need to tie the values of that freedom to something which is useful to them on a personal level.

“You get security fixes better because people can read the code”, “You have a wide range of support options for Linux because it’s free software and anyone can understand it”, “Sun may have been bought by Oracle, but you can continue to use the same products because anyone can modify the code, so others have taken up the maintenance, support and development burden”, and so on.

Providing (custom tailored) concrete benefits, which comes from freedom is the way to motivate people to value that freedom.

In addition, the point on motivation struck a cord – you need to make people feel like they belong, that their work means something, that they’re not alone and their effort counts, or they will become discouraged. A major job in any project is to make everyone feel like they’re driving towards a goal they have personally bought into.

Finally, you will only have succeeded when you have sufficiently empowered a saboteur to the point where they become an advocate themselves, and start training others in the fine arts – and this is a major challenge for free software projects too, where we often see people with willingness to do stuff, and have some difficulty getting them to the point where they have assimilated the project culture and are recruiting and empowering new contributors.

For those who haven’t read it yet, the document is well worth a look, especially the section on “General Interference with Organisations and Production”, which reads like a litany of common anti-patterns present in most large organisations; and if you never knew how to start a fire in a warehouse using a slow fuse made out of rope and grease, here’s your chance to find out.

Fernando Herrera, Claudio Saavedra, Alberto Garcia and myself will be running the two-day course, covering the basics of a Linux development environment and developer tools, the GNOME stack, including freedesktop.org components, and the social aspects of working with a free software project, being a good community citizen, getting your code upstream, and gaining influence in projects you work with.

The developer tools section will go beyond getting you compiling the software to also present mobile development environments, and the tools you can use to profile your apps, or diagnose I/O or memory issues, dealing with the vast majority of performance issues developers encounter.

This is the first time I have seen a training course which treats the soft science of working with free software communities, and given the number of times that people working in companies have told me that they need help in this area, I believe that this is satisfying a real need.

We are keeping the numbers down to ensure that the highest quality training & individual attention is provided – only 20 places are available. The pricing for the training course is very competitive for this type of course – €1500 per person, including training, meals and printed training materials, and a professional registration to GUADEC, worth €250.

If you register before June 15th, you can even get an additional discount – the early bird registration price is only €1200 per person.

I’m really excited about this, and I hope others will be too. This is the first time that we will have done training like this in conjunction with GUADEC, and I really hope that this will bring some new developers to the conference for the week, as well as being a valuable addition to the GUADEC event.

To prepare for the meeting, I had a quick look at the project, and while what follows is not a complete analysis, it certainly reaised some red flags and some gold stars about the project.

Background:

SalomeTMF was a project created by France Telecom, and it’s hosted on ObjectWeb, as part of the OW2 consortium. It is a modular test management framework written in Java, with plug-ins for various testing and bug tracking tools like JUnit, Bugzilla, Mantis, Beanshell and more. After a healthy start to the project, with a great many incremental releases over a period of years, releases appeared to have stopped in 2007, and the original developers and maintainers appear to have become dormant.

Analysis:

Currently the project appears lacking an active maintainer, but has many users and several developers. Its user forums are quite active, and a call for new maintainers (made by a disgruntled user) shows that there are a number of people interested in ensuring that the website, wiki and software get regular updates and releases. The best placed candidate for new maintainer is a developer who made a new release of the software in September 09.

There is one email from the historical maintainer which raises a red flag for me: he says “it has been a long time since we’ve actively maintained the project, but rest assured that it has not been abandoned… We are working with partners and users of Salome to ensure future maintenance and development of the project. I will keep you posted.” This sounds to me like the old maintainers are not quite ready to completely hand over control of releases and maintenance of the website to those who are working off the OW2 forge.

In this situation, project take-overs should generally be placid. If there is a possibility of conflict, the historical maintainers will retain the benefit of thedoubt until proven wrong, in which case many more months may pass. The alternative is an aggressive take-over where someone proposes themselves as (perhaps interim) maintainer, and makes releases, reviews patches and updates the website.

The bug database shows that there are not many bugs getting closed at the moment, suggesting that the user community is waiting for someone else to do the project maintenance.

I would have liked to analyse the source repository also, but I could only find a CVS repository in the ObjectWeb forge, which versions files rather than the repository. Most of the files I found have not been modified for 2 years or more. This is not necessarily conclusive evidence that the project is inactive – it is possible that other files I didn’t look at have been heavily modified, or that development has moved to another SCM.

Summary:

The project presents considerable risks -  no active maintainers, and a community which appears to be finding its way to the point where all of the keys to the house are available to a new maintainer. The documentation for the product architecture is good, as is thedocumentation for writing new plug-ins, but there is next to no documentation of the community governance structure, and the various community resources, who has access to them, and how one gains access.

Three options exist for a company interested in using the tool in the medium to long term:

1. Consumer – use the product as it is, do some basic work-arounds and bug fixes to get it working for you, and no more
2. Passive fork – develop the product to have features and functionality which you are interested in, and send patches back to the user forum & patch tracker. Have design discussions in public on the user forum. However, do not assume or try to assume control of the project.
3. Aggressive take-over – Ask the original maintainers to hand over access to all project resources to a community member – perhaps a developer in your team – and if this does not happen in good time, take your case to ObjectWeb administrators. If that fails, fork.

An aggressive take-over has the potential to be counter-productive, and expensive, and is as such not to be favoured. Perhaps encouraging the most prominent active community member to become an active maintainer is the best way to achieve the same end.

Which alternative is best will depend on the choices available. Alternatives to using SalomeTMF might be sourcing an equivalent commercial tool, or developing an alternative internally.

If the alternative is sourcing another application, then a cost-benefit analysis of choosing the commercial solution over modifying Salome is required. If SalomeTMF is close to meeting your needs, a passive fork is an attractive choice.

While this is true, it is also not the whole story. Trying to build a rock-solid software platform on shifting sands is not easy. Many projects do not commit to regular stable releases of their software. In the not too distant past, the video codecs produced by the MPlayer project, universally shipped in Linux distributions, had never had a stable or unstable release. The GIMP went from version 1.2.0 in December 1999 to 2.0.0 in March 2004 in unstable mode, with only bug-fix releases on the 1.2 series.

In these circumstances, getting both the stability your customers need, and the latest & greatest features, is not easy. Time-based releases, pioneered by the GNOME project in 2001, and now almost universally followed by major free software projects, mitigate this. They give you periodic sync points where you can get software which meets a certain standard of feature stability and robustness. But no software release is bug-free, and this is true for both free and proprietary software. In the Mythical Man-Month, Fred Brooks described the difficulties of system integration, and estimated that 25% of the time in a project would be spent integrating and testing relationships between components which had already been planned, written and debugged. Building a system or a Linux distribution, then, takes a lot longer than just throwing the latest stable version of every project together and hoping it all works.

By participating actively in the QA process of the project leading up to the release, and by maintaining automated test suites and continuous integration, you can mitigate the effects of both the shifting sands of unstable development versions and reduce the integration overhead once you have a stable release.At some stage, you must draw a line in the sand, and start preparing for a release. In the GNOME project, we have a progressive freezing of modules, progressively freezing the API & ABI of the platform, the features to be included in existing modules, new module proposals, strings and user interface changes, before finally we have a complete code freeze pre-release. Similarly, distributors decide early what versions of components they will include on their platforms, and while occasional slippages may be tolerated, moving to a newmajor version of a major component of the platform would cause integration testing to return more or less to zero – the overhead is enormous.

The difficulty, then, is what to do once this line is drawn. Serious bugs will be fixed in the stable branch, and they can be merged into your platform easily. But what about features you develop to solve problems specific to your device? Typically, free software projects expect new features to be built and tested on the unstable branch, but you are building your platform on the stable version. You have three choices at this point, none pleasant – never merge, merge later, or merge now:

• Develop the feature you want on your copy of the stable branch, resulting in a delta which will be unique to your code-base, which you will have to maintain separately forever. In addition, if you want to benefit from the features and bug fixes added to later versions of the component, you will incur the cost of merging your changes into the latest version, a non-negigible amount of time.
• Once you have released your product and your team has more time, propose the features you have worked on piecemeal to the upstream project, for inclusion in the next stable version. This solution has many issues:
  • If the period is long enough, your feature additions will be long removed from the codebase as it has evolved, and merging your changes into the latest unstable tree will be a major task
  • You may be redundantly solving problems that the community has already addressed, in a different or incompatible way.
  • Feature requests may need substantial re-writing to meet community standards. This problem is doubly so if you have not consulted the community before developing the feature, to see how it might best be integrated.
  • In the worst case, you may have built a lot of software on an API which is only present in your copy of the component’s source tree, and if your features are rejected, you are stuck maintaining the component, or re-writing substantial amounts of code to work with upstream.
• Develop your feature on the unstable branch of the project, submit it for inclusion (with the overhead that implies), and back-port the feature to your stable branch once included. This guarantees a smaller delta from the next stable version to your branch, and ensures you work gets upstream as soon as possible, but adds a time & labour overhead to the creation of your software platform

In all of these situations there is a cost. The time & effort of developing software within the community and back-porting, the maintenance cost (and related unleveraged potential) to maintaining your own branch of a major component, and the huge cost of integrating a large delta back to the community-maintained version many months after the code has been written.

Intuitively, it feels like the long-term cheapest solution is to develop, where possible, features in the community-maintained unstable branch, and back-port them to your stable tree when you are finished. While this might be nice in an ideal world, feature proposals have taken literally years to get to the point where they have been accepted into the Linux kernel, and you have a product to ship – sometimes the only choice you have is to maintain the feature yourself out-of-tree, as Robert Love did for over a year with inotify.

While addressing the raw value of the code produced by the community in the interim, Mal does not quantify the costs associated with these options. Indeed, it is difficult to do so. In some cases, there is not only a cost in terms of time & effort, but also in terms of goodwill and standing of your engineers within the community – this is the type of cost which it is very hard to put a dollar value on. I would like to see a way to do so, though, and I think that it would be possible to quantify, for example, the community overhead (as a mean) by looking at the average time for patch acceptance and/or number of lines modified from intial proposal to final mainline merge.

Anyone have any other thoughts on ways you could measure the cost of maintaining a big diff, or the cost of merging a lot of code?

•  From the archives: the best distros of 2000 | TuxRadar: A trip down Linux distribution memory lane – back to the day when WindowMaker was considered “an attractive alternative” to Enlightenment, the old default GNOME window manager.
• Polymorph: Hacking Business Models: A few months ago, Monty Widenius and Zack Greant got together to talk about what a really great company might look like. Now that he has left Sun and MySQL, Monty is going to try to put the theory into practice.
• TG Daily – Linux saga: Girl drops out of school over Ubuntu: The zealots ruin an otherwise great story on how a girl mistakenly got delivered an Ubuntu laptop, had trouble fulfilling her course requirements and connecting to her broadband supplier, and had all her problems solved by a local TV station. Rather than the story being about the problems the girl encountered – a key opportunity to educate people about Linux – it is now about how rude and insulting Linux supporters can be. Talk about snatching defeat from the jaws of victory.
• There is no Open Source Community: Building Vibrant Open Source Communities: An interesting presentation on building community from OpenCollabNet community manager John Mark Walker
• Herding cats for fun and profit: Four tips for working with online communities | Community, Incorporated | ZDNet.com: Joe “Zonker” Brockmeier, OpenSuse’s community manager, gives his top community management tips
• The Art of Community: Jono Bacon of Ubuntu has been commissioned to write a book on building community by O’Reilly, and as a case in point is writingthe book as a community effort, inviting guest authors and feedback all the way

Recently I gave a class for a friend of mine in Grenoble as part of an “Introduction to entrepreneurship” course he is teaching for a Masters in business studies. He asked me to explain my activity, how I set myself up administratively, and explain the business model and marketing plan of a services/consulting company.

I covered a lot of ground, and it was pretty interesting I think, so I’m reproducing the gist of what I presented here for posterity.

Make money giving stuff away?

After a fairly brief presentation of free software (what it is, some examples, why people are interested in it, the basic community mechanisms involved), I got my first question: how can you make money off something that you give away?

Having read “Free! Why$0.00 is the future of business” by Chris Anderson, I had some ready answers, and teased some more examples out of the students:

• Free razors: Sell more disposable razor blades
• Free newspapers: leverage higher distribution figures to get more advertising revenue
• Free music downloads: sell premium products like box sets, concert tickets, merchandising
• Free Internet services (search, email, film, photo management, …): Leverage the ability to follow behaviour patterns and high volumes to increase advertising revenue.
• Free first version, pay for upgrades: Used effectively in the drug trade. Get your users roped in.
• Free cellphones, monthly subscription: sell more of the high-margin recurrent product for the cost of the low-margin one-off purchase.
• Free flights, make money off sandwiches, alcohol, advertising, …

In each of these cases, you can see a basic process at play: free drives volume, to drive the sale of complementary goods. For a musician, concerts are a complement to CD purchases. The bigger your fan base, the more concert tickets you will sell, all else being equal. For free newspapers, advertising space is a complement to distribution.

In general the following rule holds for complementary goods: when the demand for a good goes up, the demand for its complements also goes up. And assuming a normal demand curve, when the price of a good goes down, its demand will go up. So all we need to make a feasible business model based around free software is to find natural complementary goods to the software. There’s no shortage: training, books, custom software development services, support, upgrades, magazines, other software for the platform, the hardware the software comes on, services related to the software’s function (think: photo development services for a photo management application, or web search for a web browser). And there are all the loosely related things that relate to this, like the HR consultants who specialise in finding experienced free software developers.

For me, I chose consulting services, and training. Due to my experience in the free software world, I’m well positioned to help companies who don’t understand the mysteries of how everything works to grow healthy communities, or to become good citizens of the projects they work with. I’m developing training courses on working with free software communities, and developing GNOME and GNOME Mobile applications. And I’m working directly with communities doing the stuff that needs to be done to enable the community to be effective.

Selling your wares

Next up, we discussed how someone might sell those types of services. Of course, your personal network is vital for this, and you need to be working all the time to grow that network, because you never know where the next opportunity might come from. I make a point of talking to whoever I’m sitting beside in airplanes, and not just because the flights go quicker that way. You never know who might be able to help you, and who you might be able to help.

On top of that, you need to build credibility with the people who will be paying for your services, and the people who will be ordering your services. In big companies, this will often be two different people – the person who wants you to come train their team is probably not the person with signing authority on the training budget. So you need to work to build credibility with both. You also need to have credibility with the influencers of purchasing decisions. A manager may ask the opinion of the latest intern to join the group who “knows this open source stuff”.

One good way to do this is to write and publish. Regular newspaper or magazine articles, a well-maintained blog, perhaps authorship of a book or two are all useful references for someone when they are trying to figure out if you’re any good. You should try to target publications which your targets inside your prospects read. If you’re aiming for the CIO, then he probably doesn’t read Linux Magazine, but perhaps you can be a guest writer in something like CIO or 01 Net? The intern, on the other hand, might well have a Linux Magazine subscription.

Another great way to build your network, and to gain credibility, is to give presentations in conferences. This is something you should work at – make sure you give a good presentation. If in doubt, practice live first, in front of the mirror is a good start, real people is even better. There are lots of resources out there on giving better presentations, I enjoyed “Really Bad Powerpoint” by Seth Godin, “Presentation Zen” by Garr Reynolds (and related site), “slide:ology” by Nancy Duarte, and “The Back of a Napkin” by Dan Roam (related site) (thanks to Stormy Peters for the last two references). Target conferences that give you a good chance to meet the people who will be buying your services, or at least who will be influencing purchasing decisions.

If you’re trying to build credibility as an expert in a specific area, you should also actually be an expert in the area. If you’re trying to make money selling support of Drupal, then you should probably be on a first name basis with Dries. Ideally, you will be an active developer on the project, and will be able to point to major features you’ve contributed.

And nothing works better as a marketing tool than having good references. When you have made people happy, they will get you more work. So make sure you are doing that.

How much do you charge?

One of the hardest things to do as a consultant is to figure out how much to charge for your services. And we spent over half of our three hour course talking about this.

The first way to figure out how much to charge can be called cost-plus.

You decide how much money you need, how much time you’re likely going to work to earn it, and divide to get a daily or hourly rate. They you add an amount you think that you can get on the market, and at the end of the year, this is your company’s profit. Profit is handy, since it’s what allows you to grow – to hire new people, take on new projects, and maybe move from consulting to a product-based business model.

A well-known rule of thumb (which Stephen Walli recently restated to me) is that a successful consultant will bill roughly 50% of the available time in a year. Some years will be worse, some years will be better. But between looking for new clients, down time between projects, and handling everything that you need to do when you’re at the head of a company, 50% is a good target to aim for.

The work year is 52 weeks, 5 days a week. Some people might say 6 days a week, but for me, with 3 kids, quality time on weekends is important. If you take 4 weeks vacation a year, and take away public holidays, you’re left with a working year of 230 days, give or take. So if you do well, you’ll be billing 115 days a year.

One of the advantages of consultancy is that the overheads are low. You don’t have to purchase or store stock, and your gross margins are close to 100% since you’re basically selling grey matter. That doesn’t mean you don’t have costs, though – lawyers, accountants, insurance (liability, health, social, life…), government taxes, social charges on what you pay yourself, travel to conferences, dinners and lunches with clients, computers, various subscriptions (cellphone, internet, phone), rent, furniture for the office, the list goes on.

For argument’s sake, let’s say that you want to make €3,500 per month, or €42,000 per year, before tax but after social charges. You will need to invoice in the region of €70,000 to €80,000 during the year. Assuming, as we have, that you will be invoicing 115 days during the year, you need to be charging between €650 and €800 per day. When you say this to students who would probably take a job very happily for €30 an hour, they can be pretty surprised.

There’s a second method to pricing your services, which we’ll call value-minus. It is the reason CEOs, film actors and professional sports stars get paid obscene amounts of money. In short, they’re worth it.

Why would a film studio pay $15 million to Angelina Jolie to star in a film, when they could have had someone else for a tenth of the price? Because having Angelina Jolie in the film guarantees you attendance. It guarantees you a successful press tour. If Angelina’s’ last three films all grossed over $100 million, then the chances are her next one will too – at least partly because she’s on the list of stars. The same thing goes for David Beckham – a club pays for him because the extra merchandising, bums on seats and (presumably) improved results will earn the club back more than they are laying out for him. And Steve Jobs can argue convincingly that part of the blockbuster profits that Apple is raking in are thanks to his stewardship of the company – and as such it’s normal that he be paid in consequence.

If you can put a dollar value on the money that you will earn or save a company by working with them, then you can sell your services for that amount less a dollar, and it is worthwhile for the company to hire you.

As a consultant, it’s hard to do that, though. How do you measure how much more effective a development team is after your training? Feedback is helpful, of course, but you will be measuring the team’s perception of your training, not actual dollars on the balance sheet. Performance metrics are important. Are the team getting changes upstream quicker after your attendance? Are there fewer days being spent on maintenance of local patches? How many fewer? “Reduced maintenance cost by 18% in the year following intervention” is a great headline.

It’s not always possible to follow up and get exact figures, though. To measure the effect of your services, you would need to be measuring before and after for the measurement to mean anything – and in companies that have problems working with free software, they’re not measuring anything, and that’s part of the problem.

But there are ways to infer the value of your services. I have to give a hat-tip to Andreas Constantinou for pointing me to “Million Dollar Consulting”, which opened my eyes somewhat to this.

To work out the value you might have for them, it’s useful to think of substitute goods for your products and services.

Substitute goods are goods which can be used instead of each other. Substitutes can be perfect or imperfect. One brand of car or another are close to being perfect substitutes, but taking the train, or riding a bicycle, might be other substitutes that address the same basic need of getting from A to B.

As a consultant you’re selling information in exchange for time. You’re saying “there’s nothing I know that your team won’t find out eventually on their own, but I can help you get there quicker”, or “you could hire a graduate and train him up for 6 months, or you can hire me now and I’ll be operational Monday”. Other consultants might be perfect substitutes for you (although of course you’d argue they’re not, since you’re so much better), but training, subscriptions to market analysis firms, magazine subscriptions, mentoring programs, or travel to conferences might all be substitutes, since they all address the same basic need – save the client’s time by getting him the information he needs quickly.

A good way to see what the substitutes to your service are is to follow the money. What budget would your services be coming out of? What else does the budget get spent on? Do your services replace or complement other things coming out of the same budget?

As an example, a company might decide that sending 10 people to OSCON for a week is the best way to get them up to speed quickly. 10 plane tickets + 10 weeks in a hotel + 10 expense reports + 10 registration fees might set the company back somewhere in the region of $30,000. So if your one week intensive training course saves them the need to send 10 guys to San Jose this August, you’ve saved them $30,000. You can charge $20,000 + expenses, and they’ll think it’s a bargain.

There is no right answer to the question of how to set your prices, and you’ll quickly find yourself adjusting your price depending on how involved or risky a project is – it’s unlikely that you will have a one-size-fits-all price. But thinking about the price of your substitutes can help you at least be in the range of market expectations.

Market expectations are intimately related to price. You will learn quickly that a lower price does not necessarily make you a more attractive option than your competitors. Price communicates something – skill. As a consultant, you want to position yourself as an expert, and experts cost a lot.

That said, if your competitors’ prices are substantially lower than the figure that you got out of your cost-plus calculation, you might consider looking for a different line of work, or revise your needs down. If you want more money than the market is willing to give you, the chances are you will end up disappointed.

So – there you go. Food for thought, and there are probably plenty of approximations there for people to jump on. I stand by the basic thrust:

• Base your business model on a complement to the free software you work with.
• Figure out who will be influencing buying decisions, who will be doing the buying, and who will be doing the paying, and figure out how to build credibility with each of them
• Price your services based on the value you give to the company, while keeping an eye on how much you get paid at the end of the month. Estimate value based on the market price of substitutes for your services.