Apple's .Mac service -- commonly known as dotMac -- is a suite of online utilities integrated with OS X. It is wildly popular with Mac owners, but it costs $99 per year. That annual hit to the wallet prompted J. Kent Pepper to commence a bounty-driven contest to create a free, open source replacement: the notMac Challenge. And he has found a winner.
Pepper launched the challenge last December, following a debate with his uncle over whether a bounty system could produce a quality solution. High-profile, high-price inducement challenges like the Ansari X-Prize were proven successes, and Pepper postulated that same effect would work on smaller-scale issues as well.
At that point, he says, "my uncle challenged me to come up with my own. I thought about it for a while and realizing that dotMac would be a perfect test because it was an area with a small but passionate audience and the solution could be delivered by a single individual."
As Pepper saw it, the $99-a-year dotMac service charge was just high enough to be painful to frugal users, but not high enough to motivate individual programmers to write their own replacements. The collective need of the community would provide that motivation.
"One of the things that I find particularly useful about inducement prizes is their ability to identify participants that would otherwise not have been considered (or even located) through more traditional means. For a developer working in Silicon Valley, the value of the prize might not have been enough compensation, but inducement prizes open up participation to anyone around the world."
Putting your money where your mouth is
The notMac Challenge Web site took in PayPal contributions for the prize money, each of which were then matched one-for-one by Pepper's uncle. All told, the bounty raised $8,622 for the winning entry.
Pepper drew up a detailed list of requirements, including installation behavior and system compatibility, as well as which dotMac services needed to be recreated and which did not.
dotMac offers users online storage space, Web site and photo galleries, and secure remote backup and synchronization of user data like calendars and contacts. Those services are integrated directly with client-side OS X -- iDisk online storage, for example, works transparently with the local filesystem. But dotMac also offers server-side applications, such as IMAP email and Web-based calendar editing.
Pepper decided to narrow the notMac Challenge requirements to just those services integrated on the client-side. There are already numerous, free alternatives for IMAP and online calendars, after all, so there was no point in unnecessarily burdening contest entrants with duplicating them.
The rules also stipulated that all qualifying entries be subjected to a 21-day public review period. The first entry to pass muster would then claim the reward, and release the source code to the public.
And the winner is ...
Ben Spink submitted his code in September, and was declared the winner on October 1. By day, Spink is the developer of CrushFTP, a proprietary file transfer application. He incorporated a stripped-down version of CrushFTP into his winning entry in order to implement notMac's key WebDAV underpinnings. In accordance with the rules, once he was declared the winner he posted both the source code to his notMac implementation and the source code he used from CrushFTP.
In an unusual twist on the rules, Spink's entry did not, in fact, adhere to two of the contest requirements that involved modifying the OS X Finder's Go menu. Those requirements violated accepted OS X security practices, and Spink convinced Pepper that they were a bad idea. His notMac implementation does implement the same functionality, but does so within the app itself rather than in the Finder.
Spink's notMac packages now stand at version 1.1, available from SourceForge.net. The OS X package is a 7.4MB .DMG image, and contains the code to run both the server and client components. With one Mac set up as the notMac server, additional Macs need only the client package, which redirects the built-in dotMac services to the replacement server.
There is also a Linux package that allows you to set up the notMac server-side component on a Linux machine. Currently you cannot run a notMac server and client simultaneously on one Mac, so if you need to synchronize multiple Macs with the service, using a Linux server may be your best option.
Unfortunately, the Linux package lags behind its Mac counterpart in terms of usability and bug fixes. The app is Java-based, but while the Mac version includes a user-friendly launcher and detailed instructions, the Linux version has neither. The notMac Challenge forums include several threads on how to get the app up and running on Linux and even FreeBSD.
Spink does accept bug reports and feedback through the forum, and many of the corrections that warranted the 1.1 release originated there. But success stories about the process include altering some system configuration files and creating a Mac OS X-like directory structure.
You play the Steve
The easier way to get started is with a Mac-to-Mac setup. You must first set up a notMac server, then configure your client machines. After you have mounted the notMac .DMG disk image, double-click the notMac app; it will ask whether to do a client or a server install.
The server setup tool allows you to specify the IP address and port number under which to run. By default it uses port 443 for SSL encryption, but it does not automatically select your computer's correct IP address, so be sure to double-check. You can alter the default data storage directory if you wish (important if you anticipate large backups).
It is essential, though, to set up notMac user accounts for every user who will be accessing the system. On the notMac client machines, the usernames and passwords you set up on the server will take the place of the dotMac account details OS X expects. When you have set up accounts for all your users, click the Enable button to start the service, and you are through.
Setting up a client machine is simpler -- the setup tool asks only for the IP address and port of the server. When you click Enable, the client setup tool switches out Apple's dotMac server credentials for those of your replacement notMac server.
If the server is running and you are not blocking port 443, when you go to the dotMac System Preferences panel, you will see the reverse-color notMac logo in place of the original. You can sign in with your notMac account name and password and set up synchronization and iDisk access.
Some iLife applications, like iPhoto and iWeb, include built-in dotMac features, such as one-click publishing. Since these features involve assembling content on the client side, then uploading the result, they should work out-of-the-box with notMac as well. Bear in mind, though, that your iPhoto galleries will be accessible to the public only if your local notMac server is publicly reachable.
If your main concern is synchronization of address book and other data, running a LAN-based notMac server may suffice. If you choose to run your notMac server on a public IP address, you are theoretically exposing your system to risk, and Apple won't be there to help you if it goes up in smoke.
I have never been a paid dotMac subscriber so I cannot personally attest to how painlessly notMac works as a drop-in replacement. At the very least, though, it is an excellent way to leverage OS X's built-in synchronization framework.
As a multiple-computer user, I am keenly aware of how tricky data sync can be. Even if it is Mac-only, anything that makes part of the synchronization problem go away (and at zero cost) is welcome.
Furthermore, the success of the notMac Challenge as a contest is noteworthy. Pepper has proven his point: small-scale inducement prizes can work. In fact, they are probably more likely to work than large-scale contests, at least when the effort is community-driven.
Pepper confirms that there were multiple project teams working on solutions when Spink claimed the prize money. According to the contest rules, those teams are not obligated to release their work as open source software, since they did not win. But the fact that they exist proves that Spink's work was not a fluke -- there was real competition.
Now that this challenge has reached its successful conclusion, Pepper says he is giving thought to launching another. But he is also interested in developing a method for others to replicate the inducement prize contest on their own. "When the iPhone and AppleTV were released, a couple of people offered bounties of a few hundred dollars to develop certain hacks, and I think, since the solutions served the entire community, it would be great if others could've contributed to the prize."