I recently came across a blog that Sun CEO Jonathan Schwartz posted in October 2008 opining that the fiscal crisis toppling financial institutions (and many of Sun’s key customers) presented a huge opportunity for the comapny because “innovation loves a crisis”. Spring forward twelve months, and Oracle President Safra Catz is meeting with the European Union Competitive Committee for approval of its proposed $7.4 billion acquisition made in April (see Parting Ways and Parting Ways (Redux) for my perspectives on the developments).

In the intervening 12 months, Sun announced plans to cut another 3,000 jobs, or about 10 percent of its workforce, to pare expenses over the next 12 months. In addition, Oracle Chief Executive Officer Larry Ellison said in September that Sun is losing about $100 million a month as the transaction is delayed by the EU probe.

So what exactly went wrong?

The first point that Schwartz said in his blog a year ago was that Sun needed to “to engage with customers in driving down cost, driving up utilization, and driving the changes that yield immediate and long term benefit”. He added that Sun was dramatically underpenetrated in the global market, and that represented a great opportunity for growing both current relationships and growing new customers.

Yet the ultimate benefits of a Sun-Oracle combination are far from clear for Sun’s customers, as industry analyst George Weiss was quoted in an InfoWorld article.  He noted that customers may not make long-term commitments even with EU approval of  the acquisition because of such unresolved issues as:

“In times of crisis, we have a big opportunity to stand apart from our peers, to be better connected to the market, even if it’s in turmoil. Yes, our customers are going to be under stress, but that’s simply another way of saying “open to change.” And I want Sun to be the company engaging them in the transition – with our ideas and our roadmaps. The door is open.

And yes, we will see some customers disappear – we will also see many emerge even stronger. And the market, as it’s done for the past 30 years, will return to growth – led by the companies that took advantage of the downturn to become even more valuable, to grow even faster.

So I want to assure you, we are watching the market very carefully, to understand the impact on Sun, and the challenges in front of us – on a macro and micro level. But I and my leadership team know the drill, we’ve seen this before when the last bubble burst – *now is the time* to get in front of the opportunity, and firmly establish new ground. Now’s the time our customers will be most open to change.

Let’s be sure we’re there to help – and to take advantage of the opportunity.”

I recently started a contract writing assignment with a small startup company that hadn’t made revisions to their existing product documentation in over a year (and is planning for a new product release real soon now). It’s the same startup where I spoke to the engineering manager about the use of open source authoring tools (see my post Bottom Line). The discussion eventually evolved into my proposal to use open source software as a “free” (or at least low-cost) alternative to the expensive per-user licensing and support contracts that are required for commercial tools such as FrameMaker and RoboHelp. In a time when companies need to get the biggest “bang for the buck”, OpenOffice (or variants such as StarOffice and Lotus Symphony) may be all that a small to medium sized company needs to create the short article-length documents that are preferred for posting to the Web (as if anyone really read book-oriented PDF documents cover to cover anyway).

So, I started with a situation where there were no source files for the documentation that shipped with the last software release, no clear idea of which versions of the authoring tools  were used, and no real incentive to spend the $999 for the current version of RoboHelp or FrameMaker. My first real task was to take the last available FrameMaker 7 source documents archived from an older software release, buy an older compatibile version of FrameMaker (at only $499), and eventually export RTF files that could be used with OpenOffice before any updates and revisions could actually be incorporated. Along the way, I contended with authoring tools issues (such as template formatting, conditional text, and PDF export) that are not within the expertise of the average technical writer, and I found that the “free” technical support to be minimal.

Once I managed to break apart the book-length manuals into manageable chunks (approximating a chapter in length and topic organization),  I found that OpenOffice provided the flexibility to export the content to the project team to review and update in wiki format (moinmoin is what is used here), then I could take those revisions and updates to create PDF files to post on the company web site, as well as serve as the basis of an “old school” browser-based online help set that uses standard HTML tags (framesets) rather than rely on fancy JavaScript or ActiveX controls.

A pleasant benefit of using open-source software such as OpenOffice  is that no expensive upgrade was required in order to extend OpenOffice with the ability to import and export PDF files (included in version 3.1) or to import and export wiki formats (contributed by community members). Perhaps the needs of the startup where I work are not as complex as my former employer that maintained a large knowledge base with expensive single-source structured authoring tools. However, through the collaborative efforts on open source software, the bottom line seems to be that low budget does not necessarily mean low tech.

With rumors  of the Rock project (intended to be the next generation SPARC microprocessor) being cancelled two years after Jonathan Schwartz’s announcement on his blog,  Sun Microsystems may have finally conceded its independence as a systems vendor before its impending acquisition by  Oracle (see Parting Ways).

Perhaps the should not come as a surpise with the recent  launch of  mid-range systems from IBM, Dell, HP, and Sun based on the Intel Xeon 5500 quad-core microprocessor  (code named Nehalem) with claims of being half the cost and 1.7 times the performance of a comparable SPARC-based system. Likewise, at the high end, where Sun is the preferred platform for  Oracle databases and applications with its current Niagra-based servers, there are Oracle benchmarks that show that blade servers based on the the previous generation Xeon processors scale well  to “Big Iron” mainframe performance.  Even IBM has had to re-evaluate its commitment to its Power microprocessor architecute (as has HP with its commitment to the Itanium microprocessor).

With no apparent edge on the systems side of the business, what will Oracle do once Sun shareholders vote on July 16?  Oracle estimates that Java and Solaris are the crown jewels that will be quickly exploited due to tighter integration with the company’s existing database and enterprise middleware offerings. Such retooling could provide Oracle a significant competitive advantage over such rivals as IBM (see article) and Microsoft (see article), as well as contribute $1.5 billion to Oracle’s operating profit–excluding charges and other items–in the first year after the acquisition, increasing to over $2 billion in the second year.

Moreover, Larry Ellison said the acquisition gives Oracle the ability to  engineer an integrated system – applications to disk – where all the pieces fit and work together with customers benefitting as their systems integration costs go down while system performance, reliability and security go up (see article). However, Oracle already has such an arrangement with HP to build a grid of Oracle database servers with HP Exabyte servers.  Current industry speculation suggests that HP may buy Sun’s hardware, storage and integrated cicuits intellectual property outright after the Oracle acquisition is final (see article).

This still gives Oracle an incentive to continue as the steward for open specifications focusing on the Java Community Process and OpenSolaris. On the other hand, all may not be as rosy for colleagues working on open source initiatives (such as the NetBeans developer tools and the Glassfish  application server) that compete with more popular offerings such as Eclipse and JBOSS.  Such projects could soon be on the chopping block on top of the 6000 job cuts already announced by Sun (see article).

Besides the obvious layoffs involving  the systems side of the business, the software side will also come under close scrutiny with salaries that exceed those paid by Oracle.  Oracle has also earned a reputation for a military-style discipline that may come as a shock to more relaxed Sun employees.

In the end, Sun Microsystems became a victim of its own success. Like other successful startups such as Silicon Graphics and Netscape Communications, the company differentiated itself with innovations such as Java and networked computing, but the company could not adapt as the times changed (like the dot com bust) and the technologies it evangelized became commodities that could be easily duplicated or replaced with ease and lower cost.

I had a recent conversation with an engineering manager at a small startup company who was interested in finding ways to update the existing company  documentation, as well as create documentation for a new product release. What piqued my interest was that the conversation led to a discussion of authoring tools and their ability to handle current output formats (such as HTML and PDF) as well as upcoming Web 2.0 technologies such as blogs and wikis for collaborative documentation (see my previous post).

Coming from a  company background with dedicated publication teams, it was easy for me to assume that their documents were created using software such as Microsoft Word or Adobe FrameMaker. At first, I argued the relative merits of a word processing tool such as Word for short documents and FrameMaker for multi-chapter documents. Then, I realized the manager was far more interested in the use of open source software such as OpenOffice for authoring.

I continued the discussion comparing the relative merits of OpenOffice against Microsoft Word, when I began to see that the discussion was evolving into the prospective use of open source software as a “free” (or at least low-cost) alternative to the expensive per-user licensing and support contracts that are required for commercial tools such as Word and FrameMaker. In a time when companies need to get the biggest “bang for the buck”, OpenOffice (or variants such as StarOffice and Lotus Symphony) may be all that a small to medium sized company needs to create the short article-length documents that are preferred for posting to the Web.  Even more, open source software such as the Liferay 5.2 portal application can  not only be used to publish content to the Web, but also to manage Microsoft Office formatted documents in a content management system.

Through the collaborative efforts on open source software, the bottom line seems to be that low budget does not necessarily mean low tech.

Great minds think alike! I wrote about the impact  on the impact of agile software development on documentation (see On The Fly) where I shared my experiences how the frequent (and often extensive) changes to product features make it difficult to create conventional documentation such as product manuals and online help within tight project deadlines. After that post, I came across The Agile Technical Writer and The Agile Technical Writer II by Susan Maddox. Based on her experiences working on agile projects. she came to the conclusion that, rather than her role as a technical writer being cut out of the loop, she finds it has become even more interesting, exciting, and valuable.  She said, “As a technical writer, my aim is to reduce other people’s work, by making the documentation as simple and useful as possible. It takes a lot of work to achieve that simplicity. But it’s awesome because it’s what I love doing.”

I couldn’t agree with her more wholeheartedly. I urge you to read Susan’s posts to get a another insider’s perspective on the impact that agile development is having on how products and services are documented.

The recent announcement of Oracle acquiring Sun Microsystems is the final milestone in my association with a company that spanned over 20 years. As a technical editor for Computer Design magazine in 1982, I remembered interviewing  Andy Bechtolsheim and Vinod Khosla for an article on the original SUN workstation  that Bechtolsheim designed while still a graduate student at Stanford University.  As a user and (sometimes) workgroup administrator, I experienced first hand why the reputation for reliability and performance of Sun’s servers and Solaris operating system made it the darling of  so many corporate IT organizations (or at least until the the dot-com bust). As a former employee, I toiled through the many attempts where Sun sought to capitalize on its huge investment in the Java programming language by placing big bets on its iPlanet alliance with AOL/Netscape Communications, Java Enterprise System, and open source efforts involving Glassfish and Liferay.

So what will become of the company that once prided itself on innovation and commitment to open standards? Oracle estimates that Java and Solaris are the crown jewels that will be quickly exploited due to tighter integration with the company’s existing database and enterprise middleware offerings. Such retooling could provide Oracle a significant competitive advantage over such rivals as IBM (see article) and Microsoft (see article), as well as contribute $1.5 billion to Oracle’s operating profit–excluding charges and other items–in the first year after the acquisition, increasing to over $2 billion in the second year. 

Moreover, Larry Ellison said the acquisition gives Oracle the ability to  engineer an integrated system – applications to disk – where all the pieces fit and work together with customers benefitting as their systems integration costs go down while system performance, reliability and security go up (see article). This will also give Oracle an incentive to continue as the steward for open specifications focusing on the Java Community Process and OpenSolaris.

Still, all may not be as rosy for colleagues working on open source initiatives (such as the NetBeans developer tools and the Glassfish  application server) that compete with more popular offerings.  Such projects could soon be on the chopping block on top of the 6000 job cuts already announced by Sun (see article).

In the end, perhaps Sun Microsystems became a victim of its own success. As a startup, it quickly overtook larger rivals such as Digital Equipment and Apollo Computer by providing workstations and servers based on cheap microprocessors (the Motorola 68000 family) and open source software (UNIX 4.3bsd)–yet it could not compete with cheaper offerings from Dell, IBM, and HP using Intel microprocessors and Linux. As an innovator, it invented the Java programming language — yet it could not transform its  investment into a competitive advantage (as happened with AT&T with both the C and C++ languages).

The original premise when I started this blog was to discuss how Web 2.0 technologies and open source software are changing the way that products and services are documented. Document collaboration among a community of authors (and not just a single team of writers) is becoming the norm with open source software projects such as Glassfish and Ruby on Rails using blogs and wikis for discussions and draft reviews. The influence of document collaboration will become more pervasive as (once) proprietary products such as databases and operating systems incorporate open source components (such as MySQL Enterprise and Red Hat Enterprise Linux).

An even more fundamental change than the increased use of document collaboration tools is the way that software products and services are being developed. As customer requirements demand more flexibility and quicker response in planning and implementation, companies are adopting agile development processes that focus more on working software than formal detailed specifications. The foundation of agile development are principles where software is planned, implemented, and tested “on the fly” so that project teams work closely with customers as requirements change, rather than treat change as an impediment to the development process. For more information, a presentation on agile development (in particular the Scrum methodology) is available here from the Scrum Alliance.

The impact on conventional product documentation (from user guides to online help) is potentially huge when a project team adopts an agile development process. No longer can writers use formal specifications as a negotiating point with project teams to determine the number, scope, or schedule of document deliverables. Likewise, writers can no longer rely on formal specifications to provide the gist of the information that will be fleshed out during the draft development and review cycle. Instead, the de-emphasis on formal specifications in agile development means that writers must be able to install and configure the software from working prototypes to the final version in order to create the needed task, reference, and conceptual documentation.

Scott W. Ambler wrote an excellent article detailing the documentation issues for agile development. Some of the insights that he shares are:

• The fundamental issue is communication among team members, not formal documentation.
• Write documentation if that’s the best way to achieve relevant goals, but there are often better ways to achieve these goals than static documentation (such as an online help system that focuses only on a single product release or version).
• Document information that is stable (not speculative).
• Seek (then act) on feedback on a regular basis throughout the document draft and review process.

