[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [odf-adoption] Action items and deliverables
Good suggestions. FYI, pooling resources to hire an evangelist is something that can be done through OASIS, if that's what members want to do. WRT the suggestion that we need a website with links to developer resources, a comprehensive database of supporting applications, and a professional directory of ODF development consultants, we already have one -- http://opendocument.xml.org. If that site needs to be modified to better meet the needs of developers, let's work on that and not create yet another web site on OpenDocument. Carol _________________________________ Carol Geyer Director of Communications OASIS +1.978.667.5115 x209 -----Original Message----- From: marbux [mailto:email@example.com] Sent: Thursday, May 10, 2007 5:42 AM To: firstname.lastname@example.org; OpenDocument 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 high. 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. I. STATEMENT OF THE PROBLEM 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. II. SUMMARY 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 applications; [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. III. TARGETING THE MESSAGE 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. A. COMPONENTRY FRAMEWORKS 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, <http://en.wikipedia.org/wiki/List_of_web_application_frameworks>, 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 <http://cocoon.apache.org/2.1/features.html>. 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 engine.. 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. B. THE LUCENE SEARCH ENGINES 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 sites. 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. C. VERY POPULAR WEB PUBLISHING SOLUTIONS 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. IV. ODF WEB EDITOR INTEROPERABILITY SUBSET 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 interoperability. 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?, <http://sutor.com/newsite/blog-open/?p=1145>. 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 ODF. 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. V. TAKING ODF WHERE MICROSOFT WILL NOT FOLLOW 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. VI. UNRAVELING THE LISTS DISPUTE 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 email@example.com, OpenDocument <firstname.lastname@example.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 software. 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 so. 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. VII. CAMPAIGN PUBLICITY 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 standard. 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]