Sharing JavaScript Code in Webmin

I posted a while back on my personal blog about some UI enhancement work that I’ve been doing in Webmin using the ExtJS JavaScript toolkit. Several folks had questions about whether Webmin was getting a new “official” JavaScript toolkit (it has some ancient and ugly API calls to generate a few JavaScript helpers for things like field graying and validation and such, but they aint got that AJAX religion), and, if not, how one could add a JavaScript library to Webmin to cleanly share it across modules and themes.

So, the answer to the first question is that Webmin is not getting an “official” JavaScript toolkit at this time. Webmin has as one of its core goals that it can be used by anyone anywhere with any browser. AJAX and heavy JavaScript usage makes that goal far more complicated. For example, we consider it a serious bug if a blind user using a screen reader can’t use Webmin. That said, we also recognize that AJAX is the best way to handle huge classes of user interaction problems, and with our commercial offering we have a strong interest in having the best looking, and most pleasant to use, UI in the field. So, I’ve begun to build a “semi-official” Webmin module that contains ExtJS and some helper functions and classes. The first example usage of this will be our new TheJAX Virtualmin theme, and soon after a few new modules.

For the second question, I’d just like to show how I’ve created this new ExtJS module for Webmin, and how one can use it. It only takes a few minutes to wrap something up into a module, and since most AJAX frameworks are making use of good JavaScript design practices and using their own namespaces, you can actually mix and match without too much pain.

Hidden Modules

So, Webmin has a very powerful module system, that allows you to package code for easy distribution and installation. A Webmin module is simply a directory with some files in it. Only one file is mandatory to make the directory into a “module”:

So, we create a directory named extjs within the Webmin directory (/usr/libexec/webmin on my system), and make a file called with the following contents:

desc=ExtJS AJAX Toolkit

Here I’ve given it a name, and a short description, noted the version of Webmin it depends on, given it a version (I’m going to stat it at 0.1, though the contained ExtJS version is 2.0b), and set it to be hidden. The hidden option means that users won’t be able to see this module in the UI, but other modules can make calls to it. Later, if I decide to add configurable options to this library that I do want users to be able to see, I can make it visible and add an icon and a UI.

Now, I can start dropping in my files. I merely unzipped the ExtJS bundle, deleted the extraneous files, and dropped it into an ext directory within the module directory. That’s just to make it easy to update ExtJS components separately from the helper functions that I write in Perl in the top-level directory.

Helper Functions

