English » tarmo.fi

The agile way of starting a company

I just listened to Greg Gianforte’s presentation on bootstrapping a company. What he says is that the way of starting a company that’s taught in all business schools is not the right way. Of the hundreds of thousands of startups every year, only one percent follow the business school dogma of writing a business plan, finding investors, and then starting to develop a product.

Greg’s message is also available in his book Bootstrapping Your Business: Start And Grow a Successful Company With Almost No Money. The basic message is to start by contacting potential customers and asking them would they be interested in the product or service. And if not, what would make them interested. After a good amount of these inquiries you’ll have a very good idea of what you should develop to get interested customers. And it’s a lot sooner than with the traditional method, where the first contact with potential customers can be 1-2 years after starting to draft the business plan. And at that time it’s a lot harder to accomodate customer requests that you haven’t thought up. Whereas with bootstrapping you can respond to all requests, because you have no product – yet.

This whole approach seems quite reasonable, and has a good analogy to the agile software development method. The method taught in software engineering schools is to start with requirements gathering, followed by analysis and design, followed by implementation, then testing, and finally delivery. The agile approach is to start with a minimal set of requirements, first do tests, then implement those tests, do analysis and design as necessary, refactoring the code while you’re at it, delivering every 2-4 weeks, and gathering more requirements after each delivery. The benefits are pretty much the same: you have customer contact with every release, not just at the end of the project, you’ll have a working product after 1-2 iterations, and you can respond to customer requests more easily.

Blackboard's eLearning patent is going to be reviewed

Flosse Posse commented in August on the absurdity of Blackboard’s eLearning patent claim. Now action is being taken, as the Software Freedom Law Center is demanding that the patent be reviewed and revoked if necessary.

The power of the networked community of people can be seen in the huge article on Wikipedia on the History of virtual learning environments which goes back to 1728. This massive collection of references was one reason that the SFLC decided to go ahead with this action. Well done, everyone!

And why is it that Microsoft seems to be involved in all of these sleezy patent claims, like the SCO vs. IBM (or the Linux community), which was resolved yesterday and SCO lost royally.

The power of the PHP community and the demise of Microsoft

When I read Moishe Lettvin’s blog entry about the design of the Windows Vista shutdown mechanisms (moblog: The Windows Shutdown crapfest), it immediately connected with the podcast from Open Source Conversations on business benefits of PHP. The main benefit that several companies gained by switching to PHP was reduced time-to-market. The main reason for this is not that the language is simple, but that the PHP community has become so huge and vibrant that any new feature (be it barcode reading, excel sheet processing, pdf generation, etc.) is more often than not available as a PHP module. So instead of needing to implement new features, the work is more in the lines of combining chunks of modules into an application.

Now, any beginning PHP coder out there should take heart: The difference between a beginning PHP programmer and an expert PHP programmer is knowledge of what’s available. There are countless modules available out there, so for task X, which possibilities are available, and which is the best one, and is that good enough to use as such, or use and improve, or do we need to build from scratch? This is the kind of question that a beginning PHP programmer cannot answer. So the knowledge of the vocabulary of the language (libraries and modules) instead of the grammar (the language syntax) is the factor.

But back to the main topic. Enterprise level companies are starting to use PHP because

there is enterprise level support available and
the vast amount of freely available modules decreases time-to-market

Let’s focus on time-to-market. If you listen to the podcast, you’ll hear that time-to-market is for many companies a mission-critical factor. If their customer base needs a new feature in the services that they provide and if they cannot provide it quickly, the customers will find another service provider. So getting that new feature out there in days, instead of weeks, is of the utmost importance.

Now enter Microsoft. What made Microsoft big was that their QDOS that Bill maneuvered as the base OS for IBM PCs was a disruptive innovation – it wasn’t as good as the competition, but it was good enough. The strength of Microsoft back in 1980 was that it was small, maneuverable, and fast. Unlike the bulky, slow IBM.

What’s the situation now? It took them 5 years to deliver a new version of Internet Explorer. What happened in the mean time? They lost their customer base. The market share of IE dropped from 95% to 60%. Why? Because they weren’t able to provide the new features that the competition (Firefox and Opera) were able to roll out, and the customers started switching to something else.

It’s taken them too many years to get the next release of Windows out. Vista is now coming, but it’s too little, too late. It’s main new features seem to be doubled hardware requirements. The “new UI innovations” have been done by Apple in Mac OS X several years ago. The glossy new graphical excellence is already done in Linux with its 3D-accelerated windowing managers. Their new revolutionary file system got bumped off, while the Linux community has developed several of them. Their new security features are still lagging behind what is available for Linux.

And what’s the situation now? On the server side Linux is growing its supremacy. On the client side Linux is gaining slowly but surely. Many national governments are switching from Windows to Linux, from MS Office to OpenOffice.org, from IE to Firefox. Why? Because the latter alternative is better, due to pricing, licencing, openness, and – let’s not forget – faster time-to-market. The open alternatives release new versions regularly, usually several times a year, versus Microsoft’s 3-5 year release cycle. The open alternatives release patches in days, not in months. The open alternatives release critical security fixes in a matter of hours, not every 2-4 weeks.

Agility, maneuverability, reaction time to customer demands, and willingness to react are key factors for businesses for keeping their customer base. Microsoft is doing none of these and losing badly. Based on the blog post I mentioned in the beginning, the reason is also very clear – Microsoft has become the bloated, bureaucratic, clumsy, slow monster that it originally vanquished by being lean, agile, and fast back in the 1980′s.

What’s left? Protection of their crumbling monopoly. As Lawrence Lessig has been telling me, it’s cost-efficient for a monopoly to spend all of its capital minus $1 in the protection of its monopoly. And apprently this is what Microsfsoft is planning. Lessig already several years ago reported that at Stanford Law School the “suck effect” is the sound they hear as Microsoft hires every patent lawyer they graduate. The stage is set for a huge patent war between Microsoft and the open source community, and the recent

The essence of web 2.0

Web 2.0 has many names and a lot of hype – social web, community web, interactive web, and what have you. Nick Gall boiled down the hype quite nicely in his OSCON keynote (see a summary by zdnet) which is listened to on IT conversations. Not exactly news to me, but Nick very nicely boiled down the essence of web 2.0:

It’s read-write, instead of read-only. OK, Tim had the POST method in his http protocol, and was meaning to make the second version of his browser read-write, but others started cloning his original browser and the read-write functionality was pretty much forgotten for a decade. Now with the help of the POST method and Ajax UI gimmicks, read-write is here to stay – wikis are becoming even wikier (faster) to use.
Links aren’t one-way, but symmetric. This is what trackbacks are all about – seeing the links from both directions.
After going global, the web is now extending to processes. So in addition to serving requests made by people, the web now can accomodate calls made by applications and processes (think of web services and xmlrpc). This allows the building of new services as mashups of existing services (like the all-too-popular Google Maps mashups).

What this means for software development? Use the hour-glass metaphor – wide base (build on or accept anything), narrow waist (do a simple thing), wide top (provide results in a generic way so others may take advantage of it). In practice:

Extend existing services using the hooks they provide via the web. Design your software so that is accepts generic standard formats (like xml, xmlrpc).
Do something valuable to the data your service has been given. Do only one thing at a time, so that the results can be reused after any phase. Simple is beatiful.
Provide hooks in your services so others can extend the results you’re producing. Provide the results using standard formats (like xml, xmlrpc).

Corrections to the Joel test of software development quality

I just listened to an interview of Joel Spolsky on It Conversations, and checked out his Joel Test. While Joel has good argumentation for his opinions, I think a different perspective is needed for a few of the steps in his test, especially concerning testing and user involvement.

Here’s my version of the Joel test. It starts with the same 12 steps (although modified more or less), but continues with a few additional steps that I consider important.

Do you use source control?
This is too obvious to go into detail – even a one man team needs source control. It gives you history traceability, undo, coordination of simultaneous work, and backups. I personally use it even for all of the documents that I write.
Do you have automatic builds? (was: Can you make a build in one step?)
The one step build that Joel wants is a good start, but I’d rather see an automatic build done every night, and a big fat red warning on the frontpage of the development site whenever something breaks.
Do you make daily builds?
If you can’t build the software every day, you won’t build it until you need to. That means a convergence period before releasing, which is in fact just fixing technical bugs that could have been fixed when you wrote the code. So build automatically, and daily. And make each developer build and verify his code before he commits to source control.
Do you use a ticket system? (was: Do you have a bug database?)
Again, an obvious necessity. In addition to bugs, tracking all enhancement and auxiliary tasks should be carried out in the same ticket system, especially if you’re doing distributed and/or dispersed development.
Do you prioritize bugs? (was: Do you fix bugs before writing new code?)
As Joel says, bugs shouldn’t be left lying around, since they’re getting more expensive to fix as time goes by. But a black-and-white rule of “fix all bugs before doing features” won’t work – most bugs can be tracked to one developer, who should be the one to fix it (since he’s most likely the most efficient on that bug). Others shouldn’t wait, but continue with other tasks. Related to this, if you do frequent releases, then you usually have a one day convergence period, where all the remaining bugs are squashed.
Do you have an up-to-date schedule?
No disagreement here. Having limits on what is done are needed. They discourage feature creep, for one. So timebox everything – two weeks between releases, for example.
Do you have a plan that you can change? (was: Do you have a spec?)
Joel wants a spec. I don’t. In the majority of development projects, the customer cannot exactly specify what he wants. Thus instead of a spec, use a format that the customer also understands, like user stories. The collection of accepted user stories is the spec. But it’s a spec that can be changed by the customer, and that is refined as needed. Of course, you need development practices that support a changing spec, like automated unit testing.
Do you provide developers with conductive working conditions? (was: Do programmers have quiet working conditions?)
Here I completely disagree with Joel. Most of the problems are best solved by more than one mind. The flow that Joel talks about isn’t necessarily an individual experience, but can even more easily be experienced by a pair or team of developers. Therefore: have all developers in a single room, preferrably facing the walls, with an open area in the center, so they can at any time turn around and talk to whomever. Of course, there are those people who will need 15 minutes to get their focus back on what they’re doing after being interrupted, as Joel says, but I wouldn’t want those people on my team.
Do you use appropriate tools? (was: Do you use the best tools money can buy?)
Not the best money can buy, as Joel says, but appropriate. There is no added value in getting the compile done in 5 seconds instead of a couple of minutes. Having time to relax your mind and getting some distance to the code generally improves the result. Plus it’s critical to have time to reflect on the work you’ve done. Waiting a few minutes for the compilation or the unit test suite to run is a good time for all this. Plus it makes the code that much better, since the developers actually need to think their code through instead of just trying quick fixes and seeing if the compiler likes it or not.
Do you do quality assurance? (was: Do you have testers?)
Not dedicated testers, as Joel says, but quality assurance. This can come in many forms, including dedicated testers, or by doing automated unit tests by the programmers themselves. Even Joel admits that good testers are hard to find and harder to keep, since testing is not good work. He argues that it’s still cheaper to use testers than have developers do testing, since testers have lower wages. I on the other hand argue that having developers write unit tests is cost-effective. Automated unit tests have several advantages: they make sure that any defect can only be created once (since once found, a test is written for it), they improve the quality of the code (not allowing laziness to cause bugs), and they allow you to respond to a changing spec by changing your architecture as needed. After the initial phase (after you have the first 50-100 tests done) the unit tests actually save developer time, instead of consuming it. Plus you don’t need as many testers as you otherwise would.
Do you only hire competent team members? (was: Do new candidates write code during their interview?)
Instead of just making the potential new recruits write code, as Joel suggests (which is an excellent idea), it’s also important to let the development team meet the candidates and see how the chemistry works. Since development is a team effort, it’s best to let the team have their say in who should be hired.
Do you do usability testing? (was: Do you do hallway usability testing?)
Joel’s suggestion of hallway testing is not enough, if the company is filled by developers. What you need are representatives of the focus group. No developer can say if a primary school teacher can understand a certain functionality, and few developers actually know the general usability guidelines that do exist. So using usability experts to iron out general usability issues, followed by a focus group test, where the vocabulary, approach, and priorities of the software can be tuned to the focus group, are necessary.
Do you do user-centric design?
One reason Joel doesn’t like XP is the need for an on-site customer. In Joel’s opinion customers can’t provide you with good specs – they either say the obvious, or ask for features that they really don’t need. This is where user-centric design comes to play. Instead of asking the customer what he wants, find out what the customer needs. This is not an easy task, and involves a number of practices, one of which is a representative of the customer, who has the authority to make decisions, and the expertise to find out things. This representative is not enough alone, of course. You need to do participatory design, for example.
Do you have a heterogonous team?
Unlike Joel claims, I don’t believe that a software developer can learn to understand the customer’s field in just a few hours. You need the customer’s expertise in some form. But you also need the expertise on the theoretical backgrounds and advanced technologies that are to be applied in development. It’s not enough to just have developers. You need user interface logic specialists, you need graphic designers, you need usability professionals, and most importantly instead of separate code drones and architects you need people who are excelled programmers, great architects, and that have some expertise in the field being worked on, all wrapped into a single human. Most of the failures in software development are due to miscommunication between the customer and the programmer. Misunderstandings are cut radically when you have more roles packed into a single mind. Not all of your developers need to have problem domain expertise, mind – it’s usually enough to have just one, because he can translate between customer-lingo and programmer-jargon.

