OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [odf-adoption] Action items and deliverables

On 5/8/07, Erwin Tenhumberg <Erwin.Tenhumberg@sun.com> wrote:
> Dear TC members,
> 2) Considering that more and more tools for ODF and ODF
>     implementations are under development (e.g. the ODF toolkit,
>     the KOffice API, the OpenOffice.org development tools, etc.)
>     I think it's time to write a white paper that focuses on
>     developers. I'm willing to take a first stab at it, but I'd
>     like to hear your ideas what we should be covering.

I have been working off and on for months on an advocacy strategy for
developers designed to dramatically expand the number of web
applications supporting OpenDocument by more tightly focusing on
developers of particular application types. I do not have a formal
proposal yet. However, I will inflict the detail on the reader because
this document explains my vision of the way forward not only in
resolving the current dispute over the lists amendment but also how my
recommend resolution relates to an incredible opportunity for
exponentially increasing the number of applications supporting ODF
within a 2-year period.

In essence, this is a mini-max developer outreach strategy, that is,
the maximum return on invested money and effort for the least
investment dollar and effort. The ROI/investment ratio is unusually

After considerable research and thought, I have concluded that we get
our biggest bang for our developer outreach efforts by tightly
focusing our developer advocacy on web application componentry
framework and component developers and developers of a highly
selective group of ultra-popular web publishing solutions. I believe
this strategy if implemented appropriately would multiply the number
of web applications providing ODF read/write and search support by at
least 100 times over the next 1-1/2 to 2 years and very likely even
tens or hundrededs of thousands of times or more in terms of web sites
internationally offering such support.  In short, there is a market
opening that the proverbial Mack truck can be driven through.

This strategy in my estimation requires prior resolution of the
dispute currently pending on the Office TC that interferes with our
ability to truthfully brand ODF as an interoperability solution. I am
confident, however, that this problem will be resolved, particularly
in light of this report's recommended solution and its synergism with
other recommendations. I have therefore copied the Office TC with this
message. And as discussed below at some length, this strategy requires
coordinated work by both the Office and Adoption TCs.


ODF developer outreach has largely been a helter-skelter affair so
far, with far too little focus. We have done little beyond following
up with developers who have reached out to existing ODF developers for
assistance, an almost entirely passive approach. Although we have
development tools available for at least four programming languages
now commonly used for web app development work, there has been no plan
to aggressively promote those tools in a focused way that proliferates
ODF support as widely as possible for the least effort and expense.

At the same time, we have foregone several well recogned ways of
driving home a message effectively in the age of the Internet.


The strategy summarized here proposes addressing the problem with:

[i] a tightly focused and inexpensive publicity infrastructure built
around a basic system composed primarily of a small set of links to
developer resources and a comprehensive database of supporting

[ii] a set of OpenDocument Interoperability badges linked to that web
site from web applications that support ODF, developers' web sites,
and from supporters' web sites, email signatures, and the like;

[iii] pooling funds for a single full-time position for an ODF
evangelist tasked with persuading developers to support OpenDocument
and incidental expenses;

[iv] establishing a professional directory of ODF development
consultants and their contact information and areas of expertise on
the web site; and

[v] dividing responsibilities among other advocates for needed support
of the campaign such as drafting supporting documents, researching the
most appropriate vendors to target, providing leads to the evangelist,
publicizing the campaign, etc.

The evangelist must be fluent in discussing network effects and the
"rising tide lits all boats" theme in order to persuade developers not
only to support OpenDocument but also to publicize their support. The
evangelist must have a good grasp of issues in the file format wars,
but need not be a developer or have advanced development skills.
However, the evangelist must be able to explain certain advantages of
the RDF metadata capabilities coming in ODF 1.2 that can be used to
expand ODF interoperability using interoperability subsets for less
featureful application types such as web publishing editing solutions.
 Through implementing compatibility modes with the appropriate subsets
in their applications, developers of web applications will be able to
establish round-trip interoperability among similar application types
(lateral interop) and with the more featureful office suites (vertical
interop). Such capabilities can be implemented beginning when ODF 1.2
is stable.

The business case for companies that profit from OpenDocument to pool
funds for the campaign stems largely from the network effects "rising
tide lifts all boats" phenomenon. That is, the more applications that
support OpenDocument and are perceived as being interoperable by
potential users, the more perceived value each ODF app will have to
its potential users. By jointly publicizing the number and variety of
interoperable apps that support OpenDocument, cooperating developers
can raise the tide for all ODF app developers including themselves. A
very rapidly rising tide of ODF support will also generate revenue
streams for developers with significant expertise in adding and
maintaining ODF support in applications, perhaps pointing one way to
profitability for ODF vendors currently operating at a loss.

Consistent subthemes might include striking a blow for open standards;
 joining with other developers with the courage to compete on software
quality and cost rather than using vendor lock-in tactics; voting with
their product development work against standards encumbered by IPR;
etc. As with all effective goal-oriented communication, each theme
should be developed and applied as a call for specific action by the
target audience.


Using the mini/max market analysis technique, I have identified three
software types whose developers would benefit substantially from
network effects in a concerted campaign to publicize each others'
interoperable products and whose software types or particular
applications have very significant multiplier networking effects.
Those are developers of: [i] web application componentry frameworks;
and [ii] a specific family of search engines commonly incorporated in
web app frameworks and other web apps; and [iii] the developers of
very popular web publishing solutions.


Few complex web publishing solutions are written from scratch. Rather,
they are more commonly built atop application componentry frameworks
developed by others to avoid the necessity of reinventing the wheel at
every turn, which would require web app developers to maintain not
only the unique portions of their apps but to forego the benefits of
others' specialized expertise in the componentry framework field. A
far less than comprehensive list of such frameworks can be found here,
categorized by major programming language supported. We currently have
development libraries for four of those languages, Java, PHP, Python,
and Perl.

Notice that with Java we can impact the immature but rapidly expanding
Ajax Web 2.0 market, see e.g.,
<http://itredux.com/office-20/database/>, and with the other three
supported languages we can impact the only somewhat more mature LAMP
and WAMP web application markets markets. Each of those markets
currently has no standard for exchange of formatted documents between
web applications and between them and the more featureful and
traditional client-side office productivity applications. Google Docs
& Spreadsheets unquestionably has the largest market share in this
sector and because of that its feature set seems to be well on the way
to becoming the de facto standard for such exchanges. Any initiative
along the lines I suggest must take Google's overwhelming market lead
in SAAS web editors into account.

By targeting the market for web app componentry frameworks, we focus
our developer outreach where the greatest multiplier lies. For each
such developer persuaded to add that support, the ODF support
multiplies into every web application built atop the framework and
onto every website implemented with those web apps. It is hard to
imagine a market with a larger network effect multiplier. While
non-quantifiable with anyt precision, it is unquestionably an
exponential multiplier, spanning multiple orders of magnitude.

The evangelist's major task would be to target carefully chosen
framework developers with an ultimate goal of creating pressure for
competitors to match features with the contacted develper in terms of
ODF support. It is unnecessary to contact every such developer. For
the most part, I suggest targeting the popular FOSS framework
developers because they can reasonably be expected to be more
susceptible to our appeal and their support for ODF will create
pressure on the proprietary vendors to follow suit. However, as an
over-generalized observation, the proprietary framework developers
tend to be more closely aligned with Microsoft's formats than with
ODF. So as a general matter I see them as less immediately productive
targets for our direct efforts.

I stress that the web app componentry framework market is immature and
no developer has a monopoly position. The competition is very real and
any such developer who does not have his or her eye on the need for
compelling features probably won't be in business for too long.

The value add providing the incentive for such developers to unite
behind ODF is interoperability for web editors that presently have no
standard for exchange of formatted documents. Web publishing and web
editing solutions that can exchange formatted documents in a
standardized way gain an incredible advantage in the market.

The prospect  of adding that support at the framework level gives
framework developers a very large incentive to add ODF support. Very
many such developers have already added support for SXW but apparently
have not comprehended that adding ODT support would make their
products compatible with the exploding family of ODF apps. Indeed, I
have seen a surprising number of developers who do support ODF in
their software advertising on their web pages that their support is
for StarOffice/OpenOffice.org formats and make no mention of ODF. An
example is the Apache Cocoon web app componentry framework. See

As another example, there is now support for ODT in the Zope/Plone
Python-based componentry framework but it exists only in an extension
and is poorly publicized. Persuading the relevant developers to
include that support in the default Zope/Plone package and to
publicize that support are the major tasks here.

I have identified many other areas where there is low hanging fruit to
be picked without a significant investment of money and time. And the
network effect multipliers are enormous.

To catch and direct the wave, I recommend generally identifying and
targeting the rising stars in the market. As an example, the Eclipse
project has significant web app componentry frameworks in development
for its WTF project, backed by IBM, for Python, Perl, and PHP 5.0. As
friends of ODF, it likely would not take a major effort to persuade
IBM staff and their cooperating developers that these projects need a
higher and more visible priority for ODF support. Indeed, the PHP 5.0
framework already has ODF support in its site indexing and search
component, based on the PHP port/clone of the Apache Lucene search

For every componetry framework developer we can persuade to add and/or
publicize ODF interoperability in their default shipping package, we
gain an enormous multiplier effect by proliferating that support to
all web apps built atop those frameworks and to all web sites that use
those web apps.


My research has satisfied me that the various flavors of the Lucene
search engine far and away have the lion's share of the web site site
search market. Lucene and its ports/clones are already components in
the vast majority of the componentry frameworks for the LAMP and WAMP
platforms. Lucene is a de facto standard. All ports and clones use
Apache's original Java-based Lucene as the reference application. The
Lucene family is also very commonly integrated into roll-your-own SAAS

Lucene supports ODT but that support is not activated out of the box.
ODT is not among the file formats supported by default in the shipping
package. My research showed that activating that support requires only
the cutting and pasting of a patch consisting of about 40 lines of
code and recompiling. That patch though, seems to be almost
deliberately hidden in the Apache internet presence.

If we can persuade the Lucene developers to add ODT to the list of
filetypes indexed and searched in the out-of-the-box version and to
publicize that feature, we propagate ODF site search capabilities
across a nearly unimaginable number of web applications and web sites.
If the Lucene developers were hostile to ODF, the ODF support would
not be there at all. There is every appearance that this is very low
hanging fruit indeed.

I have previously noticed that there is a good-hearted rivalry between
the Lucene developers and Google's developers. Calling to the Lucene
developers' attention the fact that Google now indexes and searches
ODF documents is likely the most persuasive information we could
provide them. There is also the fact that several other site search
engines now support ODF. They are identified on the OpenDocument
Fellowship's Applications page. I do not believe it will be difficult
to persuade Lucene developers to join this campaign. I will note,
however, that only the Java version is an official Apache project;
however, the Lucene developers for all programming languages are a
close-knit community.


ODF support is available for several very popular web publishing
solutions. See the Fellowship Applications page Content Management
Systems category. However, the support currently exists in contributed
extensions that are not integrated into publishing solutions out of
the box. Promoting their inclusion in the default packages and their
improvement has the potential to pay enormous dividends in terms of
ODF adoption in web apps.

Persuading their developers to give ODF a much more prominent role in
their products can reasonably be expected to produce pressure for
their competitors to follow suit, compounding the networking
multiplier effects.


At least in the U.S., there are severe legal constraints on
cooperation among competitors centering on concerns such as price
fixing and allocation of market share. The latter has recently become
a concern in regard to a ballot just held on an amendment to the ODF
1.2 specification. But competitors in the software market are
generally on legally sound ground when they cooperate to develop
standards to enable interoperability, since such standards promote
rather than impede the substitutability of goods and thereby
competition in the market. So it is very important for legal reasons
if for no other that the proposed campaign be tightly focused on
achieving and promoting interoperability among competing application
developers. Happily, the value-add for competing developers in the
situation under discussion lies precisely in the area of developing
interoperability and jointly publicizing it in the legimate and mutual
best interests of cooperating developers, resounding to the benefit of
software consumers.

As already discussed, identification and recognition of
interoperability subsets for particular application types is integral
to the proposed initiative. This has tremendous value-add for
customers of the major ODF vendors such as Sun Microsystems. As
discussed below, this is an initiative that Microsoft can not follow
with its present business model (and to some extent because of the
mountains of spaghetti code surrounding its major applications' page
layout engines). There is a major opportunity here to out-innovate
Microsoft, ratcheting up the pressure on it to support ODF as its
customers demand that they be able to have the benefits of ODF

The problem addressed by this campaign is well understood. In the
context of Ecma 376, IBM's Bob Sutor has eloquently explained the
anti-competitive nature of a file format standard that is too complex
to feasibly allow competitors to achieve round-tripping of documents.
See e.g., Interoperability vs. Intraoperability,
<http://www.sutor.com/newsite/blog-open/?p=1260>; Is Open XML a one
way specification for most people?,

At present, the more featureful ODF office suites stand in that
position to the less featureful web applications that support ODF. But
interoperability subsets of ODF implemented by compatibility modes in
the less-featureful and more-featureful applications can enable the
round-tripping of documents among the less featureful apps (lateral
interoperability) and between them and the more featureful apps
(vertical interoperability). Indeed, I strongly suspect that such a
scheme for interoperability with Microsoft Office would enable Sun and
KOffice to have their desired list triples whilst enabling the
OpenDocument Foundation to continue making progress toward high
fidelity interoperability with the less featureful Microsoft Word.
(The compatibility issue with ODF 1.0 formats would still require an
effort at resolution, as Patrick Durusau has explained.)

Just so, persuading Google to take the initiative in leading rather
than dominating the web editor market by proposing its supported ODF
feature set as a formal interoperability subset for exchange of
formatted documents compatible with web editors and more traditional
client-side office applications. Because of the RDF changes coming in
ODF 1.2, no developer would be held back in going beyond the feature
set of the interoperability subset, but compatibility modes for the
interop subset in their applications would provide the means of far
more reliable exchange of documents with other users using different
editors. And as web editors become more featureful, successive
interoperability subsets supporting more features can be established.

For Sun and KOffice developers, they gain the value-add of having the
primary tools for adding unsupported formatting to documents produced
by the web editors, making their office suites in effect the hubs of
ODF interoperability.  The network effects come to the fore here, with
StarOffice/OOo and KOffice having a much more central and important
role to play in the universe of OpenDocument applications. At present,
those products can offer only one-way compatibility with ODF documents
produced by the less featureful apps.

Importantly, other than interoperability subsetting, I have heard no
proposals for resolving the conundrum posed by the need to achieve
high-fidelity interoperability with Microsoft Office whilst still
allowing the Office TC to out-innovate the market leader that refuses
to abandon vendor lock-in tactics and provide native file support for

This is not the only Office TC work needed to implement the scheme I
suggest. For example, the OpenDocument conformance section now allows
but does not require the preservation of data enclosed by foreign
elements and attributes and the requirement of preserving even ODF
metadata is less than crystal clear. Moreover, at present the wording
of that section would in my opinion allow, for example, Microsoft to
hijack the ODF standard by providing native ODF support and parking
binary blobs in the foreign elements and attributes. I am nearing
completion of a proposal to address such issues.


This strategy is also intended to take advantage of the unwillingness
of a company committed to vendor lock-in tactics to follow where a
truly open standard can go. Microsoft's office productivity business
model does not allow it to help competitors interoperate with its
products. Microsoft is thoroughly committed to one-way
interoperability and has steadfastly resisted the market's demand for
round-trip inteorperability with both its its Windows and office
productivity software products.

For example, Microsoft will not enable round-trip interoperability
with web editors because it wishes to sell competing, incompatible
products such as Sharepoint Server. That product is a major new
Microsoft vendor lock lock-in product using Microsoft's new "XML"
office formats as their communications protocol. Despite hyping the
benefits of interoperability with line of business products in its
Ecma 376 submission to ISO, Microsoft did not disclose the metadata
and functionality for its Sharepoint and Exchange Server hubs that use
Microsoft Office Open XML as their communicatons protocol. Ecma 376 is
at best a subset of Microsoft's own file formats.

There is even further critical metadata and functionality missing from
the Ecma 376 specification bearing directly on Microsoft's willingness
to enable round-tripping of documents with competitors, the
Supplemental Expert Report of Andrew Shulman in the Comes v. Microsoft
litigation. <http://www.groklaw.net/pdf/Supp_Rpt_Andrew_Schulman.pdf>.
Shulman had access to the MS Office and Vista source code and his
report details a host of undocumented APIs used by MS Office and the
line of business products. I have put several days into scouring the
Ecma 376 specification for metadata relevant to those APIs and have
found only one, a minor tag for Sharepoint Server that appears to have
been left in the Ecma 376 specification by accident.

In short, we need have little concern that Microsoft will respond by
enabling round-tripping of documents with competing web applications.
The open standards proponents have have a relatively unbroken field to
run here.


I have also identified a critical data structure type where we have
the opportunity to innovate where Microsoft is unwilling to follow. It
is no secret that Microsoft Word got lists-handling wrong from the
very beginning. Word's page layout engine does not have the
functionality to support true outlining and has a crippled method of
handling hierarchical data structures, a fundamental type of data
structure type.

Word's page layout engine does not support outlining, a feature of
considerable importance in the market, notably in the law office,
government, and academic markets. It allows only the manual
manipulation of lists. For several reasons, one can reasonably infer
that Microsoft is unwilling to bear the burden of correcting that
weakness in odf-adoption@lists.oasis-open.org, OpenDocument
<office@lists.oasis-open.org>the Word page layout engine, most likely
because of dependency issues and the accumulation of more than 15
years of spaghetti code atop the layout engine. I will not inventory
those reasons here, but will note that despite the importance of
outlining in the market and WordPerfect's full support for outlining,
Microsoft never fixed the problem to match features in the many years
of the intense Feature War with WordPerfect.

