1998 was fun. I had left my position at a technology magazine because I wanted to do more in the industry than write about which backup program was the fastest. I wanted to get my hands dirty; I wanted a street-level view of the dotcom revolution. So among other things I offered to be the “feet in the Valley” for a friend who ran a small company based on the open-source version-control package CVS.

That led to a meeting with Ann Winblad, legendary head of the venture-capital firm Hummer Winblad. She listened politely as I stumblingly pitched CVS’ possible applications, for example to help law firms keep track of documentation changes. But in the end we bogged down on how anyone could make money with free software.

The next year, Red Hat had one of Wall Street’s most successful initial public offerings to date. Unlike most tech companies of the time — almost all of which were based on proprietary software — Red Hat is still in business, with over 3,000 employees and 2010 revenue of $750 million. Its success has spawned a universe of system integrators, related software vendors, and other partnerships resulting in untold millions more.

So clearly there was a way to make money with free software; in retrospect that seems obvious. But along with Red Hat’s success were many open-source companies that failed. Linuxcare was to be “the 800 number for Linux” but crashed spectacularly after burning through over $70 million in venture capital, including $8 million less than six months before closing its doors. (The current Linuxcare company isn’t the same beast.)

I’m not suggesting that Drupal companies could replicate Red Hat’s success by simply following their script: What worked in 1999 is irrelevant now. But some of the general lessons from that era remain true today.

• Have paying customers, with a broad view on what “customers” are.

  They could be businesses for whom you build sites, ad buyers who feed your Google AdSense account, other Drupal professionals who use your infrastructure services, or ordinary Janes who send you subscription money.

  Venture capital that drove the dotcom era embraced a “go big or go home” philosophy: VC-funded companies sought enormous growth and a quick payoff by projecting future customer revenues, even when there were few current customers. Funding sources have diversified somewhat, but in boom times it’s still tempting to focus on unrealistic “world domination” strategies. Yes, you can borrow money to grow. But beware projections that are based on anything other than your current skillset and customer base.

  As I write this, only a very small number of companies have publicly announced venture funding for Drupal projects, including Acquia; Commerce Guys; and SubHub, which is using Drupal to create “Subhub Lite”. (Dries wrote in December 2010 that he knows of “at least two other Drupal companies that are in the process of raising money from investors”.) Commerce Guys and SubHub are safe: They’re building on prior products, namely Ubercart and Subhub, and venture involvement in each is fairly low at around $1.5 million. Acquia is by far the biggest risk-taker, with $23.5 million of venture capital in play and an untested market. The company is tight-lipped about its earnings, but claims to have “[grown] by more than 400%” in 2010. Whether that’s enough remains to be seen.

• Grow through partnerships.

  American business histories like to lionize company founders as mavericks, from Henry Ford to Mark Zuckerberg. But the reality is that companies almost never grow by themselves. Ford teamed himself promiscuously with investors, advisors, and other mechanics, while Facebook partnered with (among others) Microsoft early in its history.

  As the community grows, partnerships continue to play an important role and are becoming more and more official. Again, Acquia is in the lead with over 250 partners in nine categories, although its definition of “partner” is somewhat different from how the word is used by consultancies: Acquia receives direct payments from some partners and provides services such as network monitoring, but doesn’t build sites itself. According to a spokesperson, the company “built our partner channel explicitly to drive revenue to our partners: We recommend partners whenever a client is looking for a website, and our training program is delivered around the world by partners.”

  Inspiration also comes from smaller partnerships. For example, Phase2 Technology and Mediacurrent brought their knowledge and funds together to produce the white paper, “Building Large-Scale Publishing Sites with Drupal”. Greg Knaddison reported that his development company Growing Venture Solutions partnered with design and marketing firm Boldium to deliver a more-complete package to their biggest recent client, California Closets. Working with other shops has been highly beneficial to GVS: Greg estimated that over 60% of the company’s revenue now comes from partnerships or referrals. Such project-based partnerships, even if minor, will show you who has resources that are complementary to yours. That knowledge will in turn lead to bigger partnerships, and victories you couldn’t achieve on your own.

• Be inventive about revenue models.

  This past January saw a debate about the rightness of a “Drupal app store” for modules. It brought out fierce opinions, in particular from module developers themselves. Some believed the financial incentive would inspire great work; others felt it would kill the free-module system.

  I think both sides are missing the point, much in the same way that America Online missed the point fifteen years ago. AOL thought its product — the “walled garden” — was a standalone item whose rights it wholly owned. The app store discussion likewise centers around modules as standalone items that their creators own. But in many cases, their real value is in the services they deliver from outside sources.

  Consider: The 8th-most popular module for Drupal 7 (Google Analytics) is an interface to a third-party service. So are the reCAPTCHA, Flickr, and Weather modules. These outside web services are where the money is.

  That’s the reasoning behind the Acquia Agent module that’s included (and enabled) in Acquia Drupal: It facilitates and advertises the company’s for-pay monitoring service. There are modules for MailChimp, AddToAny, YouTube... all are putting money into outside parties’ pockets, albeit indirectly.

  But those modules are worthless if those third-party services fail. On the other hand, some go further by adding value regardless of whether they interact with the (revenue-producing) third-party service. The Backup and Migrate module is a good example: By itself it’s a boon to Drupal system administrators. But creator Ronan Dowling is now developing NodeSquirrel, a commercial online backup service that could extend the Backup and Migrate module without reducing its original benefits.

Now, chances are you’re reading this because you’re an attendee of DrupalCon Chicago. The majority of DrupalCon Chicago attendees aren’t heads of large Drupal companies: They are, like me, sole practitioners or employees with Drupal-related jobs. As such it’s tempting to dismiss pronouncements about “partnerships” and “revenue” as irrelevant. I certainly would have if I’d read this article in the ’90s: I was working for bosses and getting paid for it, and that was enough.

But now I see that I missed out on a lot of opportunities by being so shortsighted. As a newspaper employee in 1992 I proposed going online (via AOL); what would my life have been like if I’d reached out to technology and marketing partners to make it happen? In 1995 I was part owner of an English-as-a-second-language school and wanted to be a pioneer for language instruction online. Would it have succeeded if I’d worked on a small, sellable product instead of dreaming of world domination?

As distant as those memories seem now, remember that someday we’ll look at 2011 as a point of beginning. Surrounded as we are by our community’s best and brightest, it’s easy to get lost in the details of Drupal’s current state. But Drupal is an enabling technology: It doesn’t create sustaining businesses by itself. Knowing how to use it will get you a paycheck today; seeing beyond its nuts and bolts will get you a paycheck in years to come.