Open Office, IBM, and Sun: Worlds Apart, or Just Miles?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

One thing that’s sure about open source is that there’s never a shortage of controversy. The latest such flap that I’ve gotten a few questions on now concern the flagship OpenOffice.org project, and the relationships of IBM and Sun with said project. Joe Brockmeier’s post here sums up some of the issues, taking a decidedly pro-IBM (or anti-Sun) stance.

Before I get to my Q&A, a bit of disclosure: both IBM and Sun are RedMonk clients. So drop in your skeptic lens before continuing if you feel so inclined. Otherwise, here’s a few of the questions I’ve received and my own answers.

Q: Why do you think IBM doesn’t contribute to the OpenOffice.org project?
A: First of all, I have not confirmed that this is the case with IBM, although I will be seeking further information shortly. Presuming that it is true, however, I think this comes down to how development is done, not licensing concerns. Brockmeier cites the licensing of OpenOffice.org as an issue, in that contributions to OO.o could end up in Star Office, and asks, “Is it any surprise that IBM isn’t chomping at the bit to do some of Sun’s development for them?” Personally, I think if there’s any Sun product that threatens or worries IBM, it’s certainly not Star Office. Further, IBM, by contributing to Linux, has already contributed indirectly to competitors such as HP or Oracle. So the licensing, for me, is not an adequate explanation of the situation.

If instead we look at how the OO.o code is employed – as the underlying engine to provide basic office productivity features in Workplace – it’s clear that IBM is not working off of the native codebase. In short, it’s a fork. A fork that’s about the open standard, not the open source. As such, it’s reasonable to assume that contributing back to the original project is made more complex. That’s my guess as to why IBM does not contribute back, but that’s all it is – a guess.

Q: Should IBM contribute back to OO.o?
A: This is a more complicated question. First I’d ask, as a user of OO.o, would I like them to contribute back? Yes. Next I’d ask, do I think it’d be in IBM’s best interests to do so? Depending on how different the two code bases are, I’d give a qualified yes to that one as well. But to answer the original question, should I expect or demand that they do so? No. I say this for two main reasons: first, they’re well within their legal rights to do precisely what they’ve done, second, IBM has in other areas proved to be a very functional and community aware participant, so I don’t think it can be argued that they’re being parasitic here or anywhere else.

Q: So you’re against Sun and OO.o too?
A: No. Again, as a daily user of the application I understand perfectly where they’re coming from. And while I support IBM’s right to operate as they have, I don’t think it’s in the best interests of either IBM or OO.o. In short, I support IBM’s right to choose in this situation, but that does not mean that I have to like the choice that they’ve made.

Q: Well, what would you like to see happen then?
A: I think IBM becoming an active, major participant in OO.o would be beneficial for all three parties (and no, I don’t see the benefit to Star Office as being an obstacle to IBM participation). From what I understand, they’ve streamlined the codebase somewhat for inclusion in Workplace, and it may well be that the main OO.o project could benefit from that sort of crash-diet. One of the problems OO.o has now is the size of the codebase, and there are two main approaches to combatting that problem: bodies, and refactoring. IBM could obviously help on both counts.

Q: One last question: you mentioned before that you think it’s in IBM’s “best interests” to contribute back to OO.o. Can you say why?
A: As anybody involved in the open source world can tell you, forks of a codebase come with a fairly high price tag. The good news is that you can tweak the codebase to do exactly what you want; the bad news is that you are unlikely to benefit from innovations and updates down the line. In this specific example, IBM may have forked the OO.o codebase out of necessity, to integrate it into Workplace, but that means that future improvements to OO.o will have to be refitted manually on a case by case basis. Not a particularly useful way to spend time. So the question then to me is: are there modifications that could be made to OO.o (componentization, perhaps?) that would allow IBM to integrate it without a fork? I frankly don’t know the answer to the question, and maybe IBM’s already determined that the answer is no, but that’s the course that I’d like to see pursued. A more embeddable OO.o would be a significant improvement, not to mention differentiator vs its main competitor.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *