Several months ago, I wrote in "Wanted: Better Document Collaboration System" about how we at TidBITS desperately need a better document collaboration system. It generated many suggestions from readers, and much additional thought on our part, but the final solution we arrived at, particularly after discussing the problem with Jason Snell, editorial director at Mac Publishing, was that the Macintosh world needs a program dedicated to collaborative editing.
First, a quick recap. In my previous article, I talked about how Near-Time's Flow did nearly everything we wanted, but had some problems and wasn't being actively developed by the company. I suggested that weblog editors like Ecto and MarsEdit in conjunction with a private weblog might offer what we need. And I discussed the pros and cons of using the Subversion version control system in conjunction with BBEdit. None of these ideas fit the bill. We simply can't rely on a program like Flow that lacks active support from its developer, and the Ecto/weblog approach proved clumsy and prone to data loss if one of us didn't do things exactly right. We're once again using the Subversion/BBEdit solution, even though it's awkward (requiring phone-based training from Matt, who knows more about it than the rest of us), because it's nearly unthinkable that data could be lost as the result of a mistake.
Other Suggestions -- And so, our search continued. Our clever and knowledgeable readers made some interesting suggestions, including three relatively comparable online word processors: Writeboard from 37signals; AdventNet's Zoho Writer; and Writely, which was just acquired by Google. All of these programs work, and work fairly well, but they don't take into account certain realities of the business world. First, they assume online access at all times, and as much as it's a nice idea that Internet access is ubiquitous, in today's world, we find ourselves in plenty of offline travel situations via bus, train, and plane, not to mention hotel rooms or airports that charge a pretty penny for access. Second, although they do an astonishing job of embedding a word processor inside a Web browser (at least some browsers; Writely and Zoho Writer don't work in Safari or OmniWeb), they don't begin to compete with real Macintosh word processors. It's impressive that the bear is dancing, but you shouldn't expect Swan Lake. Third, since they're hosted services, everyone who uses the program is at the mercy of the host. I'm extremely uncomfortable ceding control of something as essential as my writing environment to another company about which I know next to nothing. I worry about uptime issues, storing potentially sensitive documents, possibly unwanted upgrades, and long-term availability. All of those worries disappear - or at least become my problem - with something I can run on my own computers.
Another interesting suggestion that came from a number of readers was MediaWiki, a free wiki package originally created for Wikipedia and now in wide use elsewhere. Like other wikis, MediaWiki enables easy editing of a Web page, but where it diverges is in its excellent version comparison capabilities. Plus, there are extensions for the Mozilla Web browser that enable users to edit wiki pages in Mac editors, rather than in the highly constrained Web browser environment. However, as much as we could probably install MediaWiki under Mac OS X and try it out with an external editor, it still suffers from needing Internet access. Like the three online word processors, MediaWiki also treats document comparison as a task entirely separate from writing, so you can't see a comparison in the document in which you're working, as is possible in Microsoft Word.
Request for Proposal -- Despite the utility of these tools, they haven't been designed with the needs of a group of decentralized professional writers and editors in mind. Or more to the point, they haven't been designed by professional writers and editors who spend their lives immersed in creating and editing text in collaboration with others. These tools understand the basic concepts, but miss completely on key aspects of implementation - they see the forest, but miss the trees.
With that in mind, Jason Snell and I sat down and created an RFP - a request for proposal - that outlines exactly what we're looking for. It's not as detailed as a specification, of course, but it describes in broad strokes the kinds of features that organizations like TidBITS and Mac Publishing need. This is a real RFP - we're actively seeking proposals from Macintosh developers to create the application currently code-named GroupEdit. Being like Dilbert's customers, we would of course prefer a completely polished open source program for free, but we're willing to help design and test it to make sure it meets our needs, and we're even willing to pay some thousands of dollars to have this application created. Of course, should the developer wish to market it, that would be totally hunky-dory, and (without compromising our editorial integrity, of course), it's a pretty good bet that such an application would merit mention in at least TidBITS and Macworld. We believe this application has a broad audience, and that a real business could be created around it. Or it could become a poster child for an open source program with a fabulous interface and excellent documentation.
I won't recapitulate the entire RFP here, but I'd encourage everyone who's interested to take a look at it in QuickTopic Document Review, where you can leave comments and have side discussions about our proposal. If you're a serious developer and have a track record creating solid Mac software, drop me a line, and Jason and I will be happy to start more detailed discussions.