Why OpenOffice.org Failed - and What to Do About It (ComputerWorld UK) [LWN.net]

Why OpenOffice.org Failed - and What to Do About It (ComputerWorld UK)

Posted Oct 23, 2008 6:13 UTC (Thu) by PO8 (subscriber, #41661)
Parent article: Why OpenOffice.org Failed - and What to Do About It (ComputerWorld UK)

The thing nobody ever seems to comment on in these studies is the base issue. What Belgium's FPSE has is what a lot of organizations have: a software development organization dispersed in and disguised as an administrative department.

The failure to take spreadsheets and macros as software and manage it appropriately is a classic risky strategy common in government and finance. If these were taken seriously by the sponsoring organization, there would be several positive effects.

Separation of concerns: The software needs of typical office workers are quite different from those of software developers working in an office environment. The FPSE study clearly identified these two groups, and verified that the majority of users were in the first group. No explanation was given as to why this group of users could not be successfully migrated to OpenOffice, while leaving the rest of the Dept on MS Office (or elsewhere; see below).
Professional management: A number of good practices have been identified for management of software and software development. To use these, though, you typically need to identify a work product as software.
Requirements and verification: In a properly managed software project, software requirements are well-specified, and a good software solution is selected based on the requirements. This is typically only possible once the software components of the system are isolated. A requirements specification also enables verification of a software product, which is a key tool in assessing a change in solution.
Appropriate skilling: Once you've identified the software project, you hire software development professionals to develop it. If it's statistical software, you take special care that these developers are also knowledgable about mathematical and statistical methods.
Appropriate tools: Statistical software should be written using tools such as R. Data management software should be written against a database framework. When this sort of thing is written in an office suite, experience shows that it will be fragile and difficult to maintain.

Etc, etc. The point is that arguably the least of the problems at FPSE and places like it is lock-in to Microsoft. If they solved their real problem—lock-in to a broken methodology—the rest would take care of itself.

It also seems from previous comments that the authors may have had some real naïveté about the political workings of the project. This guess is supported by the almost complete lack of discussion of political and personal factors in the FPSE project.

This was in some ways an informative study. However, I do not regard it as particularly indicative of the general situation.

(Log in to post comments)

Why OpenOffice.org Failed - and What to Do About It (ComputerWorld UK)

Posted Nov 3, 2008 19:55 UTC (Mon) by Lifewish (guest, #55026) [Link]

I've just signed up to LWN entirely for the purpose of responding to this post. It is an incredibly insightful post. It should be read out loud to anyone who even *thinks* of touching VBA. Heavy weaponry and attack dogs should be extensively used to ensure the wannabe developer's mind is focused on the subject at hand.

However, I would question one of the claims here, that this development model is broken. From the point of view of programmers, even of amateurs like myself, this is clearly the case. A world where version control consists of thinking up a new cute name for your spreadsheet every few weeks is not a world in which I wish to live.

But, from the point of view of the managers in (e.g.) the pensions industry, the model works fine. It limits expenditure. It avoids hassle and political intrusions. It stops the IT dept stepping in and turning a two-hour job into a two-month fiasco. It prevents their employees being snaffled by real software companies.

Fundamentally, this is because the ten-year event horizon of a competent programmer is greater than the six-month event horizon of a competent manager. They're not worried about long-term maintainability; they're worried about whether adding in a market value adjustment can be done *yesterday*. They're not worried about verification; they're worried about spelling errors in the Most Holy Standard Wording. They're not worried about separation of concerns; financial professionals are used to being concerned about *everything*, all the time...

The only real silver lining I can see is that a sort of software middle class is emerging. People who separate their concerns, who know that code commenting is important, who are aware that GOTOs are bad... and who talk to each other, sharing best practices. More, they are able to explain the motivation behind these practices to managers.

As this element hits critical mass, I predict we'll see a gradual shift from the alchemy of the traditional VBA guru to the science of these new practitioners. Most of this science will be reinventing stuff that real developers already know, but eventually the two communities will reach feature parity.

One big part of this process will, of course, be developing better Office tools - proper spreadsheet/programming hybrids and the like. The main reason no-one does proper source control on spreadsheets is because you *can't*, not really. I'm hoping this will become a visible issue over the next few years.

Why OpenOffice.org Failed - and What to Do About It (ComputerWorld UK)

Posted Nov 3, 2008 23:18 UTC (Mon) by nix (subscriber, #2304) [Link]

I nominate that comment and its parent as the two best comments on LWN in
the last six months. Don't leave, we need more insight.