Author: Bruce Byfield
that it has been six years since FOSS began to have a market impact. Now, with the dot-com crash and a recession in the technology sector behind us, companies are still trying to answer the question, “How can we make money from FOSS?” I can’t pretend to give a complete answer, but here are a few observations that might improve the odds.
At the companies where I’ve been a manager or a consultant, I’ve seen what works. More frequently, I’ve seen what doesn’t work. Stormix Technologies,
my introduction to FOSS companies, was never profitable. Nor, in my day, was
Progeny Linux Systems. At other companies, I was a consultant, and didn’t hear all the private decisions, but too often, I’ve seen the same mistakes being made over and over again.
In the hopes of preventing the new wave from making the same mistakes as the old wave (and not, I hope, simply freeing them to make their own mistakes), I present here a summary of what I’ve seen. Some of the comments might seem self-evident, except that, from what I’ve seen, for most people, they’re not. Others are not unique, but take a special twist when applied to FOSS.
You’re not smarter than the FOSS communities
The entrepreneurs of six years ago greeted FOSS the way a barbarian horde might greet the discovery of an unwalled city. It seemed to beg to be plundered. Many members of the community were young. They were willing to work cheaply because they believed in what they were doing. Most of all, they were giving valuable intellectual property away for free.
It took the entrepreneurs a while to realize that young doesn’t mean stupid, and idealistic doesn’t mean naive.
One company learned the hard way when it was negotiating the internship of a teenage free software developer. The developer was the lead on a project that promised to make an important commercial product obsolete, and the company was eager to acquire the rights. Its general counsel sent him a densely worded contract in which he reassigned all rights to the company. Fortunately, the developer had an aunt and uncle who were intellectual property lawyers and could advise him. He refused the offer, and the company failed to pull off its coup. The project continued under the GNU General Public License, and is now a standard tool in most GNU/Linux distributions.
Six years later, the FOSS communities may be as idealistic as ever, but they’re much less naive. Naturally suspicious of people who want to take without giving back, they’ve had their suspicions strengthened by dozens of encounters with entrepreneurs, each of whom is convinced that nobody else has had the same idea about plundering the communities. Just as importantly, the communities have their work adapted by millions, and,they have reason to believe that their software licenses will be upheld in court.
Under these conditions, entrepreneurs moving into FOSS no longer have the advantage — assuming that they ever did. If they want to thrive, they have to learn the customs of the communities, and keep to them.
Focus your business plan
In 1999, FOSS was new in the marketplace. No one was quite sure what it was good for, and companies galloped off in all directions. Distributions, firewalls, professional services, Web services, gaming, embedded system — at least a dozen companies tried to explore all these directions at once, often with fewer than a hundred employees. Even Progeny, which came late enough to the game to learn from the mistakes of others, tried to combine a Linux distribution with the product it really wanted to develop, and went on a wild ride for several months while it learned to focus and survive.
Today, FOSS executives know better than to act as if they’re suffering from a corporate version of Adult Attention Deficit Disorder. Progeny transformed itself successfully into a custom development house. Red Hat dropped its commercial distribution to focus on enterprise servers. Similarly, among the new companies, Alacos is carving out a niche in migration from Windows, and Black Duck Software in the managing and licensing of software code.
The prevailing attitude now seems to be that the FOSS communities provide the general functionality, and FOSS companies provide the specialization. If the idea doesn’t always work, or isn’t wildly successful, at least it’s more successful than the old free-for-all.
Repackaging FOSS isn’t enough
When software is freely available for a download, wrapping it in marketing material is a service for which relatively few are prepared to pay. Consider:
In 1999, retail distributions of GNU/Linux were available from six companies: Red Hat, SUSE, Turbolinux, Caldera, Mandrake, and Corel. This crowd left little room for newcomers like Storm Linux or Progeny Debian. Both had trouble finding retail outlets even in their home cities.
Today, Turbolinux and Xandros, which purchased Corel’s distribution, are second tier. Caldera, reincarnated as The SCO Group, is into lawsuits rather than retail boxes. Red Hat leaves the desktop to the Fedora community. Meanwhile, Mandrake, as its acquisition of Conectiva makes clear, is feeling itself squeezed out by Red Hat and SUSE. Moreover, during the last six years, only Linspire has emerged as anything like a new challenger. Yet, over on DistroWatch, the number of distributions is as high as ever.
Develop a hiring schedule to meet changing needs
When a company is new, its main need is programmers. However, as the company moves toward product release, it needs new skills, and the number of non-programmers needs to increase. Even a fast hire usually takes two to three weeks, and new employees need to get up to speed before they can manage a product after it is released. That means that companies need to start interviewing for new employees at least two months before they actually need them. This scheduling is especially hard to understand if a company is founded by developers who are unused to thinking about business needs.
However, if hiring is not planned, a company may find itself with a product, but not enough people to promote it. Distributors, retailers, marketing channels, and potential partners all need to be cultivated, or the product fails.
Yet, if the staff isn’t in place to handle all these tasks, the rest of the company suffers as people are pulled from other areas to fill in. For example, the first release of Storm Linux occurred with only one person handling the business side of the company — and he was still learning the product. In order to attend promotional events, Stormix had to recruit volunteers from among the programmers. The trouble was not that the volunteers lacked marketing experience. In fact, many adapted extremely well. However, the week of a trade fair or a promotion, the company virtually closed down because so many people were away. These interruptions were probably the main reason why the company took eight months to replace the much-criticized first release with the more acclaimed second one.
Avoid internal divisions between programmers and non-programmers
At any tech company, this division always threatens. To the average programmer, job satisfaction means hot projects and writing tricky bits of code. By contrast, the average executive is looking for more pay and a shortcut up the corporate ladder. Where programmers judge people by knowledge and accomplishment, executives judge them by status. Given these differences in outlook, misunderstandings are probably inevitable.
Yet, in a FOSS company, these differences can be emphasized even more than usual. The FOSS communities take the tendencies of programmers to an extreme. They’re also more coherent in their philosophy. A company may be able to find managers with some understanding of ordinary programmers, but managers with an understanding of FOSS are practically non-existent. Unless management takes care, the programmers can end up seeing the rest of the company as mindless droids, while the management talks condescendingly of the programmers’ naivete.
To keep the two camps together requires working overtime on interpreting one to the other. On the one hand, programmers need to understand that the open source view that a release is ready when it’s ready doesn’t sit well with investors. On the other hand, non-developers need to understand that slapping copyrights and patents over everything is not just distasteful to programmers, but can cause serious licensing problems — problems, moreover, that the programmers may understand better than they do.
The trouble is, both sides may resist cooperation. At one company, a young programmer was in the habit of interrupting any mention of corporate strategy by announcing that the discussion was “evil.” Similarly, one company founder showed his opinion of his development team by writing a series of increasingly hysterical general emails in which he addressed the staff as children, and threatened dire consequences for everybody if the person guilty of dropping gum on the office carpet didn’t confess. Unsurprisingly, the developers started avoiding him and stopped communicating with him.
Sometimes, the results of this lack of understanding can be comic. For instance, one company owner was so delighted to check the office webcam at 11:30PM on a Saturday and see the entire development team at their workstations that no one had the heart to tell him that they were playing Quake. More often, though, the lack of mutual understanding poisons the everyday culture of the company, and keeps employees from working together.
Everybody in the company must understand the products — and the community
Some professional sellers claim that they can sell anything. They’re wrong, but never more so than with FOSS. With FOSS-based products, employees don’t just need to understand the software — they need to understand the communities behind them as well. Otherwise, each gaffe tends to be followed immediately by the sound of doors slamming shut.
For example, when one manager received a copy of the Melissa virus on her Windows computer, she dutifully warned her correspondents, including at least one employee of the Free Software Foundation. When politely told that Linux was immune to the virus, she replied with “Isn’t Linux great?” — a false bit of enthusiasm that fooled no one into thinking that she was actually using the operating system. The story echoed back to me from several different sources, with different details, but always with the name of the manager and her company.
A media relations manager made an even worse gaffe when she referred to the staff of a trade show display as “booth babes.” A few people complained of sexism, but more considered the comment as an insult to a community that prides itself on rationality. The release was soon pulled, but the damage had already been done. At the next trade show, the company was being openly cited as a business that didn’t understand FOSS.
How much these incidents cost each company in lost opportunities and business is impossible to say. However, another time, I saw a deal torpedoed by a business development manager who insisted that another company’s demo was too hard to install. The reason? He didn’t know what a tar file was, let alone how to use it. I can still see the look of mingled disbelief and dismissal slipping over the faces of the representatives from the other company. At that moment, I knew that the deal was lost.
Market the company to both the business and FOSS communities
Any company needs marketing. FOSS companies, however, have the added challenge of having to market themselves to both the business and the FOSS communities. These are two very different campaigns, because the audiences want different messages.
The business community wants to know that a company is a reliable partner, a message that can be easily lost in the static of lingering suspicions about FOSS. By contrast, the FOSS communities want reassurance that the company does not simply exist to exploit their volunteer labor. They’ll also ask questions about when the company is going to make contributions to the community — usually code, but possibly also cash and marketing or the sponsorship of a conference. They want proof that the company is a credible member of the community.
It helps, of course, if your company hires people who already have a reputation in the community. Progeny, for example, had little trouble gaining trust because it was lead by Ian Murdock, the founder of Debian, and employed known Debian Developers such as Branden Robinson, John Goerzen, and Jeff Liquia. Stormix also had Debian Developers, but less prominent ones, and had a correspondingly harder time convincing the community of its good faith.
The difficulty in communicating these two messages is that very few people are capable of delivering both messages. If a company has the budget, it may make better sense, as Sxip Networks has done, to hire a separate evangelist for FOSS community marketing.
Once a company has proved itself a trustworthy member of the community, it is more likely to attract volunteers. Yet, even if that doesn’t happen quickly, or to any large extent, the effort to respond to the community pays off with good will. This good will can become a word-of-mouth marketing campaign that’s far more effective than any other effort that the company can afford.
Last words
Following these tips won’t guarantee that your new FOSS-based company will survive. Most new companies of any kind fail, often for reasons beyond their control. Moreover, for some people, being warned just means finding subtler stupidities. And the FOSS community is still a relatively new environment that many executives will have a hard time to map. Still, paying attention to these suggestions should remove some of the more common problems. And let’s face it — if you’re part of a startup, you have enough problems without taking on unnecessary ones.