In summary: This is just my experience of how people and code work. Joel’s test is an excellent resource for job seekers and managers, but in some aspects I disagreed so much that I had to write this response – Joel test as it is is biased away from some very good new practices that I consider a comptetitive advantage. Comments are welcome. And thanks to Joel for sharing his thoughts with us all.

The trend for good companies and valuable employees

On the 12th of September the pedagogical faculty of the University of Helsinki hosted a panel talk Siltamat (in finnish) where, among others, Esko Kilpi was talking about how the frontline companies in far east are conducting business. It was refreshing to see someone actually use hype words like “web 2.0″, “blog” and “wiki” in a meaningful way. Here’s a summary.

Instead of the static business models of the industrial era, the information age and globalization make everything dynamic and changing. This means that the relationship companies have with their customers, and with their employees, must be a learning relationship. The relationships must be evaluated and adapted constantly.

Because the problems tackled in the information age have already become too complex for individuals to handle, the unit that functions, learns, and is evaluated, is no longer an individual employee, but a group of employees, often called a team, group, or department. The traditional way of evaluating role based competences of people is no longer meaningful, since the relationship is dynamic and learning, and people will move from one role to another constantly. Replacing them are as adaptation and learning abilities, and evaluation more often than not happens through peer review.

Each unit (team, department) must communicate and collaborate. If each person just does his own job, the company is soon in trouble. Employess no longer need to learn everything that relates to their role, but rather they need to know where they can get help. The three things that an employee in a new role should find out are:

Who has done this before? Who can I ask?
What has been done before? What has it been based on?
Where is the best expertise?

In order for these answers to be available, employees and teams need to reflect on their work. And the organization must make reflection possible by giving people the time to do that. And reflection is meaningless unless things can be changed. This means that the conclusions of reflection should be fed back to the system, so that the ways of working can be improved based on the findings. The employees themselves thus must have the power to change the rules they work under.

