Thanks for all your mail and comments about my article in the 24-Jul-06 issue of TidBITS. What with the comments on my article and Jason Snell's , we've been having discussions both with users who desperately want the collaborative editor we're proposing and with some developers who are potentially interested in writing it. That doesn't mean we don't want to hear from more developers; the more the merrier, and if someone were to start an open source project, I'm sure the extra coders would be welcome. However, we want to clear up a couple of common misconceptions that have arisen.
SubEthaEdit and Real-Time Tools -- First, lots of people have asked if we've considered , from The Coding Monkeys. Yes and no - we know all about SubEthaEdit and use it occasionally, but it's not at all suited for the kind of group collaboration we have in mind here for two main reasons:
We're testing a workaround for the saving issue by having the person who creates the document use an auto-save utility; currently we're trying GoldfishSoft's $20 shareware, and it would seem to fit the bill (although it's hard to say how it would work over time, given that the demo times out after 30 saves). It's also worth noting that the current version of SubEthaEdit itself is no longer free, but the notable changes between the free versions and the current SubEthaEdit 2.5 revolve around its capabilities as a text editor, not as a collaboration tool. Luckily, it turns out that you can still download  for free.
A few people pointed us toward from AquaMinds, but it too is a real-time tool, though with the added fillip that only one person can edit a particular shared notebook at a time. That eliminates the need for tracking multiple sets of changes simultaneously, but it also means that a collaborative editing team would have to store only a single document per notebook to avoid having one person lock everyone else out from all other documents in that notebook. NoteShare is definitely a 1.0 product, though it may evolve in useful ways given comments made by AquaMinds about future versions possibly allowing multiple simultaneous editors of a single notebook and providing versioning capabilities.
Text Creation, Not Publishing -- Second, a number of people aren't quite realizing where in the publishing process our proposed GroupEdit exists. In a professional publishing environment, text is written by an author, is edited and commented upon by one or more editors, goes back to the author, returns to a primary editor, goes to a copy editor/proofreader, and only at the very end of the process is sent to print publishing software and/or a Web content management system.
In most Internet publishing scenarios - particularly weblog and wiki approaches - collaboration happens at the very end of this process. Weblog entries only generate comments and links once they're posted, and wiki entries are available for modification only after they've been published for the first time. That's because weblogs evolved from the personal publishing paradigm, and although wikis have long been group-oriented, an entry in a public wiki like Wikipedia is available for public collaboration from the very moment it is created, not once it has been "published" officially.
So what we're looking for in GroupEdit is a tool that supports the pre-publishing process, long before the public ever sees the end result. We don't want a sausage, we want a sausage stuffer. And yes, the back-and-forth that results in a well-written, well-edited, thoroughly proofed publication is a case of sausage making - it isn't always pretty, and it's not something that most publications want exposed to readers. Although I haven't been deeply involved in Wikipedia, my impression is that the manufacturing of a controversial Wikipedia entry reveals quite a bit of the sausage making, and while that may be fine for Wikipedia, it's not something most publications want to do.
I say all this as a way of explaining the more basic reason why tools that enable Web publishing, like weblog utilities, wikis, and even programs like Macromedia Contribute, never quite provide what we're looking for. All of them are tweaked to support that final aspect of the publishing process, rather than the early steps when a document is moving back and forth rapidly (and the more rapidly the better, though current tools hamper quick transitions tremendously) between an author and one or more editors.
The program that comes the closest to meeting our needs is probably, which integrates with InDesign to enable writers to work more fluidly with text that's destined for InDesign layouts. Although InCopy would seem to have many of the basic features we want, it falls down in being focused primarily on integration with InDesign and on collaboration between writers and designers, not writers and editors. Plus, at $250 per copy, it's not something we or Macworld could afford to provide to freelance writers.
Return to the RFP -- Therefore I would once again encourage everyone to take a look at , both with an eye toward making comments that could help refine or enhance the proposal and toward alerting Macintosh developers who might be interested in working on such a project or who might even have code that would benefit from features along the lines of those we outline in the RFP. The comments and discussions that the RFP has spawned so far have been helpful and are exactly what we hoped it would bring out. We're looking forward to keeping the dialogue going and hopefully getting something along the lines of GroupEdit into development.