Because of the iterative nature of agile development, Ambler notes that a best practice should be to wait until the information has stabilized before you capture it in documentation. It is risky to capture speculative information, such as requirements or design details, early in the lifecycle because those details are likely to change.

To give you some idea of the current (and likely) demands for someone wishing to create documentation on an agile project, you can look at a wiki article intended to describe the administration console for an open source project. As with the rigor of agile development, the administration console underwent significant UI changes between the November 2008 community milestone build to the current Beta build in January 2009 — requiring a total of 38 draft revisions to the original wiki article posted in November (and likewise supporting the decision that a conventional online help system for the console was too risky at that stage in the development). To track all those changes, myself and another writer became part SME (knowing what the software is supposed to do), part system administrator (install & configure software), part QA engineer (figure out what the software actually does and doesn’t do) before we can even devote time to the task of actually writing.

This effectively means that writers are no longer insulated from the software development and QA testing processes with a unique process just for product documentation. Writers will increasingly be asked (if not required) to participate as peers on the project team during agile software development, or else their jobs will (most likely) become redundant.

I said in a previous post that, while community wikis are a valuable opportunity to solicit feedback, they cannot replace the requirement for dedicated writers to create task, reference, and conceptual documentation for a given product or service. Yet, I did not acknowledge at the time that community members have an “enlightened” self interest to keep the wikis accurate and up to date.

Two articles that were contributed to the Liferay community wiki (as part of an open source partnership) brought this to mind. The first wiki article had updates incorporated by a community member after the article was first posted. The other wiki article illustrated the opportunity for community members to discuss possible revisions/updates after the article was first posted.

Such input/feedback could not be incorporated at the time that these articles were written because, to be honest, the authors of the articles couldn’t anticipate everything that the users would need to know (or want to know). Indeed, there is wisdom in saying that the community is greater than the sum of its members.

PS

I have summarized the effort needed to contribute articles to the Liferay community wiki (with an eye towards creating documentation for a future commercial release) on my wiki.

I haven’t gotten any user comments on the articles that have posted to the community wiki after blogging about it. But, just for argument’s sake, I do get comments from users just after I start together the review draft of the product documentation (which are based on the wiki articles). Do I incorporate the user comments as part of the product documentation as I would review feedback from the project team? Or should I just collect the user comments and have the product team review them for completeness and accuracy (as is done with bug reports)?

In other words, should a documentation wiki for an open source project be considered as complete and accurate when the product documentation is available separately? Or, more to the point, can a documentation wiki replace the need for separate product documentation?

My past experience working on open source documentation projects is that, while community wikis are a valuable opportunity to solicit feedback, they cannot replace the need for dedicated writers to create the required task, reference, and conceptual documentation. In other words, someone has to bake the cake before others can get a taste.

Perhaps the ideal role that community wikis and blogs can play will be to provide forums to discuss how to fill the gaps in the product documentation over the life of the product, perhaps starting with planning and deployment issues (at the beginning of the product lifecycle) to upgrade and migration issues (when the next product release is available).

PS

Originally posted on blogs.sun.com by J. Aseo on 10/31/08.  You can find a summary of the effort needed to support the Project SocialSite community wiki (with an eye towards creating documentation for a future commercial release) on my wiki.

I wrote my first blog about my issues with blogs and wikis (specifically blogging to arouse user interest in an early draft of an article). So…after a full month of revisions incorporating feedback from the project team after first posting my article to the wiki, I think the content is now “complete” (or at least it incorporates everything that everyone on the team can think of). Then comes the deafening silence of no responses from the community…kind of like that saying “If a tree falls in the forest, and no one is around to hear it, does it make a sound?”

At first, I’m more than a little discouraged, because wikis are supposed to be this wave of the future that will bring about the age of collaborative documentation and forever break down the walls between professional technical communicators and the user community, But perhaps I’m just being skeptical–it took 20 years before desktop publishing moved from the realm of graphic designers to everyday users. Things take time, and good ideas like wikis will eventually move from the realm of computer geeks to everyday users.

So, I guess I’ll just continue to keep posting articles, being well aware that community feedback may be slow in coming (if at all at first). But if you plant a seed, and the seed grows up to be a tree, then someday that tree just might make a “boom” and someone will be around to hear the sound.

PS

Originally posted to blogs.sun.com by J. Aseo on 10/31/08.  You can find a summary of the effort needed to support the Project SocialSite community wiki (with an eye towards creating documentation for a future commercial release) on my wiki.