So, the simplest thing to automate away is the inclusion of the script tags that load the library. So, I’ll create a header_text function in a file called (Webmin has a convention of calling function libraries, which looks like this:

do '../';
my $debug=''; # Set to '-debug' to use non-stripped library
# header_text()
# Text to load JavaScript and CSS for use of extjs
sub header_text {
  return <EOF;
<script src="/extjs/ext/adapter/ext/ext-base.js" type="text/javascript"></script>
<script src="/extjs/ext/ext-all.js" type="text/javascript"></script>
<link href="/extjs/ext/resources/css/ext-all.css" rel="stylesheet" type="text/css" />
<link href="/extjs/ext/resources/css/xtheme-$config%7B" rel="stylesheet" type="text/css" />

Here we pull in the Webmin core library, pull in the configuration for this module (which I’ll cover in a couple of days when I’ve completed the configuration code for this module), and build the function to return the bits of text we need to properly load ExtJS and its stylesheets.

Using It

Believe it or not, we’ve now got a library that can be used by other Webmin modules or by themes. Webmin has a foreign_require function that will pull libraries like this in under their own namespace. So, when I need to use ExtJS, I can do this:

foreign_require("extjs", "");
print extjs::header_text();

All done! In a few days I’ll be finished with the first full-featured version of this library, and will wrap it up for distribution, along with some proof-of-concept modules that show how to use a full-featured AJAX interface without breaking text-mode browsers and readers, among other things.

One config file to rule them all

Configuration files are a boring necessity in software development. Parsing existing configuration files is a necessary aspect of almost any systems automation task. I regularly need to read and write configuration files from different languages, as I have simple maintenance, startup, and installation scripts written in BASH, larger Webmin-related tools in Perl, and stuff related to our website written in PHP. Of course, there are some great configuration file parsers for Perl in CPAN, but if you need a highly portable script and you don’t want your user to have to know anything about CPAN, it makes sense to build your own.

Luckily, in all three of these languages, plus Ruby and Python (other favorites of mine), simple configuration files can be easy, if you choose the right format.

Start from the Least Common Denominator

The least capable language in this story, at least with regard to data structures, is probably BASH, so we’ll start by creating a configuration file that’s easy to use with BASH. The obvious choice is a file filled with simple variable assignments, like so:


# A comment
start_cmd=/etc/rc.d/init.d/httpd start
stop_cmd=/etc/rc.d/init.d/httpd stop
# A blank line too..
apply_cmd=/etc/rc.d/init.d/httpd restart
#  A comment with an=sign

This file is valid BASH syntax–you could run this directly with /bin/sh apache.config and it would return no errors (though it wouldn’t do anything, because the values are not exported, so they are only in scope for the split second it takes BASH to parse the file. Because it’s BASH syntax, empty lines are ignored, and any line that starts with a # is a comment and also ignored. Empty values are also legal, so we need to accommodate lines that have only a key and no value. Also because this is a valid BASH script, we can make use of these variables in our scripts easily by sourcing this file. In shell scripts this is done using the dot operator ( . ), like so:

. apache.config

After this, each of the values in the apache.config file are accessible by their names. There are some caveats that make this a less than ideal practice for anything more complicated than a small script. The variables pollute the namespace when pulled in this way. So, if you later wanted to use $apachectl_path as a variable for some other purpose, for example, you would overwrite the existing assignment, and cause possibly difficult to diagnose errors. BASH doesn’t have support for complex data structures, so there isn’t much we can do about this, without introducing quite a lot of complexity, so we’ll take our chances and keep our scripts short and simple.

Getting the values into a Perl data structure

While our configuration file is not valid Perl syntax, Perl still has plenty of tools for working with this kind of file. After all, Perl was born to pick up the ball where shell scripts fumbled (and eventually evolved into a hodge podge of every great, and some not so great, ideas in programming languages from the past couple of decades), so it’s natural that it would have the ability to do the same sorts of things as a shell script.

But, since our configuration file is not valid Perl syntax, we can’t simply call do apache.config; as we would to import another Perl script. We’ll have to parse it into a data structure (which is better programming practice, anyway, as mentioned above). One way to do this would be a while loop, like so:

my $file = "apache.config";
my %config;
open(CONFIG, "&lt; $file") or die "can't open $file: $!";
while () {
    s/#.*//; # Remove comments
    s/^\s+//; # Remove opening whitespace
    s/\s+$//;  # Remove closing whitespace
    next unless length;
    my ($key, $value) = split(/\s*=\s*/, $_, 2);
    $config{$key} = $value;
# Print it out
use Data::Dumper;
print Dumper(\%config);

Now, we can access the values in our configuration file from the %config hash, such as $config{‘apachectl_path’}. Another option, if you’re feeling particularly idiomatic, is to use map:

my $file = "apache.config";
open(CONFIG, "\&lt; $file") or die "can't open $file: $!";
my %config = map {
      s/#.*//; # Remove comments
      s/^\s+//; # Remove opening whitespace
      s/\s+$//;  # Remove closing whitespace
      m/(.*?)=(.*)/; }
# Print it out
use Data::Dumper;
print Dumper(\%config);

So, what’s the benefit to this latter example? Nothing major, it’s just another way to approach the problem. It’s a couple of lines shorter, but more importantly it has fewer temporary variables, which can be a source of errors in large programs. The multiple substitution regular expressions I’ve shown above in either example could be reduced to a single line, but I believe this is more readable, and according to the Perl documentation breaking the tests out into single tests is faster than having multiple possible tests in a single substitution. Some folks also find long regular expressions difficult to scan.

But, I only like Ruby!

OK, so you want to do it in Ruby. Ruby has a lot in common with Perl, so it’s actually pretty similar, though a bit more verbose. Ruby fans seem to discourage regular expressions, though it is a core part of the language and it has roughly the same regex capabilities as Perl, so I’ve only used one (I guess I could have gotten rid of it somehow…but I got tired of searching for the non-regex answer and punted):

config = {}
File.foreach("apache.config") do |line|
  # Skip comments and whitespace
  if (line[0] != ?# and line =~ /\S/ )
    i = line.index('=')
    if (i)
      config[line[0..i - 1].strip] = line[i + 1..-1].strip
      config[line] = ''
# Print it out
config.each do |key, value|
  print key + " = " + value
  print "\n"

Same end result as the Perl versions above: A config hash containing all of the elements in our configuration file.

What about those web applications written in PHP?

Two of the websites I maintain (, and this site) are written in PHP. One is a Joomla application with numerous extensions and custom modules and components, the other is a mildly customized WordPress site. In the case of, we’re developing a number of applications that have both Perl components for the back end work and PHP components for the web front end, so sharing configuration files can be useful. Webmin, conveniently enough, already uses shell variable key=value style configuration files, so everything we do is already in this format.

So, let’s see about getting these configuration files into a PHP data structure. PHP isn’t quite as rich as Perl in its data manipulation capabilities, but it did inherit quite a few of the same tools from Perl, so our solution in PHP looks pretty similar to the while loop version above, though it is a bit more verbose due to the keyword heavy nature of PHP (Perl is often accused of having too much syntax, and PHP has way too many keywords):

$lines = file($file);
$config = array();
foreach ($lines as $line_num=&gt;$line) {
  # Comment?
  if ( ! preg_match("/#.*/", $line) ) {
    # Contains non-whitespace?
    if ( preg_match("/\S/", $line) ) {
      list( $key, $value ) = explode( "=", trim( $line ), 2);
      $config[$key] = $value;
// Print it out

Hey, what about snake handlers?

Of course, it can also be done in Python. As with the Ruby implementation, I’m not certain this is the best way to do it, but it works on my test file.

import sys
config = {}
file_name = "apache.config"
config_file = open(file_name, 'r')
for line in config_file:
    # Get rid of \n
    line = line.rstrip()
    # Empty?
    if not line:
    # Comment?
    if line.startswith("#"):
    (name, value) = line.split("=")
    name = name.strip()
    config[name] = value
print config

Or, as dysmas suggested on Reddit, a more idiomatic version would be:

config = {}
file_name = "apache.config"
config_file= open(file_name)
for line in config_file:
    line = line.strip()
    if line and line[0] is not "#" and line[-1] is not "=":
        var,val = line.rsplit("=",1)
        config[var.strip()] = val.strip()
print config

So, now we’ve got a config associative array filled with all of our values in all of our favorite languages (except BASH, which gets straight variables). Assuming we use a common file locking mechanism, or always open them read only, we could even begin to use the same configuration files across our BASH, Perl, Ruby, Python, and PHP scripts independently but simultaneously.

What’s the point?

This isn’t just an academic exercise. The simple examples above make up the early start of a cross-language set of tools for systems management.

With these simple parsers, we can build tools that use the best language for the job, while still leveraging some interesting knowledge contained in Webmin’s configuration files (which are in this key=value format). Webmin supports dozens of Operating Systems and hundreds of services and configuration files, so the config files in a Webmin installation (usually found in /etc/webmin) contain a huge array of compatibility information that would take ages to gather. If you need to know how to stop or start Apache on Debian 4.0, or on Solaris, or on Red Hat Enterprise Linux, you’d have to check an installation of those systems or search the web or ask someone who has one of those systems handy. Or, you could check the Webmin configuration file, and get the same data for all of the Operating Systems Webmin supports. It’s a pretty valuable pile of data. Imagine writing a script for your own favorite OS, and then being able to hand it to anyone that happens to have Webmin installed, regardless of their OS and version. Or, if they don’t have Webmin installed, you could provide a template configuration file that they could fix for their OS and version, addressing both situations as simply as possible.

Not the only configuration file format

Of course, this isn’t the only configuration file format out there, or even the best. Python users really like INI files, and I can’t argue with them. When I was writing Perl and Python predominantly, I used the Config::INI::Simple module from CPAN and ConfigParser for Python so I could share configuration between my various software easily (I was generally writing a Webmin front end in Perl to a Python back end application). That worked great. So, I’m not arguing you ought to be using key=value configuration files for everything. But being able to read them makes a lot of portability data available to you for free.

Next time I’ll wrap a couple of these routines up into friendly libraries for easy use, and add some tests to be sure we’re doing what we think we’re doing.

The new face of Webmin

After much deliberation (a bloodbath!), Jamie, Kevin, and I (and a little help from some friends) have chosen a new logo for Webmin, from the seemingly infinite great options offered up by our recent logo contest at SitePoint. Without further ado, I present to you the new face of Webmin:

The figure represents the letters W and M, but there is also the additional symbolism of three Ms to represent Webmin, Usermin, and Virtualmin. We agonized quite a bit over leaving behind the spider web themed branding of the old logo, but in the end, decided that a web was simply meaningless in a modern context where everything is web-based. When Webmin began, almost nothing for system administration ran on the web, and it was the defining characteristic of Webmin. Jamie is still justifiably proud of being so far ahead of the curve on adopting the web-based paradigm, but felt it was time to move on. The future of Webmin is virtualization and grid computing, mobile devices, public APIs, clustering, and more. The web-based UI is merely one aspect of a large swath of interesting facets.

We’d like to thank all of the designers who took part in the contest. They were patient, enthusiastic, and really good. We came into the final round of judging with a dozen or more entries that at least two of us loved, and only after two days of debate and seeking advice from friends and family, did we finally come to a concensus on one that we could all love. We’re extremely excited about the new logo, and plan to roll it out to the website, and the default Webmin theme in the next few days. We’ll also be printing some T-shirts, as soon as I find someone good here in the Bay Area to make them for us.

Thanks also to Kevin Hale, of Particle Tree and Wufoo fame for being our celebrity judge and providing adult supervision during the contest. His magical designer-y ways kept us thoroughly on the right path. Jamie’s sister Lara Cameron
also loaned us her eyes and expertise.

See also

Webmin Logo Contest

Getting a great logo: Reducing the field

It’s just not a contest until you see a goatse

As I’ve mentioned here and here, we’re holding a logo contest for Webmin’s tenth anniversary. We’ve gotten a ton of fantastic entries, and we’re coming down to the final hours of the contest. We are feeling really good about quite a few of the entries, but today the entries finally achieved what all great contests should aspire to: an unintentional goatse troll.

The finest goatse logo troll of all time, of course, appeared during the BBC Olympic “Lisa Simpson doing something naughty” logo coverage (pay attention at about :29 on the clock). But, now we’ve got one of our very own:

I’m so proud.

See also: Article at the Register

Getting a great logo: reducing the field

We’re holding a logo contest over on SitePoint. We mentioned it in an article a few days ago and since then it has become the most popular contest running right now on the site! Awesome. That’s the good news. There’s also great news: The designers entering the contest are really good! There’s at least half a dozen designs that we’d be proud to call our logo, and at least a dozen of the designers are folks I would love to work with in the future. Hundreds of entries would do us no good if they all sucked, but these guys are doing really solid work.

We’re about 30 hours from the end of the contest, so I wanted to post a summary of the work so far, and offer some advice to the designers, as well as offer up our thought process on why we like the logos that we like, and a few for logos we want to like, but don’t, and why. This is, by no means, an exhaustive list. For that you’ll need to check out the contest itself and the feedback on each of the entries.

Our Judging Guidelines

These are the guiding principles in our decision making process. We don’t all agree on how they should be reflected in the end product, but we all agree that these are right for the Webmin logo. It helps to know, in advance, the general feel of the branding you want, as it makes it really easy to rule out some possibly great executions of ideas that don’t fit. I think this is one of the leading causes of a failed branding effort; if you don’t know what you want, you’ll almost certainly not get it. So here’s the guidelines we’re using in our judging and advice to the designers:

  • We’re an Open Source project, so super corporate looking logos probably aren’t right.
  • We’ll be printing T-shirts, so too much complexity is a negative. Costs more to print, and looks stupid when screen-printed. It also leads to a weaker brand image…takes a long time to remember a really complex logo, but a simple one can stick on first or second viewing.
  • Colors aren’t set in stone. We’ll have the SVG vector version, and can change the colors, as needed. Though poor color choices might indicate a lack of skill on the part of the designer, and we might be wasting our time trying to guide them towards perfection if the logo has problems other than color. I’ve noticed some of the designers take advice much better than others. Some of these folks are pros, while others are well-meaning amateurs, and one of the things that separates the pros from the amateurs is an uncanny ability to read my mind. We aren’t going to miss out on a great logo just because it is by an amateur, but we’re also going to choose a perfect execution of a good idea over a mediocre execution of a great idea.
  • Be gentle, and have fun. We’re encouraging everyone to get involved, so we’ve got a few entries that are, frankly, not great. You can be harder on an entry that you really like a lot, because it’s easy to soften the criticism with praise. But, if one of us picks something that another hates, be gentle in vetoing it.
  • Jamie has veto power (we all do, but Jamie really does). It’s his baby, and he gets to say no to any logo, no matter how much one of the other judges loves something.

The Top Ten (give or take a few)

This is a bunch of logos that Jamie or I loved. Kevin is reserving judgment until the end, so we’ll have to wait for the professional opinions, but here’s where we stand, right now. This is definitely not an exhaustive list of the good to great logos in the contest, but it’s the ones that we picked out as being our favorites. Some of these won’t actually be going into the final round, due to a veto by Jamie or I, but these are all great by either my estimation or Jamie’s, so they’re worth commenting on.

Modern stylized spider web by vjeko

I like everything about this one. The spider web is clearly a spider web, it feels kinda like the Pentagon of spider webs: a place where Serious Internet Business takes place. The font is fun and the colors are soothing and modern. It scales small and large with no loss of impact and handles limited colors like a champ. Jamie also likes this logo. He’s unsure of hanging on to the spider or spider web branding of the old Webmin logo, so many of my favorites are in limbo (most of my favorites are spider related). But the strength of this logo won Jamie over, and he’d be happy with this concept.

vjeko deserves special mention for poking fun at me with this variant that adds a fitting tagline:

Fat, friendly spider by Haetro

I love this spider! Every time I see it, I like it more. It’s got real personality, and with only one color. It looks great in any color, and even with fonts I don’t care for, like the one in this particular instance. Some of the other variants of this logo have better fonts, but miss out on the purity of this one. I like the single color, and I like the square spider icon better than the later instances that round the spider or add more colors to the Webmin text (though other instances do have better fonts). Haetro has a great sense of style and a minimalist approach that I find very appealing.

Unfortunately for me, and for this design, Jamie vetoed it. The white space is pretty deeply offensive to him, and when scaled up he finds the spider frightening (I can see that…the eyes get really scary when he’s big). That said, Haetro is among the best designers in this contest, and I hate that none of his entries will make it to the final round. So, an interesting lesson to learn from this is that perhaps some of the most compelling images can also be the most off-putting. I asked around about this one, and it’s a very polarizing logo, you either love it or hate it.

Solid Webmin surrounding racks full of servers by RetroMetro Designs/Steve

This one is out of left field, and that’s a big part of why I like it. It’s unlike any other entry, so far, and gets bonus points for that originality. The feel I get from the green blocks in the center is clearly “look at these modern server racks filled with systems doing Serious Internet Business”. And the big fat WEBMIN sitting on either side makes it real clear who’s in charge. It’s simple, clean, clearly relevant, reduces nicely, and looks good. Steve’s entry prior to this one is really nice, too, and in fact, Jamie likes it better. Steve has done some revisions of that idea, which Jamie and I both like better, so it may find its way into the final round.

Interestingly, while Jamie and I both like Steve’s sense of style, we diverged on which of his designs we like best. But, at least one of Steve’s entries will be in the final round.

Give me a “W”, Give me an “M”, What does that spell? Spider! by highendprofile

Awesome execution on the idea of a spider built from the letters W and M. This is a gorgeous illustration. I wasn’t so sure about highendprofile’s skills based on his first entry, which was a nice idea but not very well executed, but this spider immediately blew me away. Beautiful execution and the spider is among the best illustrations in the contest. I don’t love the font on this one–it’s a bit tall and thin, but the colors are nice, and the spider is what draws the eye, so even with a not quite right font, I really like this logo.

This is another of the spider-based logos that has gotten the axe by Jamie. In this case, the cuteness that I love is a turnoff for Jamie. It won’t, unfortunately, make it into the final round, but highendprofile is a great designer, and I wish we had another idea or two from him in the contest.

Ooh, shiny spider makes me happy, by demonhale

What a champ. Give demonhale an idea and he runs it all the way in. This is a great spider illustration. Cute and shiny, very modern, very friendly. The font looks spidery, and the whole thing just screams “New Technology!” Great color choice, but color isn’t necessary for this one to look good. I like that the spider is hanging by a thread…perhaps going some place new. And, who doesn’t love shiny things?

Jamie, surprisingly, did not veto this spider. It’s shiny and serious enough to pass the “is it too cute?” muster, and it’s also a really simple design. The colors are subdued and the execution is clean. So, shiny spider is going to the final round.

Webmin is like a box or a building block, by joswan

This is another nice idea, that breaks from the old spider web and spider tradition. A box built from the letters W and M, with a nice solid font and cool colors. It’s quite pleasant to look at, and has some relevance for what Webmin does. Boxes don’t have a lot of personality…but it looks good nonetheless. It degrades nicely, and makes for a good favicon and icon version.

Jamie doesn’t love the colors here, and I have to agree. Orange and blue have a feel that is distinctly non-high tech. But joswan is an excellent designer, and does really nice work, so we can probably chase him into getting the colors right.

The fleur de Webmin, by ulahts

This designer has submitted nothing but great entries, but this is my favorite. The WM here is subtle and pleasant, the Webmin is bold and distinctive in red and gray. Nothing says Serious Internet Business like some sturdy red text. A stylized WM doesn’t mean much, but it sure looks nice as hell. It feels like it’s got the weight of Webmin’s ten year history behind it (ten years in Internet time is like 20 generations, so this is kinda like a family crest or family plaid to represent the Webmin family of products for the next 20 generations, or more). This is a very distinctive logo.

Jamie found this one a bit boring, but likes some of ulauts other work. We might end up pulling another of his logos into the final round, instead of this one.

Life saving technology, by dumples

This designer came out of left field with this one. It’s his only entry, but man did he ever knock it out of the park! Jamie and I both like this one a lot. The bubbly WM is just very pleasing and it feels familiar in a good way. I trust this logo. It feels kinda like a lifeguard. And, I can even kinda see one swimmer being helped to shore by another, now that I try to figure out why I think “lifeguard” when I look at it.

So, dumples, has swept in with one lone entry, and found himself as a shoe in for the final round. You don’t have to do lots of entries, if the one you run with is great, and this one is great.

Infinity needs system administrators, by fbarriac

Another one that Jamie and I agree on. We like the subtle use of color here, and the lovely dark gray Webmin in a round and friendly font. The infinity shape doesn’t mean much in reference to Webmin, except maybe that there are seemingly infinite things Webmin can do, but it looks good as hell doing it. I can picture this on great looking T-shirts (that cost an arm and a leg to print, because it requires shading to look this good), and it really shines on the web.

Webmin is sorta like a castle…or maybe a rook in a game of chess, by rust3dboy

Jamie likes the colors and sturdiness of this one. But it’s one that I vetoed. I’m not wholly aghast at the “WM as castle or rook” idea, but this execution feels like a logo for a BBS from the 80s. I think I broke several federal laws in order to call that BBS for free when I was thirteen. Jamie might have fond memories of calling that BBS, too, and that may be clouding his judgment. So, this one won’t be in the running, but another of rust3dboy’s logos will be, as we both really like most of his ideas…in particular the next one in the list.

Do you have a flag? by rust3dboy

In general, a great designer is one that can produce numerous really great logos, and rust3dboy has done that. We don’t all love all of them, but at least a couple of his entries are among our favorites. This is another good, abstract “it’s a W and an M!”, concept, implemented by a real pro. I like the color symmetry here, and the WM looks kinda like a flag (I’ve always thought people who have a Black Flag tattoo are super cool, and this looks kinda like the Black Flag logo). Nothing to complain about here.

Links in a chain, open source style, by BeeOsx

This is another the both Jamie and I really like. The colors are beautiful and professional. Very modern feel all around. We have no clue what those dots and lines are all about. It’s like they’re being dropped into a shredder or something, or maybe it’s a wood chipper and those are the chips flying out. I think my favorite thing about this one is actually the colors, and the really professional execution rather than the idea itself. It just looks really clean. BeeOsx is a really good designer with some interesting ideas, and I suspect at least this entry will be in the final round.

What else?

So those are the ones that bubbled to the top in the first round of discussions. Except for three or four vetoed entries those will definitely be considered in our final round of judging. There are a few that have come up since we had our discussion a couple of days ago that deserve special mention, as they are interesting new entries.

Swooshy wavy W and M, by babitaverma

This one is nice and subtle. I have no idea what the waves mean here, but they look awesome, and the color scheme is amazingly pretty. The font is a bit squat, but otherwise this is a great, simple, idea executed brilliantly. I’m going to unilaterally pull it into the final round of judging, but it may bounce right back out if Jamie or Kevin veto it.

This designer showed up after the first round of judging, so he missed out on getting feedback from Jamie, but I think at least two of his designs are final round calibre entries.

Butterflies, by babitaverma

Another by the same designer as the previous one. If we’re going to go with a new mascot, rather than a spider or web, butterflies would be a great choice. This illustration is lovely and simple, and looks great in all sorts of colors.

WM is a box, by RetroMetro Designs/Steve

This is the other entry by Steve that Jamie and I both liked, but had some reservations about during early discussion. Steve touched up the problem spots, and now it looks pretty darned good. Definitely a contender.

WM is another kind of box, by DaHoNK

This is another early entry that we had some reservations about, but the designer cleaned up those problems, and now it looks really good. This one takes such a different route on color scheme that it’s notable for that reason alone.

Tell us what you think!

What’s your favorite logo, so far? Any gems we’ve missed that you think ought to be make it into the final round? Let us know! This is the future of Webmin’s branding we’re talking about here.

Webmin at 10

Webmin is ten years old today. I recently took some of Jamie’s time away from Webmin to ask a few questions about where it’s been, the spin-off projects, and the goals achieved. More interesting, however, is what is Jamie working on now?

My questions are italicized, and Jamie’s responses are in the regular font.

When was the first release of Webmin?

I looked at the tar file for the 0.1 release of Webmin, and it was dated 3rd October 1997 .. it’s amazing that this was 10 years ago now! And even more so that I still have all the released tar files since then, despite numerous hard drive crashes and moves over the years.

I was working in Singapore at the time for a local company called National Computer Systems, and the idea for Webmin came out of a small set of CGI scripts that I did at work for managing DNS. I figured, if you can use a browser to manage a DNS server, why not the whole Unix system?

Fortunately I’d just won a Sun workstation in a Java programming contest, which had a (for the time) massive 64 megabytes of RAM and 2 GB of disk. So I had a pretty good machine at home to do development on. That’s why Solaris was the first operating system that Webmin supported, and why it is still a top-tier OS today.

Webmin version 0.1
Webmin version 0.1

Even a project as big as Webmin had to start somewhere. What did the first released version of Webmin do?

From looking at the modules in the original file, the first version managed only Cron, NFS shares, the BIND 4 DNS server, Inetd, bootup actions, mounted filesystems, Samba, and Unix users and groups. And it ran only on Solaris, Redhat Linux and Slackware.

The user interface in that first version looked pretty bad, but the basic design of Webmin was the same as it is now – a web server written in Perl and running as root, which then ran various CGI scripts. A big part of the work was writing that webserver, as Apache refused to run as root and setting up suexec or setuid root CGI scripts was too tricky to do in software that other people would be installing.

Why did you write Webmin?

Back in university when I first started using the first graphical web browser (Mosaic), it became apparent that the browser was a great interface for applications. Users didn’t have to install anything – just open a URL, and the app was there.

Of course this seems totally normal now, but back in the day almost all graphical applications were programs that you’d have to install and run .. and developing them was a lot of work, especially if you wanted to write something that many people could access at once, or which could be used remotely. So the web to me looked like a much easier platform for many types of applications – the first significant one that I wrote was an interface to the university library catalog, which until then could only be queried using an arcane command-line interface.

Shortly after graduating I was working as a sysadmin and software developer, and was getting a lot of requests to make updates to the company’s DNS domain. In those days, the only way to do this was to telnet into the DNS server as root, and edit a configuration file using the vi editor. This wasn’t something that a non-admin could be trusted to do, as one typo could wipe out the whole DNS domain.

So the natural solution to this problem was a web-based application for DNS management. This would protect users from themselves, save me time spent handling trivial sysadmin tasks, and only give users the rights to make changes to the settings related to DNS. This is what effectively grew into Webmin.

Webmin gets graphic
Webmin gets graphic

Webmin, Usermin, and Virtualmin now contain over 400 thousand lines of code, according to SLOCCount. Any idea how many lines of code were in the first public release of Webmin?

Lucky I still have that original tar file – it contained 17530 lines of code.

With over 8 million downloads, and over two million new downloads every year, Webmin is popular. Does popularity matter to you?

Not really – and even though Webmin has a lot of users, very few of them could name the author, so hardly any of the people I meet know that ‘Jamie Cameron’ was it’s developer.

Still, it is nice to know that something I’ve written has been so widely used.

Web-based system administration was a new concept when the first public release of Webmin occurred. It seems like a no-brainer now, but dozens of competing projects that ran on the console or X have come and gone. Was there a blinding flash of insight, a particular requirement in the original version, or did you just accidentally stumble into building a web-based tool that could stand the test of time?

I think the web interface was the key – other tools like Linuxconf, YaST and Redhat’s Gnome sysadmin applets replicated some of the functionality of Webmin over the years, but none of them made remote access easy. YaST and Redhat’s tools are X-only application, which means that they can be run only at the console of a Linux box, or from a Unix system on the same LAN. Linuxconf had multiple interfaces (web, X and command-line), but this abstraction meant that none of them were very good.

Even though there is a lot of talk about Linux on the desktop, it seems that the vast majority of Linux systems are servers managed remotely. So any administration tool has to work across the Internet, and a browser-based interface is perfect for that.

Another plus that Webmin had over competitors was its support for multiple operating systems and Linux distributions. A huge amount of work has gone into providing the same basic user interface and functions regardless of whether it is installed on Fedora 7, Solaris 2.5 or Mac OS X, even though those systems all use different configuration file formats and locations under the hood.

Thoroughly Modern Minnie

Thoroughly modern Minnie

There have been numerous major milestones in Webmin over the years: advanced ACLs, branching Usermin for user-level tasks like webmail, branching Virtualmin for virtual hosting management, conversion to a modular and theme-able UI library, and a dozen or so new modules each year. What’s the next big project in Webmin? Do you plan very far ahead?

The next big thing I am working on is called VM2 (Virtualmin Machine Manager), which is a Webmin module for managing Xen domains, VServers, Solaris Zones and Amazon EC2 instances. From a single control panel you’ll be able to manage multiple host systems, each of which can in turn run multiple virtual systems.

Initially at least this will be a commercial application, targeted at the hosting market – it will be tied closely into Virtualmin, and allow virtual servers to be managed across multiple systems. I feel there is a huge demand and market for this kind of software, as hosting companies are moving more towards virtualization now that Xen is well supported in the Linux kernel, and shipped by several Linux distribution vendors.

On the Webmin core side, the biggest task is user interface cleanups and consistency improvements, which involves re-writing many of those 400k lines of code. Also on the cards is better LDAP integration in the Postfix and SpamAssassin modules, better support for ClamAV, and perhaps a module for managing an LDAP database server.

Speaking of architectural changes, Webmin is predominantly a Perl application. Have there been any particularly painful transitions over the years, either due to changes in Perl or changes in your own design of Webmin?

Not really – Perl has been very good at backwards compatability, and I can remember only one case where some change in Perl itself broke Webmin. That was when they switched to UTF-8 mode by default when reading files, which broke my code that read binary files like images.

The biggest recent architectural change in Webmin was an update that replaced all code which wrote to files with wrapper functions that checked if all writes succeeded, and only replaced the target file with a complete new version if everything went OK. This was a lot of work due to the vast number of places in Webmin where files are written, but was worth it to protect the user againsts situations where critical files like /etc/passwd are half-written due to the system running out disk space!

Any thoughts on Perl 6?

I’m reserving my judgements until it actually gets released! That said, Webmin doesn’t really push Perl 5 to its limits, so hopefully it will run fine under the final version of Perl 6.

Webmin does a lot. It’s functionality encompasses that of dozens of single-purpose tools, often providing more functionality than the single-purpose counter-part. What Webmin feature do you think people ought to know about that doesn’t get talked about much?

I think the MySQL and PostgreSQL modules are the best examples of this, as they have pretty much all the functionality of phpMyAdmin and phpPgAdmin, yet phpMyAdmin is much better known as a MySQL management tool. In fact, it some areas Webmin can do more than phpMyAdmin, such as shutting down and starting up MySQL, and editing the /etc/my.cnf file.

What area of systems management do you find most interesting right now?

Virtualization, in particular using Xen. I’m really impressed with what it can do, and how many virtual systems you can host on a decent box. Solaris Zones are an impressive virtualization system as well, although they operate at a different level.

Other than your own software, what is your favorite product or online service for system administration tasks?

Definitely Amazon’s EC2 and S3 services. EC2 in particular is invaluable, as I can use it to create new virtual systems running a variety of Linux distributions for testing purposes. The alternative is to have a rack of machines of my own for testing, which would be far more expensive and a take up a lot more space.

EC2 is pretty good if you are looking to set up a webserver quickly, as you can provision a new instance in minutes using Amazon’s command-line tools, or an application like VM2. I know several startups that are using EC2 to host their web services, as it is cheaper and more flexible than renting or buying a real dedicated server at a colocation facility. And if you design your application right so that it can scale across multiple machines, you can easily bring up new EC2 instances.

Now if only they would take it out of beta!

Analysis and Reporting of System Data Part 1

There are a few basic elements to maintaining and administering systems: configuration, software management, data integrity and availability, and monitoring and reporting. This article introduces a number of tools for the last of those components, as well as presents some simple ways to create custom tools to report on data specific to your environment. There are dozens of great Open Source tools for gathering and presenting data, and so this series merely scratches the surface, but it provides a good introduction to some of the major system data analysis problems and presents some solutions.

Before trouble starts

Who, What, When, Where, Why and How

The six W’s (yeah, I’m not sure why “how” is one of the Ws, either) of reporting also apply to systems data. You want to know:

Who has been interacting with your server and services.

What they did.

When they did it, so you can determine if something they did is related to problems on the system.

Where they were coming from, just in case they aren’t who they claim to be.

Why? OK, so systems data probably can’t tell you why someone did something. You’ll have to ask them. But, with the right tools you’ll know who to ask and what to ask them, if anything funny does happen on your systems.

And, how any problems came about, so you can prevent them in the future. In short, the goal of all of this analysis and reporting on systems data is to keep your sysadmin house in order.

Oops.  Something went wrong.

The Basics

In the spirit of starting from first principles, we’ll begin this little exercise with the rudimentary tools that every system administrator ought to know a bit about: grep and tail.

While there are lots of automatic tools that provide graphs and charts and doohickeys that you can click or drag or hover over for hours of fun, odds are very good that some day, you’ll need to find out something very specific about a service on your system. Do you really want to schlep all over the Internet looking for just the right log analysis tool to find out whether that important message your boss sent to your companies biggest client was actually delivered? Of course not! Your boss is breathing down your neck right now. This is a job for grep!

grep is a search tool. It finds lines in a text file that match a regular expression1 and prints it to STDOUT. Like all UNIX command line tools, it can easily be combined with other tools for maximum awesomeness. So, let’s see grep in action, eh?

Find the boss’ email to Your boss ( sent it out yesterday and he still hasn’t gotten a reply!

grep "to=<>" /var/log/maillog</>

Assuming your boss actually sent the message, this will print out something along the lines of:

Sep 24 23:04:52 www postfix/smtp[3208]: 93498290E97: to=, relay=none, delay=42281, 
status=deferred (connect to[]: Connection timed out)

Aha! The mail server isn’t responding. The message didn’t go through yet, but it’s not our fault! Ass covered. Rest easy and reward yourself with another one of those delicious cupcakes that cute secretary brought in this morning.

Just when you begin to think the rest of your day is going to be easy, in comes the web designer. She’s thoroughly in a panic because one of her off-shore contractors got the syntax wrong in an .htaccess file and exposed a directory filled with sensitive files. It’s now been fixed, but she needs to know if anyone outside of the company accessed those files during the couple of days while they were exposed. Hmmm…sounds like another job for grep. But, we need to find entries that don’t match a particular pattern. We’ll use the “-v” option to negate the pattern.

grep -v ^192\.168\.1\. /var/log/httpd/access_log

This assumes 192.168.1. matches our local company subnet. The “^” indicates that the pattern should appear at the beginning of a line, which in the Apache common log format is where the client IP appears. Because grep uses regular expressions, and the period “.” has special meaning (it means “match any single character”), I’ve used a backslash “\” to escape the periods in the IP. It would match anyway, because a period matches “any single character”, but it could lead to false positives (or negatives in this case) because would match even though it isn’t in the network.

Next up, tail, a nifty little tool that I use many times every day. In its simplest form it simply displays the last 10 to 20 lines of a file. Because log files on a UNIX system always append new entries to the end of the file, this will always show the most recent items in the log. It’s very useful for interactively debugging problems.

Even better, modern tail implementations include the “-f”, or “–follow”, option, which prints the log entries as they are added. So, if I were debugging a particularly ornery mail problem, I might watch the maillog with “tail -f” while making requests. Of course, if I’m looking at the logs of a very active server, I might want to only see very specific entries. Say, I’m not sure why a particular mailbox isn’t receiving mail. We can combine tail and grep, like so:

tail -f /var/log/maillog | grep

Now, when I send an email to, I’ll see the related entries in the maillog (of course, in some cases, it won’t show all related entries…you might then need to pick out a message ID and grep the whole log based on that ID).

Next week, we’ll cover using Perl to extract useful information from your system and build time series graphs from the data.

See also

grep documentation

grep at Wikipedia

tail documentation

tail at Wikipedia

  1. Regular expressions, or regexes, are a syntax for advanced pattern matching. There is a de facto standard known as egrep, or extended grep, style regexes. This further evolved into Perl style regexes, which are used by many other languages and tools, via the pcre (Perl Compatible Regular Expressions) library. The Perl regex documentation is among the best on the subject. Jeffrey Friedl’s Mastering Regular Expressions takes the subject to the next level, and covers grep, egrep, sed, Perl, and much more. []

Open Source and Business: a Precarious Partnership

The business world has thoroughly embraced, by some definition of “embraced”, Free and Open Source software. No longer is it the sole province of the barefooted ideologues, MIT AI lab vagabonds, or bearded Berkeley beatniks. The biggest businesses in the world now have an Open Source deployment plan. Even Microsoft, the historical protagonist in the FOSS (Free and Open Source Software) story, has begun making vaguely conciliatory gestures towards the community alongside its traditional FUD (Fear, Uncertainty, and Doubt) and Embrace and Extend tactics, because their biggest customers have started demanding better interoperability, better standards compliance, and more transparency: features that are core beliefs of the FOSS world. So, big money has come to FOSS, but so far, the majority of big winners have been traditionally proprietary vendors adding FOSS solutions to their portfolio.

There are a few success stories from pure play OSS companies. Red Hat Software is one, Mozilla is another. But, I see a lot of great Open Source projects floundering with poor business plans and even poorer execution on those plans, wasting time that could have been spent developing and spending it instead on plugging the holes in the business. Most Open Source entrepreneurs start out with the goal of being able to work full-time on their project, but end up having even less time for the project and being broke, to boot. So, I’d like to offer some advice to budding FOSS entrepreneurs.

I’ve now built two businesses based on Open Source software, and I’ve learned a few things about what works and what doesn’t. Many of the “standard answer” solutions to the problem of making money on something that is available for free have died out over the years, as it’s become apparent, at least to the folks who’ve tried them, that they simply don’t work. I’d like to talk about some of those failed models, as well as some of the models that do seem to be working across a wide range of Open Source based businesses.

Service and Support (or, “what’s wrong with being a consultant?”)

This is the old standby for lots of Free Software and OSS purists. The argument goes, “don’t charge for the software, charge for the service and support that you offer”. Most of the people putting forth this as a viable business model haven’t actually built an Open Source based business based on this model. It is possible, but the scale on which you’ll be operating will never be very large.

Here’s why:

  1. Support is fundamentally a consulting business. To increase sales revenue you have to increase head count. Increasing head count is expensive, and your best employees will eventually start their own consulting business and likely compete with you. If you’re lucky, they’ll pick a niche that doesn’t overlap much with your core business.
  2. Expertise is hard to find. You may be the absolute master of the popular Open Source Frobnosticator project, and people come from all over the world to pay you for that expertise. But when it’s time to scale, see item 1 and contemplate finding or training someone to have your level of expertise with the Frobnosticator.
  3. The only advertising that works is word of mouth. You can’t easily have someone else sell your services for you. Most of the businesses (IBM, for instance) that might be well-placed to do so have their own services arm that they’d sell before they’d sell your service. Sure, IBM professional services doesn’t have any Frobnosticator experts on staff, but they’ll wing it and bill $200/hour while they figure it out. Thus, you have to pound the pavement to drum up your sales. Do not underestimate the cost of getting and keeping customers.

That said, if I can’t talk you out of building a service and support business around an Open Source project, there are a few things you can do to improve your chances and reduce the pain of the above problems.

Making the best of an Open Source service business

Pick a popular project. I mean a really popular project. Apache, MySQL, PostgreSQL, Linux for an interesting and growing niche (like mobile and embedded devices), one of the more popular web application frameworks, etc. By picking a popular project, you insure there are a lot of users. You also guarantee that you can find other experts to hire when it’s time to scale your business from a one-man consulting shop to a real business with employees.

Become an established expert on that project. Your name needs to be on the core developer list. If it isn’t, you’ll always be picking up scraps. If you can’t see a way to get yourself into this position, you don’t have a business.

Write a book about that project, or at least start a blog. The money for technical documentation isn’t very good, and you’ll spend a lot of time on it, but nothing says “expert” like “You can pick up a copy of my Frobnosticator book at Amazon, for more details on this subject”. If you’ve got a blog, people searching for help on a particular topic related to your area of expertise will find you. There is no better marketing than helping someone solve their problems.

Swell Technology: Joe’s case study OSS service business

Back in 1999, I started an Open Source service business called Swell Technology. I actually intended to build a product company, but the only aspect of the business that ever made money was service. So, it remained a service business until it closed up shop in December of 2005.

I accidentally picked a reasonably popular project, Squid, because I had used it and thought it was really cool. I accidentally became a core developer, because I submitted a few patches, helped out a lot on the mailing lists, did lots of hardcore testing, and made myself extremely useful to the other developers on the project. When one of them needed hardware, I sent it to them. When they needed to make some money, I hired them to build things for my company.

But, it failed to scale. Swell Technology was throughout its life a small business. It bought me a 350Z, and kept me in food and houses all those years. But, I took only two vacations during that time. I also managed to avoid doing a lot of things that I enjoyed, because I was always too busy with the company and its customers.

Hardware Bundling (or, “It’s an appliance!”)

This one is frightfully common. The basic premise is, “Open Source software is hard to install, hard to optimize, and hard to use, so I’ll put it on a box, and sell the box!” This is a horrible idea, and here’s why:

  1. You can’t afford to be in the hardware business.
  2. If you’re not already in the hardware business on a large scale, you really can’t afford to be in the hardware business. Dell does not leave room for companies selling a billion or more dollars worth of hardware each year (see Compaq)…how do you think you’re going to hold up doing $1mil, or even $10mil, a year in sales?
  3. Hardware is really a service business. When you sell an all-in-one solution and charge a premium for it, customers want 24 hour, top of the line, support. If you’re a one or two man shop, that means you’re answering the phone at 3 AM on a regular basis.
  4. You can’t charge enough. Your customers will talk specs, and the moment they do, they’re going to realize you’re selling equipment they can buy from Dell for a third the price. You’ll actually find that customers want to buy Dell hardware and pay you an hourly rate to install your products on it. The moment you accept such a deal, you have a pure service business, limited to the number of hours you can summon each day.
  5. Being in the hardware business means that you have one more thing to distract you from your core competency. You develop software, right? What are you doing futzing around with hard disks and RAM and processors all day? Every 12 months your hardware platform changes, by necessity. Do not underestimate the time expense of managing a hardware-based business.

Hardware bundling is the worst possible solution to the problem of “how do I make money with Open Source software”, but it crosses every OSS entrepreneurs mind at least once. I can’t think of a single pure-play OSS “appliance” company that has been an enduring success. Not one. The success stories I can think of have ended up selling proprietary products along-side their Open Source core (Barracuda), or pretending there is no Open Source core (InfoBlox). The really lucky ones sold out to a bigger vendor before things had a chance to go south (Cobalt). The ones that lasted a few years had time to burn through their capital and find themselves on the wrong side of the profit line. (Swell Technology, my first business, was one of those that lasted long enough to lose money on hardware sales…the hardware business was subsidized by service pretty much the whole time it was in operation.)

Plugins (or, “the coffee table is free, but the doilies are going to cost you”)

This one actually crosses the line from pure play OSS business model to a hybrid model, since the plugins aren’t Open Source. Not coincidentally, this is the point at which the business model begins to make sense as a scalable business where your core competency is what you do all day: write software. There are actually a few examples of this that work. MySQL AB doesn’t charge for the core database, but they charge for various extensions and management tools that work with the database. Because databases are a huge market and MySQL is the most popular relational database in the world, in number of installations, they can build a nice company, with employees and everything.

Of course, this is also the point at which Free Software zealots begin to squirm. It’s generally legal, as long as you comply with the relevant licenses, or hold the copyright on the software, so you aren’t restricted by the license. The majority of folks aren’t going to begrudge you making a living. But, there will be some pushback if you’re taking a historically Open Source project, and building proprietary products on top of, or alongside, it. Depending on the community, this pushback could be dramatic and ugly or peaceful and friendly.

Mambo is a fine example of handling this approach poorly. Very, very, poorly. I don’t know the whole story, but the end result was a loud and angry fork and exodus of developers to another project. So, here’s a few tips for how to avoid the OSS death penalty (a fork which takes away all of your best developers):

  1. If you aren’t a core developer of the project in question, stop here. You need to become more important to the project. You don’t have the clout to pull off a commercial venture based on this project. There is at least one shortcut to this clout: Hire one or more of the core developers, after making sure they’re on board with where you’re going. With Virtualmin, Inc. we have the original author of Webmin, Usermin and Virtualmin, as well as the second best known Webmin guy whose previous company actually funded the original Virtualmin development (that’d be me and Swell Technology). Even so, we got a bit of pushback on building proprietary products.
  2. Don’t screw with the license. If you don’t hold the entire copyright, you must abide by the license, religiously. Respect the license, and respect the developers, and the users will generally keep quiet. With Virtualmin, we actually hold all of the copyrights, but we are, nonetheless, respectful of the license of Webmin. Everything good we do in Webmin for Virtualmin, Inc. purposes, gets rolled out to the Open Source Webmin immediately.
  3. Make the core project better through your involvement. Be the best friend the users of the OSS project have. Be involved on the mailing lists or forums, make large contributions in the form of code or money, and make great things happen with the core project. Don’t be pushy about it, and make sure the big ideas you have aren’t at cross-purposes with the other developers on the project. Since we’ve started Virtualmin, Inc. we’ve rolled out a huge swath of usability and UI enhancements to Webmin, as well as several new plugins for Virtualmin GPL. Even though the Open Source users don’t get everything we build, they get more than they would have gotten had Virtualmin, Inc. not existed.

Freemium (or, “the grass is greener on the other side, but your wallet is a bit slimmer”)

This one is sort of an extension of the shareware model of yore, and it’s roughly the model we’ve chosen for Virtualmin, Inc. In this model, you’re distributing the majority of your software under an Open Source license, but for a few premium features, you charge money and protect them with a different license. So, you continue to enjoy the popularity that free software brings, while still knowing that there is a pretty good chance lots of people will pay for the extra features. Our Open Source core has millions of users, so we have a reasonably large pool of potential customers, though the percentage of converts is still quite low (Webmin is downloaded 2 million times per year, and we have 700 paying customers for Virtualmin), but increasing at a steady rate.

This is, perhaps, the riskiest of all Open Source business models, from the perspective of keeping your Open Source users happy. We have effectively forked our own software into two versions, and because the Open Source version of Virtualmin is under the GPL, it attracts the most vocal of OSS fanatics to its defense. We hold all of the copyrights to Virtualmin, and there have been no other significant contributors to the codebase besides me and Jamie, and so the gnashing of teeth didn’t last too long. But, we still rigorously follow the advice given in the section above for keeping our OSS users happy. We give away more than we hold for paying customers. This is probably a mistake in the short term, but we suspect it will pay off in the end, when the de facto solution to a wide array of systems management problems is based on our software.

Dual Licensing (or, “you don’t have to admit you’re using Free Software”)

This is, perhaps, the oldest Free Software business model, and thus one that has stood the test of time. The basic premise with this model is that there are lots of businesses out there that would like to make use of your code in their software, but they don’t want to release their own source code under a Free Software license. So, they buy a non-viral alternative license. SleepyCat, makers of the BerkeleyDB, ran on this model for many years. Likewise for the makers of the Ghostscript Postscript library.

We even tinkered with this model for a while with Virtualmin. Very early versions of Virtualmin exist in two other commercial products, licensed under traditional copyright terms, for which we made a few thousand dollars each. But, this model works best for libraries, because the software really needs to be invisible to the end users (otherwise, users figure out that it’s just some Free Software re-branded and complain about it). This is another case where your market must be huge for it to make sense. Databases and typography are both pretty big and are used behind the scenes in thousands of products.

Note that this model only applies to software that has a viral license, like the GPL. BSD-style licenses are already liberal enough to permit re-branding and distribution without source or without any particular restrictions. So, while our underlying software, Webmin, is used in hundreds of products, we don’t see any licensing revenue from this usage, because it is under a BSD license.

Hosted Applications (or, “Web 2.0!”)

This one is a beauty. You don’t have to worry about licenses, much. Your end users never need to know you’re using FOSS, though you can still get lots of goodwill by tossing out crumbs now and then. The vast majority of Web 2.0 companies (Facebook, MySpace, Digg, 37signals, etc.) fall into this category to one degree or another, as do the big search (Google) and internet media companies (Yahoo). In these cases FOSS is your lever, and some big problem is the world you want to move. It’s kind of like TV, in that you can offer premium services like HBO, or advertiser supported services like the big three networks.

I won’t go into too much detail about business models for web applications, as it is pretty well-covered ground, and I’ve never actually built a pure play web application business, so my knowledge is all anecdotal. But, there’s a lot to be said for hosted applications.

  1. You don’t have to worry about platform compatibility. At least 25% of my development time goes into making Virtualmin Professional run easily on several Operating Systems, versions and architectures. It’s a serious drain on productivity, and yet it’s a necessary expense.
  2. Bugfixes can roll out immediately. At Virtualmin, we manage update repositories for our software, so it’s easy to update to the latest versions…but we still find customers running versions over a year old. Having many versions in the field is another big drain on productivity, because you’re answering questions about bugs that have long since been fixed (sometimes I don’t even remember that it’s a bug that’s been fixed, so I end up helping a user troubleshoot the problem from scratch again, only to find at the end of it all that all they had to do was update to the latest version).
  3. Licensing is a hard problem. Selling software and protecting it from illicit use requires walking on eggshells. Your honest users (luckily most of them, in our field) will be offended if the license management gets in their way. Users who don’t want to pay will do nasty things to avoid it. One of our serious headaches is chargebacks due to fraudulent credit card purchases. Of course, if your hosted app business model involves credit card billing, you have this problem, too…but since the software isn’t installed elsewhere you can lock the account after the chargeback comes through and the user loses their data and the service. Our stick is much smaller: We shut down updates, and make the red license violation box show up on the front page of the software whenever they use it. We could be more harsh, but then we’d risk treating honest customers poorly in the event of problems contacting the licensing server, which we won’t do.

So, those are the obvious business models for Free and Open Source software. A couple of them are known to fail. A couple are known to be difficult and require a lot of luck and a lot of popularity. And a couple are proving themselves effective in a large number of cases. Which one is right for you and your favorite Open Source project, if any, is up to you to figure out.

See also

Getting Real A book by the founders of 37signals about starting a web application business on the cheap.

Paul Graham’s essays. Virtualmin, Inc. accepted funding from Paul’s company Y Combinator in 2007, and many of his essays inspired the business we’ve built over the past couple of years. We’re big fans.