In association with heise online

Every bug is a feature

OpenOffice was originally developed as StarOffice by StarDivision, which Sun Microsystems purchased in 1999. Simon Phipps, now an ex-Sun employee, later claimed that "The number one reason why Sun bought StarDivision in 1999 was because, at the time, Sun had something approaching forty-two thousand employees. Pretty much every one of them had to have both a Unix workstation and a Windows laptop. And it was cheaper to go buy a company that could make a Solaris and Linux desktop productivity suite than it was to buy forty-two thousand licenses from Microsoft."

Sun released the code of StarOffice to the open source community. But for the sake of continuity Sun retained ownership and control of the developer process through StarDivision and the original developers of StarOffice. As a result, OpenOffice.org, the "open source" development tree of StarOffice, retains much of the proprietary software development process inherited from StarDivision, with an emphasis on a rigid Waterfall development process, with proprietary development tooling.

"There are serious systemic problems inside Sun," Meeks has said, "primarily in the QA department. For example, they would say that they can't understand how the Quickstarter could work in UNIX without a full specification, including screenshots of it, a description of what the function should do, approval by the user experience team inside Sun, and of course the help documentation team. They should all be involved, write a specification, and then you can actually write the code..."

By which time you have forgotten what it was you were trying to achieve, and have lost the incentive to make the changes. This rigid development model contrasts hugely with the free wheeling, itch scratching style of community development. "It's certainly possible to cruise along talking about all the marketing advantages of end-user communities," Meeks noted in 2008, "but in the end-game, without a focus on developers, and making OO.o truly fair and fun to contribute to - any amount of spin will not end up selling a dying horse."

As Meeks sees it, the conflicting demands of Quality Assurance, as they have been viewed by Sun's management, and responsiveness, as demanded by developers, is another of the major problems. "I would stress that there are people inside Sun that do 'get it'. People that are open, and helpful, and really good. But there are also a large number who are very traditional, very staid people, particularly in Quality Assurance. You can't argue with them, because they're in their own self-reinforcing world view. They say specifications are necessary for product quality, and you say 'That's fine, but look at the quality. It's still not very good.' They say more specifications are necessary! The answer is always more of the same, and you can't argue with that. It leads to obsolescence - quality through obsolescence, is what I like to call it. By not ever changing the product you can specify every bug as a feature, and hey! It's bug free. Instead, you really need to be getting changes in, fixing things and improving them."

Why aren't they?

The project "just needs some leadership and some vision, and some willingness for change," says Meeks. "It's very easy to get lost in the number of different problems there are, particularly on the developer side, and not to see the bigger structural problems that effectively cause those problems not to get fixed."

"Some of them are relatively easy to fix, but don't get fixed. I don't think there's really anything that complicated that needs to change. The ownership situation leads to a broken collaboration model, many fewer parties investing and contributing to OpenOffice than there could be. Whether you see that as a problem or as a feature probably depends on whether you think that owning and controlling the developer process is what you want to be doing."

“Ultimately the management only seems happy to take our code if they can, not only own it, but ensure that no-one else has access to it under similar terms. Copyright assignment itself is not an insuperable obstacle here – it is the gulf between the project license and complete ownership that is. Of course, we would prefer a uniform copy-left license, such as the LGPLv3, with no ownership, but Sun could not accept that. Perhaps it makes sense to do assignment to Sun, but mandate a (less optimal), more liberal license for those pieces written externally."

"We have a great product. There's no doubt about that, but in order to improve it as rapidly as we would like to see it improve, to extend the feature function range, and comprehensively win the feature / function / performance battle against our competitors it is necessary for everyone to work together, and grow the developer community. Even if we all work together, without more developers we can't achieve what we all want to achieve. But I don't see the developer community being prioritised. I don't see the decisions being taken that could grow it."

An offer of oblivion

Copyright assignment is one of those issues that can seem logical and fairly inconsequential to corporate interests, but "throws a huge spanner in the works" from the point of view of individual and corporate developers. Assignment makes it difficult to re-use the code elsewhere, and allows the assignee to re-license your code on their own terms. For example Sun has used their ownership of OpenOffice to agree patent protection with Microsoft that the project license does not allow. Indeed intellectual property right infringement is issue that has arisen with OpenOffice in the past.

"One of Sun's arguments against including code they don't own in OpenOffice is that you can do anything you want in an extension, and you can find what you want in an online extension repository. The sad reality is they have tried this approach with some really quite good functionality for the presentation viewer, but nobody knows it exists because it lives in the extension repository, and there are limits to what you can do with the repository. You have one million downloads of OO.o a month, and something like 10 thousand downloads a month of the presentation viewer. Only one per cent of people got it. The offer of a place in the extension repository is an offer of oblivion. There are a menagerie of inconsistent and incompatible licenses. Sun has packaged the MySQL client library which is normally GPL under the LGPLv3 license there, even though the source code is GPL." Recently the FSF has highlighted this confusion by announcing a project to assemble a replacement extensions library for OpenOffice.org which will list only those extensions which are free software.

"Just the idea that enterprise customers would want to download native code from some random site that is unsigned and run it on their network is barmy, and flies in the face of all the 'don't download things from the internet and run them' promises. There is no effective quality control of the extensions, no signing, nothing. So what Novell does is package those extensions that we identify as being good quality and useful, and we package them with our products and install them as part of the product, and users don't have to go hunting for something they don't know exists in some zoo elsewhere."

Next: The world's lamest brand

Print Version | Permalink: http://h-online.com/-1023702
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit