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.

Come by & see me!

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?

Governance comes in many shapes & sizes of course. My favourite governance stories are about federating individuals, who manage to channel community efforts, maintain a meritocracy where code talks, and yet don’t come across as authoritarians.

Outside of Linus (who’s a good example), Ton Roosendaal of Blender has this kind of presence. Talking to Ton, it is easy to see that he cares about Blender and about the Blender Community. The care and attention that he brings to projects like “Elephants Dream” and “Big Buck Bunny”, or to the supporting documentation and conferences he organises for the community, illustrate the esteem in which he holds his users and his developer community. Even the way the Blender Foundation came into being was amazing.

One of my favourite communities is Inkscape. When they broke from Sodipodi, there was this acrimonious flame war, and something of a bitter taste in people’s mouth. So what Bryce Harrington, Nathan Hurst, MenTaLguY and Ted Gould did when they split was decide to throw open the doors, and accept code from all comers. They set a direction and some ambitious goals, but they were very clear from the start - come right in, you’re welcome. And this gave the project some great results, especially early on when it was still establishing itself. Bryce describes one of them in this article.

The success of the Inkscape project’s governance model is borne out by its ability to escape founder’s syndrome - Bryce, Nathan and Ted have now backed away from the project to some extent, they’re still there as wise heads, but they have passed off the direction of the project to other capable people.

I think the way that Drizzle was born bears some resemblance to this, and I really like the way they have consciously broken down the walls which were necessarily up around MySQL. Brian Aker’s been something of an inspiration on this. His mission statement at the announcement of the project was astounding.

Subversion’s governance model is an exemplar of best practices too. Set a clear project scope (”Subversion is a compelling alternative to CVS”), clear goals, establish transparent and fair community processes, and open up the gates. Anything within the scope of the project is fair game. And once again, code talks. This story, from Karl Fogel’s “Producing OSS” illustrated the robustness of their governance, and the confidence the project’s leaders had in their ability to influence the project.

The Maemo Community Council has the potential to be a very good governance structure, I think.  The idea of a governing body of the community, by the community, for the community, whose goal is to canalise the efforts of a disparate group into something coherent, and to provide a legitimate point f contact for technical decision-makers in Nokia, is a novel one, and hasn’t been tried, as far as I can tell, by other companies.

Counter-examples of good governance are all around, I won’t name any in particular to protect the guilty. But many of them stem from a misguided belief in absolute free speech, to the detriment of the quality of discourse and code in the project (”we are all created equal”) which results in very chatty, but unproductive, individuals taking senior positions in the community, or a sort of shyness of the founder or leader, who doesn’t believe that it’s his place to set a direction and tone.In company-run projects, excessive control or influence is an equally toxic characteristic. Companies who retain a veto on community decisions are companies who do not trust their communities.

•  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.

The false assumption here is that only software companies can make money off free software in a “pure” way.

There are lots of ways of making money leveraging free software. Simon Phipps writes often on about the core principle behind some of these.

First, there are all the hardware-based models. Reduce your per-unit costs for some hardware you’re manufacturing because you’re integrating a free software stack. Make a better product, because you can modify the software running on it from top to bottom. Sell more server hardware because your software is more widely distributed. To paraphrase Doc Searls, people aren’t making money with free software, they’re making money because of free software.

Second, you have the software as a service business model. If your software gets more useful the more people use it, then at some stage, it doesn’t matter whether it’s free software or not - the value is in the user base and the data. Imagine a SugarCRM where there were substantial network effects in having an account on their hosted service. Eventually, it wouldn’t matter that the platform is available for download, the value would be in being hosted.

And thirdly, you have what Simon says “payment at the point of value”. Get your software out there. Make sure that you’re heavily deployed. And set yourself up so that when people need help they come to you. This is the “pure open source” play, and it is the one which I have talked about before. In this model, you’re open to competition, since you are monetising a value-adding support and expertise in a product which anyone can master and change.

There is a fourth way of making money off free software which doesn’t make sense for a company, but might make a lot of sense for an individual developer. And that is, get paid to do what you love by someone who belongs to the first three groups, and who values your expertise. Thus, Nokia, Novell, Red Hat  and Canonical hire established  free software developers to keep on doing what they were doing before, for money - because what they were doing has value to those companies in the context of their business model. Companies such as these, and other companies who hire people to work on products they depend on, are ensuring the future of free software.

If your company is building products on free software projects, then you would be a fool not to invest in those projects to ensure they continue to develop and improve. You can invest with a service contract, by outsourcing to a company like Spikesource, or by hiring in a hacker - the net result is the same. Companies using the software will ensure that key free software projects will continue to develop, independent of any one business model.

Neary Consulting

74 rue Maurice Flandin

69003 Lyon

France

It’s been great to get out of the house every day, we already have a plan to work with one client together, and I have come to realise how much I missed being able to bounce ideas off people when trying to explain some pretty basic stuff on algorithms, data structures and the usefulness of knowing first principles when you’re writing code in a higher level language like C# and Java to their intern - I got slightly mixed up, and meandered down a long and winding path without getting to the point.

Hopefully being around Real People over the next few weeks will sharpen up those thinking skills somewhat.

One major difference over the home office is that now, on Wednesdays, when the kids are home, I don’t have to wear ear-plugs any more.

Moving the Mobile industry from purchasing to co-development in free software communities

Recently, Matt Aslett wrote an article about the way that attitudes to free software evolve over time within a company, using a graphic he got from the Eclipse Foundation, based on some Nortel funded research. Software sneaks in on the ground floor, going from simple use of components to a real understanding of community-driven development, resulting, long-term, in building free software projects and strategies.

Matt sees an evolution in attitudes as the software and its value is discovered at different levels of the organisation, before finally the business development side of the company picks up the ball and drives free software into the heart of the company’s product strategy.

I have also seen this learning process in action, but I would express it differently. People discover the value of the freedoms granted by free software one by one, more or less independently of their level in an organisation – exploring each freedom before discovering its limitations, and thus discovering the value of the next freedom, and qualifying for the next level.

The core freedoms  in the Free Software Definition which are granted to the user of free software are:

1. Freedom to use
2. Freedom to modify
3. Freedom to share, freedom to redistribute
4. Freedom to participate

As companies start to integrate free software components into their products, they discover the value of these freedoms one by one.

Use

The first thing that people see about free software is FREE! As in zero cost. The days when companies reject a product out of hand because they don’t have to pay for it are gone – Linux, OpenOffice.org, Apache, Red Hat and a plethora of other “free” products have proven themselves in the marketplace, and companies are now prepared to allow free software components into their solutions, after appropriate consideration of the licences involved.

To quote one attendee at MAPOS 08, “why would I want to write a compression library, when I can download the best one in the world from zlib.org?” In the area of specialised components for secure communications, compression/decompression, a commodity kernel, and a bunch of other situations, it is appropriate to use free software components off-the-shelf. We expect them to work, and we don’t expect to ever need to talk to the maintainer.

Free software components are in use like this in thousands of systems solutions and commercial products, often without their authors even being aware of it. The main advantage of this for a systems or product company is a saving of time and money, through having a fully functional component without having to go through a purchasing process, and a reduced software bill of materials. An additional advantage is the simplification of your licensing due diligence, thanks to the relatively well-understood consequences of the various popular free software licences.

The difficulty arises when the software doesn’t meet your needs. In many cases, libraries are written by an individual to scratch an itch – it works for him, but is not quite up to your requirements. As one friend of mine put it: “Open Source: 80% as good as the last guy needed it to be”.

Perhaps it’s software that works on 32 bit platforms, but has never been tested for 64 bit. Perhaps it has not been ported to ARM or MIPS. Or perhaps the author simply never imagined that anyone would want the feature which you find indispensable.

In this situation, you can always ask the software author to write the feature or fix the bug for you – but since there is no client/supplier relationship between you, it is entirely reasonable for a volunteer to put your request on the long finger, or reject it outright.

At this point, you realise the value of having the source code – you can modify the software to meet your needs, or pay someone else to do it for you.

Modify

Being able to modify software that doesn’t quite meet your needs is amazing. This is the way things used to work by default, but the shrink-wrapped software revolution of the 1980s got everyone used to the idea that software was a valuable asset to be protected from public view at all costs. When I worked for Informix in the late ’90s, we used to refer to the source code of our leading product as “the crown jewels”.

With the widespread acceptance of free software as an alternative, developers are no longer surprised when they may see how a program works, and change its behaviour. This ability brings two important and immediate benefits – you have control of the behaviour of the software, and you can adapt it to suit exactly your needs. The old choice of build vs buy has become: build vs buy vs extend.

This situation is common in software services companies which provide vertically integrated “solutions” to corporate clients. You take components where you can find them to speed up initial development, stick everything together with duct-tape, hack whatever you need in whatever libraries you’re using to make everything pass the client’s integration tests, and then publish a set of .tar.gz files somewhere on the website of the company to fulfil any licensing requirements.

This control and ability to tailor a solution comes at a price, however. Over and above the cost of making the changes, your team is lumbered with a maintenance problem. Let’s say that implementing the features you need on top of a component the first time round takes a month. Fixing bugs in the features when it has been rolled out can take another few weeks. A few months later, the upstream product you’re based on goes and releases a shiny new version, with lots of compelling new features that you really want.

The cost of integrating your features into the newer version, and doing extensive regression testing before rolling out the new version, might take you another 6 weeks. It is not unusual for time spent integrating your work into later versions to quickly outweigh initial development time and investment. Inconveniently, this is typically effort which is not budgeted for beforehand.

After a company has run into this problem a couple of times, over the course of a year or two, someone will usually suggest that you propose that the features you have developed be sent upstream to the projects you work with – if the feature is accepted, you have solved your maintenance problem, it will be in all future releases of the project, and all of that tricky integration work and regression testing work will get done upstream, as part of normal maintenance.

Redistribute

And so you tell your star hacker Jack that he has two weeks to get your 5,000 line patch down to manageable size by getting your work integrated upstream. (when I said this at MAPOS, no-one laughed – so maybe this does not sound as ridiculous as I thought it did).

He diligently goes to work, cleaning up his code, getting rid of all the warnings, spliting up the big diff into small manageable chunks, creating accounts in 10 different bug trackers, signing up to a dozen mailing lists, creating 47 bugs with terse descriptions, attaching proposed bug fixes, and for major features he sends email telling people that the feature is there and asking for review.

By the end of a frantic month, two weeks more than he was given, he reckons that if everything he’s submitted is accepted, your 5,000 patch will be down to a more manageable 2,000 line patch.

What happens next is… underwhelming.

Major features and bug fixes lie unreviewed for weeks or months. Those that are reviewed need changes which take time and effort. Some patches are rejected outright because they’re too big and the feature is difficult to review.

A post mortem analysis of the project of “giving back to the community” might identify some of the following conclusions:

• Not enough time and resources were devoted to advocating your changes upstream
• Personal relationships between Jack and the project maintainers led to a much higher acceptance rate for patches and feature requests
• The projects were initially evaluated on technical grounds, no thought was given to the developer community underpinning it
• In some cases, maintainers priorities were ill-understood

There are two common conclusions that people make from this kind of analysis;

1. It’s not worth it. They don’t want our work, and the time we’re spending is costing us more than maintaining out-of-tree patches
2. Perhaps if you had engaged with the projects before modifying them heavily, or had been regularly sending contributions, that the maintainers would have been more encouraging, and might have been more prepared to consider your work. If someone from your company was a maintainer or committer already, you would have had a valuable short-cut to getting your agenda implemented in the upstream project.

If you choose door number 1, you will go no further in your quest to really understanding free software processes. This is a reasonable thing to do, but the costs involved are often miscalculated. In addition, the benefits of influencing upstream projects are often vastly underestimated.

If you choose door number 2, you have concluded, in short, that it is madness to include a component in one of your products and exert no influence with upstream projects.

Participate

To have influence, you must understand how the community around a project works. Someone within the team must become an active, trusted member of the community. Once they have gained the trust of the community through their contributions, there may be some procedure to follow for them to become a maintainer of the project, or to gain commit privileges.

These considerations are not technical, for the most part. Friendship and trust are fuzzy human concepts. And this more than anything else brings me to my final point.

Community is hard

For a start, every community is different. They all have different people, different behavioural norms, different dynamics, different forums for communication.

Taking GNOME Mobile as an example, there are 18 projects in the GNOME Mobile platform, with another 10 or so in incubation. Within that, we have a large number of projects housed on gnome.org, and governed by our rules, procedures and conventions. And yet each project has its own set of maintainers – GTK+ is maintained by a committee of around 10 people, EDS is maintained principally by Novell employees, gtkmm has one core maintainer, and so on.

On top of this are a number of freedesktop.org projects, and a couple more which are not under either of these umbrellas. To be an effective influencer of GNOME Mobile, you need to learn the culture of over 20 projects, of wildly varying sizes and baggage.

There are a number of issues to bear in mind when you approach a free software community for the first time. The main one is that while the vast majority of projects think that they are welcoming people with open arms and are very welcoming, if you are a stranger to their land, it is very likely that you will be getting exactly the opposite message.

In some cases, the extent of the welcome is “go and read wiki page telling people how to contribute to the project”. In other cases, no wiki page exists. Occasionally, you will be told that you’re asking your question on the wrong mailing list, or in the wrong way, or that you should read the relevant documentation first. It is not unusual for people to answer questions with a very terse answer – perhaps a link to a mailing list discussion or web-page where the answer can be found.

In general, all of these things are intended to fulfil a simple goal – get you the information you want as quickly as possible, in a way that wastes the time of people already in the project as little as possible. An admirable goal indeed, but as a newcomer, this is not how people are used to being welcomed. Eric Raymond wrote extensively about this in his essay “How to ask questions the smart way”.

Indeed, one of the hardest things to do as an outsider looking in is to evaluate when a community is healthy and viable, and when it has problems which will prevent you from working effectively in partnership. Few resources which talk about healthy free software community projects exist - “Producing Open Source Software”, by Karl Fogel, is something of a bible on the subject, and should be required reading for anyone considering investing in free software. I have also found some presentations, including Simon Phipps’s 2006 OSCon keynote “The Zen of Free” and “How Open Source Projects Survive Poisonous People” by Ben Collins-Sussman and Brian Fitzpatrick, to be excellent resources in helping identify traits of what makes up a healthy community. Two other useful papers which include metrics on measuring the openness of a community, including its governance model, are Pia Waugh’s “The Foundations of Openness” and François Druel’s Ph.D. Thesis (in French) “Évaluation de la valeur à l’ère du Web ” (PDF - rough translation: “Measuring value in the era of the Web”).

Some of the considerations when evaluating a community are whether there is clear leadership, whether that leadership is an individual, a group, or a company, how the leaders are chosen (if they are chosen), what technological and social barriers to participating in the project exist, whether the community processes are documented and transparent, what recourse one has if one feels badly treated, what the behavioural norms of the community are (and whether they are documented) – the list goes on. Pia’s paper in particular gives a great overview in the section “Open Governance”.

Call to arms

And so I close with a call to arms to both free software communities, and companies planning on developing an “open source strategy”.

First, developers, document your communities. Think of yourselves as guides, explaining the cultural quirks of your country to a newly arrived immigrant. Be explicit. In addition to explaining where and how your community works, document how one gains trust and responsibility. Ensure that a newcomer can learn quickly what he needs to do to become a citizen and from there a project maintainer. I am not saying that it should be easy for someone to become a maintainer. What I am suggesting is that it should be easy to see how one becomes a maintainer before doing it

Next, project managers, software developers, company leaders: please, please, please – save yourself time and money and, when you reach the point where you will be building products which depend on good free software components, let the second thing that you do, right after a technical evaluation, be to evaluate the health of the community. A community where you can earn influence and guide the project to better meet your needs is a better long-term investment than betting on a slightly technically superior solution with an unhealthy governance model.

You are building products that you will be selling, supporting, and hopefully profiting from. In this situation, does it really make sense not to have the developer’s ear?

Jerry Maguire

“Fewer clients. Less money.” Sacrilege in a world where the goal is to grow the first billion dollar “open source vendor”. But that chimera that Matt Asay holds a torch for may never come. Free software has a lot of selling points - and the main one is that if your vendor is charging you too much money, you can find a different, smaller one who will charge you less.

That doesn’t mean that the originator of the software can’t make money - knowing the software better than anyone else, and being able to customise the software, is a pretty powerful selling point and a clear path to building a profitable small business.

As many commentators have said (and I agree), support is not a scalable business model. Other smaller, more agile, companies can start businesses around your product, gain expertise, become contributors to your project, and syphon off some of that yummy support and maintenance cash you’re hunting for.

But so what? Free software doesn’t get developed like proprietary software, why should the free software industry look like the proprietary software industry?

Here’s my vision of the future: Smaller businesses. Each with fewer, happier clients. Less money. Lots of them, all over the world.