0.40 2010-08-29 -20:13 -0700
1. Who Participates in ODMA
1.1 Software Developers
1.2 Administrators, Power Users, and Integrators
1.3 Document-Management Newcomers and Students
2. On To Active ODMA
2.1 Taking an Open-Source Approach
2.2 Identifying New Participants
2.3 Approach to Further Engagement
3. Further Information
1.1.1 Initially, the ODMA community consisted of software developers of document-management systems and of document-oriented applications on the Microsoft Windows desktop. The development process led to the series of ODMA specifications, from 1.0 in 1995 to 2.0 in 1997 with full deployment in 1998. The result of this work remains in use today.
1.1.2 The development work was carried out on 16-bit Windows 3.1 followed by migration to 32-bit support on Windows NT to Windows 98 and on to Windows 2000 and XP, both servers and clients.
1.1.3 The work was heavily developer-oriented during development and integration until completion of the ODMA 2.0 Specification and Connection Manager software. The ODMA community, organized as the ODMA Coalition under AIIM International through its Standards Department, dissipated as ODMA became stable and well-established. To this day, the most-common level of compliance is with the original ODMA 1.0, a subset of the later ODMA 1.5 and 2.0 specifications.
1.1.4 By April 2000, the ODMA Coalition was disbanded. The specifications and software were made available for public use under AIIM sponsorship as part of the DMware Interoperability Exchange. At this time there was a major change in the make-up of those having active interest in ODMA.
1.2.1 First, administrators and power users in organizations where ODMA was adopted as part of their document-management integration began to call for maintenance and troubleshooting support. In most cases, this involved finding ways to mediate between the user and the desktop/DMS software products to determine the root cause of failures. With the ODMA Connection Manager in the middle of these configurations, there were some remarkable opportunities for finger-pointing. Fortunately, ODMA 2.0 includes logging capabilities of great value in determining what requests were being made through the middleware and what the results were.
1.2.2 Over time it became clear that, although there are minor defects in the Connection Manager, they don't matter unless one of the other parties (usually the desktop application) is using the API incorrectly: has already failed. To this date, there are instabilities that have never been isolated, usually involving configurations of the Microsoft Office suite, the hands-down critical desktop applications in use with ODMA. Generally, assistance consists of walking someone through the capture of Connection Manager logs and then analyzing those logs to help pinpoint where the application failure is arising.
1.3.1 From time to time, new DMS products are developed and offered as ODMA-compliant systems. There are occasional requests for information and moderate assistance, but the developments happen independently, lately in Eastern Europe, Asia, and Latin America. The appeal is always for a way to simplify integration with key desktop software (always Microsoft Office) and, it seems, as a way to establish additional legitimacy for new DMS offerings from small companies. ODMA provides an appealing, lightweight approach for those cases, although most developers are wary of having to work in C/C++. Visual Basic and Java (and .NET for sure) would be preferred if it were supported by the ODMA Connection Manager integration model.
1.3.2 Recently, there are occasional requests for development advice from students who've taken on programming projects involving ODMA. In this case and that of new DMS vendors, it is clear that the samples in the ODMA SDK are inadequate as reference implementations, with new defects in the samples being uncovered all of the time.
1.3.3 There has always been more production of DMS integrations than new client integrations, although many vendors do not register their products with ODMA.info. For example, Adobe Acrobat Capture 3 features ODMA for writing PDFs to document-management systems.
2.1.1 The formalization of a BSD-compatible license for ODMA was provided in response to the private request of another desktop-application development organization.
2.1.2 This made explicit the promise made at the time the ODMA Coalition disbanded: The software, specifications, and any further development would be perpetuated as open-source in a form that allowed unrestricted incorporation in proprietary works. The original community effort was fostered by commercial software developers so they and all other interested parties could enjoy the mutual benefits of interoperability via ODMA. That arrangement is to be preserved.
2.1.3 Although the support for further development since 2000 has been lackluster at best, amounting to periodic flurries of activity by the technical coordinator, there is a SourceForge ActiveODMA project. It is proposed that it now (Autumn 2005) become the forum for any further development of community-shared ODMA fixtures of all kinds. The current planning is to employ the Creative Commons Attribution license for new web pages and documentation such as this one. The Academic Free License, a more-tightly written equivalent to the BSD license is being proposed for new software that is developed.
2.2.1 The creation of an open-source project creates a new set of challenges. The toolcraft of the open-source community is focused on the GNU/Linux tools, command-line processing, and distributed availability of source code. At the same time, ODMA is firmly anchored on the Microsoft Windows platform, no other implementation having ever been deployed. There are four challenges:
- 22.214.171.124 Providing narration and documentation of the approach to creation and distribution of new open-source components that is understandable to new ODMA participants. The newcomers may also be inexperienced at software development and having a Windows-centric background.
- 126.96.36.199 Moving through development on the web to software development on the site to development and coordination on SourceForge in steady, reliable steps.
- 188.8.131.52 Building bridges to the use of SourceForge in a way that preserves the arrangements for trustworthy development and opens up wider participation.
- 184.108.40.206 Releasing components that are safe, dependable, and that position us for improving the classic ODMA components without disrupting anything.
2.2.2 This will take a foundation that is inviting and reassuring for a range of participants, from the curious system administrator to students and seasoned document-management system developers.
2.3.1 ODMA is a niche fixture. In the world of the long tail, there is nothing wrong with that.
2.3.2 ODMA is also a fertile territory for some safe development of practices and approaches that can be reapplied in more complex settings where highly-trustworthy deployments are called for.
2.3.3 To have the range of engagement be accommodated in a practical way, we will identify a few personae that are in the target community. Then we will identify activities of these personae that we want to support. Then we'll produce some code samples and experiments because many onlookers want to be spoken to with code.
2.3.4 This should let people know where they'll find more of interest to them (or not), and when to expect it and in what form.
Continuing on ...
ODMA Interoperability Exchange.
created 2005-10-05-15:32 -0700 (pdt) by