With current technologies, reflection is most naturally done using personal blogs within the company. And instead of just writing, a lot can be podcasted – images of designs, or audio/video recordings of designers discussing a complex issue. The more popular a blog is, the more valuable information that individual is sharing with his colleagues, and the more valuable that individual is for the company.

The company itself should be presented in a wiki. Every employee can edit the wiki pages, and thus the ever-increasing knowledge (or intellectual capital) of the company is not stuck within the heads of employees, but is shared with everyone as best as possible. Any and all documents, people, and resources should be tagged. Not with keywords from a closed vocabulary, but actually tagged with freeform tags (folksonomies). Information cannot be categorised into a tree structure of folders anymore, since most of the complex information should be present in several places. The network hierarchy needed is most easily represented by tags.

Because of the learning nature of relationships and the constant changes in company realities, deep hierarchies of managers are no longer appropriate. Instead of forming permanent departments, employees should form short-lived unofficial teams, groups, or pairs across intraorganizational boundaries as needed (emergent resource allocation). This also means that there is no such thing as repeatable processes, since things change all the time. This makes many quality standards, such as the ISO 9000, meaningless.

Summary: people need to adapt, learn, and share; evaluation is done based on the contributions of the indivudal to the organization, often using peer-review; sharing is done using blogs and wikis; people are allowed to reflect on their work and rules of working are changed accordingly. All this gives the company more flexibility and provides an advantage in the current market, where the focus is moving from mass production to customized production, and companies need to adapt and accomodate changes in the market rapidly.

Distributed design and development using agile methods and Trac (XP2006 presentation)

I’m hosting a session at the XP2006 conference and here’s the material for that session.

Also, the title should probably talk about Dispersed, not distributed, since that’s what we’re doing (not just having teams in separate locations, but having team members in separate locations).

Getting Java plugin to Mozilla/Firefox on Debian

I needed to get the Java plugin to work with Mozilla Firefox on yet another Debian workstation. Here’s the (currently updated) instructions:

Get the latest Java Linux self-extracting file (not the RPM)
Become root: sudo -i
Make a folder for the Java environment: mkdir /usr/local/java.sun; cd /usr/local/java.sun (or wherever you want)
Extract the package: sh /path/to/downloaded/jre-whatever.bin – it will extract everything into a subdirectory in the current directory
Make a symlink to ease things: ln -s jre-whatever java.current
Change permissions: chmod -Rc go+rX .
Make symlink to Mozilla’s plugins folder:
- Personal install (only for your user account): Leave root and make the symlink into your personal mozilla preferences: ln -s /usr/local/java.sun/java.current/plugin/i386/ns7/libjavaplugin_oji.so ~/.mozilla/plugins/
- Global install (for all users): Continue as root and make the symlink into /usr/lib/mozilla-firefox/plugins, but be prepared to take care of that plugin after every Mozilla or Firefox update.

On evolution of life and IT businesses

Every now and then these strange connections between seemingly unrelated topics happen. This time it happened yesterday when I was at a Mobile seminar organized by Hetky, and one of the presenters mentioned that even though the IT bubble burst and left thousands of bankrupt companies in its wake, there were still some good companies that survived. And of course it’s not a surprise that the good companies survived. But the connection to the evolution of life happened because I had just finished reading The Science of Discworld by Terry Pratchett, Ian Stewart, and Jack Cohen. And here’s the connection:

The planet Earth is irregularly but repeatedly being hit by events that very nearly wipe out all life. But not quite. There’s bacteria in the bottoms of the oceans, and even 10 miles deep into the crust you find bacteria living on just rock silicates. The typical event is a large lump of rock that just hits our planet (doesn’t really matter where), causing a massive mega-tsunami that goes around the planet a few times, but – more importantly – the tremors it causes (that of course would destroy any buildings if there have been any at those times) converge on the other side of the planet, breaking the crust in an area about the size of India, causing massive vulcanic activity that will most likely burn the atmosphere, then cover everything in acid and dust, and finally cool the planet so that pretty much everything is covered with a mile or two of ice. Not many higher life forms survive a pummelling like that.

An event such as described above probably accounts for the changes in geological epocs. And, of course, only the fittest survice. Those that are able to adapt themselves to the rapidly changing environment. But the most important implication is that evolution itself would not happen if there were no catastrophies. The dinosaurs ruled for a hundred million years, and pretty much nothing happened in the way of evolution. Since dinosaurs worked, they stayed the same. Boring. But throw a spanner the size of Texas into the works, and things get interesting.

So while the bursting of the IT bubble caused a lot of people to lose a lot of money (or, more correctly: got some people rich with other peoples’ money), it also performed a necessary operation – a change of environment. And, to be more accurate, the bursting of the bubble was not the cause, but the result of people realizing that the much-hyped IT businesses weren’t as great as they tried to make you believe. And most of the companies got wiped out, and rightly so. The ones that survived were able to function in an environment without inflated expectations.

Another way of looking at this is that after any major change in the environment, there is always a new niche, which is pretty soon filled by a rich variety of creatures. After the dinosaurs became chalk, the small mammals started to stake their claim in the suddenly-free environment. And this variety of creatures probably expanded until the space was taken up, and then competition ensued again. And the winners are the species that are still going strong.

Likewise, when the IT business got going, it created a new, free niche, that needed to be filled. Many, many people and companies converged on this free space, and most were successful, since there was no competition – there was enough investor money for everyone. But when that excess money ran out, competition ensued. And the weak were pulverized.

As a post scriptum I have to mention another environment that will need adaptation in the foreseeable future – stock markets. Because public stock markets don’t really produce money, but rather just transfer it around (if someone earns money through investments, it’s always someone else’s money), they are basically a huge pyramid scheme – getting new people to join with their money, so the guys at the top of the pyramid (the top professional investors) can cash it for themselves. And this whole pyramid will come tumbling down in either of two cases: 1) people stop joining (as in the great depression in the USA in the 1920′s) because the don’t believe in the system anymore, or 2) there’s no more people left to join. So at the latest when everyone is on board, the system will simply break, because without newbie money flowing in, there’s nothing to be gained. Are you prepared for a no-growth economy? Or as everyone gets their money out as quickly as possible and the bubble bursts, and all the effects thereof?

Or are you ready for the next natural catastrophy, which most likely is the melting of the ice caps, melting of the methane crystal deposits in the bottoms of the sea, melting of the permanently frozen methane deposits in the tundras, and probably many other yet undiscovered mechanisms, which will feed each other and warm this planet significantly, raise the sea level by 10 meters, and change the ecological conditions everywhere. And in addition the ice caps will probably produce a few mega-tsunamis as they melt in continent-sized pieces sliding into the sea, destroying all coastal civilization. As most major cities are coastal, a tsunami + 10 meters of water means a lot of homeless people. As most nuclear power plants are coastal, it will also mean hundreds of deposits of hot radioactive fuel, without working coolant systems. This could happen – oh, tomorrow, for example. Are you ready for that? I’m not. This last vision of the future is pretty much what Risto Isomäki describes in his newest book, Sarasvatin Hiekkaa (see review) (only in Finnish, sorry).

Making money with open source

I had a conversation with a new media student, and was surprised to hear that the curriculum of the Medialab of the University of Art and Design of Helsinki does not include anything about business and open source.

So here’s the 101 of open source business models:

Provide something that has a demand: This applies to business in general, in all fields. Do something that has enough value for others, and make them aware of what you’re offering.

Bits are free: Charging for digital data doesn’t work, since most people consider bits to be free (as in beer). This means that you can’t make your business model about selling software packages, or selling digital content (like music, images, or whatever). Many companies of course try, and do so with mixed success. It is, however, a battle they’re losing, since more and more software and content is becoming free (as in beer and as in speech), so as customers find their needs satisfied with freer alternatives, they stop coming to you. Of course, it’s a very lucrative thought to just develop software once and then keep on selling it – free money, you may think. And yes, it is. This is what Microsoft is doing with its software. But now that the free alternatives are becoming good enough (a disruptive innovation), Microsoft’s business model is in trouble.