Unfortunately, StarOffice largely cloned Microsoft Word in this
regard, resulting in a critical flaw in SO/OOWriter. That problem has
now come home to roost in the TC disagreement over adding support for
lists metadata triples while continuing support for the ODF 1.0 list
tuples also used by Microsoft Word. The Sun and KOffice developers
understandably do not wish to bury that bug under years of subsequent
bug fixes and dependencies and to fix it before it is even more
painful and expensive to do so.

One of the major problems I see, however, is that we have not involved
developers with a real stake in the outcome, the developers of true
outliners. While I can agree that we should not allow bugs in
Microsoft Office to limit future ODF development, there are compelling
reasons to address that problem in a manner that neither breaks
high-fidelity interoperability with MS Office nor cripples the
evolution of web standards' handling of hierarchical data structures.
For those who have not followed the dispute, the problem lies with
list numbering. List tuples can be translated to list triples, but
there is no standardized method of going the other way, a
round-tripping problem that can result in numbering changing in the
translations. This a barrier to compatibility both with MS Office and
with the ODF 1.0 formats that does violence in high-fidelity
interoperability use cases involving migration to ODF and fully
automated business processes such as in a SOA.

But is what most relevant here here is that the interoperability
subset for exchange of formatted documents created by web editors
needs attention by developers of the new crop of Ajax outliners just
appearing on the market. See e.g., <http://www.ijot.net/>, which uses
OPML as its interoperability format. That is not a choice I would make
given OPML's numerous warts. See e.g.,
<http://en.wikipedia.org/wiki/OPML#Shortcomings_of_OPML> ("Due to the
arbitrary nature of the "type" attribute, and the acceptance of
arbitrary attributes on "outline" elements, interoperability of OPML
documents relies almost entirely on the undocumented conventions of
content producers").

I see it as critically important that the Office TC ensure that lists
handling neither breaks round-trip compatibility with existing
client-side outliners nor with the new crop of outliner web
applications beginning to appear. The HTML lists model was never
intended to be the final word on handling of lists on the Web. But so
far the discussion of the lists issue has not addressed the
requirements of developers with true outliners, a class of
applications historically marginalized by the unavailability of
supporting metadata in the major office suite's file formats.
Presently, there are more than 100 client-side outliners on the market
using a riot of file formats with their hallmark difficulty that of
round-tripping documents with the market leading office suites.

I recently persuaded the developer of one outliner to add
import-export support for ODT. His new version is at the feature
freeze stage and he says he has been able to round-trip outlines with
OOo. Development snapshots are available if anyone is interested.
<http://bellz.org/treeline/>. But will he still be able to round-trip
outlines with OOo if the current lists amendment stands? We simply do
not know. Neither have we looked at whether the lists amendment risks
breaking interoperability with web-based outliners beginning to
appear. Moreover, outliner developers have other metadata needs that
may be able to be resolved using RDF in ODF 1.2. But will they be able
to do so in a standardized way that that still allows round-tripping
of documents with other outliners and with the market leading office
suites? Again, we do not know the answer and our actions risk barring
outliners into the ODF fold, an entire class of office productivity

We do not create this standard in a vacuum bounded only by the needs
of current participants. We hope to create a standard enabling fairly
universal interoperability among office productivity applications. But
what constitutes "office productivity applications" is a moving
target. We ignore the foreseeable needs of new application types at
the risk of crippling the standard's future implementation by a wider
group of developers than those represented here. Certainly, getting
the handling of lists right is more important than how quickly we do

I urge all TC members to take a fresh look at the lists issue as an
opportunity for advancing ODF adoption and support, rather than as an
intractible problem that can only be resolved by breaking
interoperability with less featureful applications. Using
interoperability subsets and compatibility modes, we can deliver
interoperability as our hallmark feature, dramatically enhancing the
value of all apps that support ODF. But we deal here with a
fundamental data structure type. The scope of the problem may be far
broader than just compatibility with MS Office and ODF 1.0. We have
web apps, web outliners, and traditional outliners to consider unless
we are to deny them the benefit of round-tripping ODF documents.

Returning to the subject of a web editor interoperability subset,
Microsoft will not follow this initiative unless and until it drops
its vendor lock-in business plan. Microsoft is not into round-tripping
documents with competitors' applications.

Using RDF in ODF 1.2, I understand it would be feasible for developers
to create interoperability subsets by agreement. The principal utility
of formally establishing interoperability subsets in the standard is
that it creates pressure for developers to support the standard. For
example, the Agreement on Government Procurement requires governments
at all levels to specify International Standards where they exist in
their software procurement tenders. Beyond any doubt this is why
Microsoft is seeking ISO standardization for Ecma 376.  As open
standards continue to become more important to governments, the treaty
will tend to cap market share for applications that do not support
International Standards. By establishing the formal standard for
exchange of formatted data between web applications within the ODF
standard, ODF becomes the lingua franca for such purposes.


While other campaign materials will need to be developed, the hard
core of the publicity effort to supplement the evangelism is an ODF
applications database on the web, demonstrating the breadth of
applications sharing common file formats. "OpenDocument
Interoperability" badges in web applications providing ODF support
linked to the database are intended to drive software users and
developers interested an adding ODF support to the site, which would
include links to developer resources on the home page. In essence,
this establishes a clearinghouse to inventory the applications that
support ODF and a database highly useful to potential users looking
for particular types of software and features. I know of no antitrust
barrier to such joint promotion of software that supports a particular

The OpenDocument Fellowship's Applications page is currently the most
comprehensive inventory of such apps, but we have been falling behind
for some time primarily because we use a static page for the purpose
and have up to know required that software be test-driven and
evaluated before being rated using a star system. There is some
support for dropping the rating system and reimplementing the project
using a database and web form for submission of data in predefined
fields that will better capture the information we need. As it stands
now, we invite developers to do their own page edits and ratings, but
as the page's formatting grows more complex fewer developers are
inclined to go to the trouble. I would estimate that we know of at
least twice as many ODF apps as those listed.

I think it important that the new Applications database be a branded
as the joint venture of the major ODF advocacy organizations and
developers who provide support for ODF in their applications. (I do
not see any issue, however, with giving prominent credit to the
organization that hosts and maintains the site. ) I have raised these
issues with the ODF membership.

Developers of web software would be urged to include the badge links
in their default installation packages, requiring deliberate user
action to hide them. I have in mind linked badges such as those at the
bottom of this Tikiwiki page, <http://dev.tikiwiki.org/Features>,
which appear in all default Tikiwiki installations and must be turned
off if the site operator does not wish them to appear.

Examples of such websites that promote the "rising tide raises all
boats" theme include the Office 2.0 database,
<http://itredux.com/office-20/database/> and the CMS Matrix site,
<http://www.cmsmatrix.org/matrix/cms-matrix>. There are many others.
For an example of a web data submission form that would dramatically
ease the burden of maintaining the database and keeping it current as
well as relieving data submitters of the burden of formatting the
data, see <http://o20db.com/db/submit/>

I know from many years experience in owning/operating a office
productivity software-oriented site that nothing drives search engine
rankings like a topical metalink collection in turn linked from
countless other websites. Our Links index page consistently was the
first page visited ten times more often than even our home page. It
was the engine that drove our traffic to the point that we had the
premier web site for the particular technology involved. We were in
effect the portal to all related sites, by design. The fact that we
were able to drive so much traffic to related sites gave the other
site owners ample reason to aim people at our web site because they
were sensitive to the networking effect that raised all boats.

In this instance, I think it important that the site also include a
professional directory of those with development expertise willing to
consult with other developers, summarizing each person or firm's areas
of relevant expertise. This feature would also serve as a resource for
the evangelist and others promoting the campaign to developers.

I am sure that those closely involved with ODF advocacy will see many
opportunities for supplemental activities built around the hard core
described above. E.g., a free service for developers to publish
support announcements to targeted mailing lists.

I also think it critically important that the necessary funds be
raised by pooling investments rather than by simply asking a large
vendor to write a check. It is important that those who profit from
OpenDocument feel some sense of investment in the success of the
campaign. And nothing could be more damaging to the campaign than a
revalation that it was bankrolled by a single large company with a
vested interest.

I will close my discussion of the strategy by apologizing again for
the length, but I have researched and refined this concept for many
months and believe that it requires the detailed explanation given,
particularly as it relates to the issue that has fractured consensus
on the Office TC. Interoperability is more than a technical problem;
it is the key to the success of ODF in displacing vendor lock-in
formats. Enhancing ODF's interoperability presents an opportunity for
innovation, not a barrier.

> 6) What ISV's and open source projects should we proactively
>     contact in order to encourage them to support ODF?

See above discussion.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]