Brad Hutchings, general partner of Hutchings Software, sent the following message to the ODF development community. Hutchings is looking to obtain control of the future of ODF development from Apple.

ODF Developers:

I have a proposal that will keep ODF viable for at least the next year. It makes several improvements to ODF, costs Apple nothing, costs you nothing, is doable by Hutchings Software (HS), is worth doing by HS, and won't be a drain on HS's resources. I'd appreciate your time reading and considering the proposal, and any suggestions, feedback, or discussion. It is important that Apple makes a good decision about what to do with ODF as soon as possible.

For a moment, let's work under the following assumptions:

1. Apple's tabling of OpenDoc and Cyberdog does not necessarily kill our currently shipping ODF-based products or require us to halt development of other OpenDoc parts. OpenDoc provides tremendous end-user value even on just the MacOS platform.
2. Development of parts with ODF needs to remain viable thru at least June, 1998.
3. ODFLibrary must have bugs fixed on an ongoing basis, but must remain under control of one entity to prevent all of our parts from breaking. Anarchy will kill ODF and that will kill OpenDoc. THIS IS THE MOST URGENT ISSUE WE ALL FACE!!!
4. 4ODF must remain buildable with the latest CW releases.
5. ODF for Windows is not complete and would be pointless to complete anyway, with IBM's recent OpenDoc announcements.
6. ODF must support 68K and PPC Macs.

Here is my proposed course of action. It is designed to cost ODF developers nothing while preserving our investments in OpenDoc and ODF and offering a growing OpenDoc customer base a greater selection of components.

Apple turns control and ownership of ODF over to Hutchings Software (HS), subject to the following conditions (to be worked out in further detail if necessary):

1. HS cannot sell ODF to a third party. HS grants no-fee licences to use ODF and improvements to any interested developer. Apple distributes future versions of ODF at the ODF web site and on developer CDs. HS is allowed to charge for duplication and shipping expenses from developers who don't want to wait for Apple or download from the web. HS is not allowed to charge or accept voluntary payment from other ODF developers for future improvements made to ODF.
2. HS is the only party that releases official updates to ODFLibrary. Developers shipping ODF-based products are required to ship the latest official release of ODFLibrary.
3. HS coordinates changes to the rest of the ODF framework. All ODF developers are expected, but not required, to help improve the framework.
4. Apple has an option to buy ODF back from HS for some specified amount, to be distributed among ODF developers who have helped to improve ODF in the meantime.
5. ODF part dialog boxes include message "©Apple Computer, Inc. and The ODF Consortium". No mention of HS is necessary.
6. There are no official release schedules for future reference versions of ODF. Sample parts and DU parts will not likely be maintained. Most documentation will not be updated. ODF will be issued "as-is". HS will not be legally or financially responsible for bugs unfixed or introduced.
7. Apple turns over source files, bug databases, documentation, etc. HS, so some sense can be made out of the whole project.

This isn't a proposal for HS to just grab the coolest framework in existence. I've also got some modest plans for improvement:

1. Integrate HS's "ODF Internet" improvements into ODF by May. I've got something that handles the progress broadcasters and CyberStream loading in separate threads. You will be able to turn an existing ODF 2/3 based part into a Cyberdog display part by overriding one method of your FW_CPart subclass. All your part does is read from a FW_CReadableStream, like your content classes most likely already do. I can provide a working demo and source code sample to anyone interested in evaluating the seriousness of this offer.
2. Strip out Windows code by July. We're Mac-only at this point. It would be nice if ODF code were a little easier to read and compiled a little faster. That _does not_ mean changing ODF API for things like graphics or anything else for that matter.
3. Release HS's "ClassGrinder" Java tool as part of ODF by July. This tool generates subclass files for important ODF classes, integrating lots of boilerplate code. It's like PartMaker Pro, except it does one class at a time. Also, it's very easy to write templates (".grind" files) for. I've got templates for part, content, frame, view, shape, and some custom classes.
4. With just a little bit of help from Metrowerks, convert ODF to Direct-To-SOM, and make it much easier to write part extensions. All MW has to do is support SOM modules, if I understand the current problem. I think if there is enough interest in further DTS development, MW can be convinced.
5. HS will create an "AppleScript" subsystem which encapsulates OSA support like in Rapid-I Button by June. I've also got classes for calling handlers in scripts and extracting the results.
6. HS will lead evaluation of potential changes to the project structure of ODF when Metrowerks release CW 2.0.
7. ODF-Interest is continued at HS's web server if needed. ODF developers will be consulted about all major changes, and I'm hoping they'll submit their improvements as well. Coordinating what goes into the reference version should not be a terribly hard task.
8. Developers will be responsible for finding bugs in ODFLibrary, and recommending fixes. All developers will evaluate fixes for compatibility with their software. HS will release an update when enough developers concur that a suggested fix is appropriate.

I look forward to all comments. I would suggest sending comments to this list, to me, and to Mark Thomas, Components Evangelism manager:

markt@apple.com

It is important that this be resolved quickly, while all the ODF materials are available and the people to gather them still around.

I want everyone to know that HS wouldn't bother with this for a moment if HS didn't think it was worth the effort, and if it wasn't within HS's means. The payoff for HS is the continuation of OpenDoc, the development of more parts that work with Rapid-I parts (whether you want them to or not :-), and a chance to continue making money.

Thanks for your consideration,

Brad Hutchings
General Partner,
Hutchings Software