Nobody owns the software: Since the software is open source, no-one owns it. Well, of course someone has copyright on it (or parts of it), but being free/libre open source software, you (or anyone) has the right to make any changes to it (with the possible exception of the license and list of authors) and publish and distribute the changed version. This has some wide-ranging consequences, which give new possibilities for businesses.

Marketing by word-of-mouth: In addition or instead of traditional marketing ways, providers of valuable contributions around an open source product gain fame. This is why Linus Torvalds gets paid (quite well, I imagine) just for hacking the Linux kernel, even though much of what Linus does doesn’t directly benefit Linus’s employer. This is why open source gurus don’t need other jobs in addition to hacking the code and travelling around the world in conferences (and, again, getting paid quite nicely). The catch here is that they have shown that they know what they’re doing – by providing open and free stuff, that anyone can see. If they provided closed, commercial stuff, no-one would bother paying just to see whether the content is any good. But free content gets you a huge audience, and if you do a good job, everyone will see it. And suddenly the door is open to all those “expert” possibilities, like conference keynote speaking and consulting.

Services are always needed: While software may be free, people still need services around them. The traditional services are things like installation services, tech support, and maintenance. But open source (since you also have the source, and the license to change it) provides other possibilities as well:

Localization: Some customer may be ready to pay for you to provide a translation of the software’s user interface and/or the manual into their language. Of course, after the localization is complete, it will be available for anyone else for free. But whoever wants it the most needs to do it themselves, or pay for someone else to do it. That someone else could be you.
Documentation: Most open source projects don’t have very good documentation, but the customers need good documentation. Someone could make a business out of providing it. Of course, you don’t need to license your manual (if you’ve done it from scratch) as open, so you get to charge everyone who wants to use it. Or you could operate in the spirit of open content and license it under a Creative Commons license, meaning you get paid only once. There are other, fairer ways, of getting extra revenue for a good manual: you can print it as a book and sell that – it’s surprising how many people actually want a printed book in addition to a free online version. But maybe the best reason of putting all “finished bits” available for free is this: as a known producer of high quality content (software patches, documentation, whatever), you gain fame. And fame gets you places.
Training: Even printed manuals aren’t enough – most companies want training for their staff in using a new system. You need some fame to be considered a valid trainer (read: provide quality content that build up your fame as an expert on the system in question). Training is a good business, since even if the training material is freely available, the trainer is always needed.
Software development / consulting: If the customer need to integrate their new open system with other systems, or make major customizations to it, they need a consultant to their development team, or an entire software development team, to do the required modifications. This works brings very good revenue, but you need lots of fame to be considered a worthy partner.

Summary: It’s about the services, not the bits. Provide services around the software that the customers need. Take advantage of the freedoms that open source grants you: you’re not limited to just providing services around the software, but you can modify, localise, customize, and improve the software to fit your customers’ needs. Build up fame by putting everything you do openly available, and do only high-quality stuff. Leverage that fame as a free marketing tool to get even more opportunities to use your expertise in your business.

Finally, a nice example: www.openoffice.fi. It’s a Finnish company that was built around providing services around OpenOffice.org (OpenOffice in Finnish). They have a good domain so customers can find them. They provide manuals, FAQs, and a help desk. All manuals, templates, patches, and instructions that they’ve produced are openly available for anyone (which gives the company a lot of good karma in the eyes of all Finnish people who want to use OpenOffice in their homes), but commercial support with e-mail and phone help desks is also available, and that’s what’s producing the revenue. Many people are familiar with the company’s templates and manuals, including CEOs (and families of CEOs) of companies that are considering switching MS Office to OpenOffice.org. So when the switch becomes imminent, there’s a high probability that the company will at least consider OpenOffice.fi as a partner. Fame gives you business opportunities.