Digger Solutions is an intranet application that takes a classic open-source marketing tack: give away a bunch of useful functionality, and hope to make some money by selling additional add-ons. The free part is useful enough that it just might work out that way.

The idea is simple: this is the sort of application that a small consulting company might use to manage its projects and time. It's implemented in classic ASP with an Access backend (scripts are available to convert the backend to SQL Server 7.0 or 2000 if you prefer). At the heart of the system are tracking pages for clients, projects, tasks, and timecards (hours applied to an individual task - you might have seen other systems call these timeslips). There's not full Gantt-chart project scheduling here, but there is plenty of room to plan future projects, as well as a good set of reports to tell you how you're doing.

There are also a bunch of other things that dress up the intranet: a shared calendar, company news, a discussion area, resource links, an employee directory, and a document repository, for example. You can create and update message logs for each client, and inspect both the work logs for clients and for employees. On a local server, it's all quite fast, and it seems to work as advertised. The source code is somewhat commented, and there's an administrator's manual with some basic documentation.

I was able to get IOS up and running quite quickly on my own server, poke around in the sample data, and enter my own. The few problems that I hit were in misconfiguration, and they were easily solved with the help of the support area on the Digger Solutions site.

So if you get all that for free, what do you need to pay for? The answer is that, although you can administer everything by manipulating the database directly, there are Admin Paks for things like news, calendar entries, and employees. These range in price from $19.99 to $99.99 (for a complete package that includes everything). There are also some skins to make IOS look nicer, though it's perfectly functional without them.

I was just thinking about writing something like this for a distributed development team that I'm involved with. Now I just may implement IOS instead. After all, reinventing wheels is not a great use of time.