Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
If you can't, then the spaghetti talk applies.
Lotus Symphony code for OpenOffice coming soon
Posted May 19, 2012 14:43 UTC (Sat) by keithcu (guest, #58738)
The bug discussion you cite is exactly the sort of situation that could take place in AOO as well. Your solution of separate teams won't fix your problems. Your best hope for good behavior overall is to get lots of good people working together where the collective wisdom and size gives you the resources to do the right thing. If programmers upset current users, angry emails and bug reports will come in. Sometimes it takes a while to add a feature, and yet do it in a way that doesn't upset people who are used to some aspect of the old behavior. But it will usually get there.
I again repeat that comparing LO to spaghetti sauce is dangerously wrong. Malcom Gladwell isn't incorrect, only those who try to compare it to a reason for the OO / LO fork. It is scary that someone important would make this comparison.
Posted May 19, 2012 21:47 UTC (Sat) by chithanh (guest, #52801)
Maybe AOO will follow LO in imitating Excel for the empty cell behaviour or not. I wouldn't be surprised for either outcome. But the important point is that it's only one decision of many, and this is very much the spaghetti sauce lesson: a "one size fits all" product can never be as successful as a variety of competing products.
I fully expect that AOO and LO are going to diverge. AOO will start integrating Lotus Symphony code and possibly become more "enterprisey". LO has demonstrated a web frontend and collaborative editing which show a path in direction of the cloud.
Posted May 20, 2012 7:54 UTC (Sun) by keithcu (guest, #58738)
Your next argument is theoretical: that different teams will by definition diverge and therefore produce something that meets more people's needs. However, this idea is also flawed. What if someone wants a version with a mix of LO and OO functionality? Each place of divergence creates a potential for someone to become unhappy with either project. Instead of meeting more people's needs it can meet less. What you want is a version with the best work from everyone. You can work through these issues, adding options to allow for custom behaviors.
You also assume that both teams are healthy. What about the situation where one is a good, big team, and the other is new, small and floundering, mostly redoing the work of the older, bigger team, and never able to catch up? Would you not suggest in that situation those teams work together?
You continue not to realize that a codebase like LO is already deeply customizable. It has 10M of code which enable all manner of this. The whole point of this product from a user's perspective is to build custom documents. Every character you type and picture or formula you insert makes LO more personal. The best way to make it even more customizable is to add more code, not more teams.
You conclude by asserting new evidence for a good reason for divergence. I'll leave it as an exercise for the reader to ask such questions as whether LO wants more enterprise features like you imagine OO will add. Hint: here is a page from their wiki (http://wiki.documentfoundation.org/Development/Enterprise...)
Posted May 20, 2012 10:01 UTC (Sun) by chithanh (guest, #52801)
But that bug was only one example. The developers must make decisions all the time, and many have the possibility to make the software more palatable to one group and less palatable to another group of users. It is inevitable.
In the Apache meritocracy model, AOO will likely be dominated by IBM and their business partners, and TDF/LO is dominated by Linux distros. It seems preposterous to assume that the two won't diverge.
By "enterprisey" I do not mean incessantly integrating features that companies are assumed to desire or that IT professionals demand. I mean meeting the checklists of business deciders.
You claim that a version with the best work from everyone is desirable. I don't think it is even possible to create. Much like a spaghetti sauce that is after everybody's taste or a single Linux distro for everyone.
Posted May 20, 2012 13:51 UTC (Sun) by keithcu (guest, #58738)
Furthermore, the problem with generalizing is that you assume that you won't get a situation where users want half of the differences from one suite, and half of the differences from the other. Each difference decreases the likelihood that anyone will be happy. Either an idea is a good one, or it isn't.
The reason AOO and TDF/LO will diverge is because they have separate social structures. They could work through their issues. Both want better UIs, better DOCX support, etc. You should try to consider divergence, and multiple teams re-doing each other's work, as a bad thing rather than something to be celebrated.
Your distinction between the two sorts of enterprise features is nonsense.
If you can't understand the difference in customizability between LO and spaghetti sauce, you are highly confused.
I'll note you didn't respond to a number of my other points. When you consider that the LO team is better and larger, and can grab any changes from AOO, but not the reverse, it really puts into question the point of these separate trees. Anyway, you need to really focus on efficiency issues. This isn't about freedom. This isn't about whether anyone inside LibreOffice is complaining about wanting to create a new organization. When you strip away all your hypotheticals and look at the actual facts, the situation is a lot clearer.
Posted May 20, 2012 15:37 UTC (Sun) by chithanh (guest, #52801)
The assumption was only to show the point that LO cannot and will not satisfy everyone fully. There is no checkbox for the particular feature, and while maybe possible it seems not a priority to implement it.
> Furthermore, the problem with generalizing is that you assume that you won't get a situation where users want half of the differences from one suite, and half of the differences from the other. Each difference decreases the likelihood that anyone will be happy.
I never said that two office suites will satisfy everyone. I just said that (according to the spaghetti sauce example) they have the potential to satisfy more users than a single office suite.
> Either an idea is a good one, or it isn't.
> Your distinction between the two sorts of enterprise features is nonsense.
If that is true, then you have vastly more insight into business reality than I have.
> I'll note you didn't respond to a number of my other points. When you consider that the LO team is better and larger, and can grab any changes from AOO, but not the reverse, it really puts into question the point of these separate trees.
Sure they can. But will they follow each of AOO decisions? If there is a decision that makes AOO better for IBM's Windows customers, but makes it worse for everybody on Linux, do you really think that LO will grab this change?
> When you strip away all your hypotheticals and look at the actual facts, the situation is a lot clearer.
If you look at popular open source projects (Linux distros, desktop environments, text editors, programming languages, ...) you will see while superficially they seem to do the same - after all you can code Perl in vim running KDE on Debian as nicely as you can code Ruby in Emacs running LXDE on Slackware - there is a lot of diversity and there are very few high-profile exceptions where one project was able to fulfill the needs of everyone. There is no reason to assume that office suites are different.
Posted May 20, 2012 17:30 UTC (Sun) by keithcu (guest, #58738)
Again, you revert to generalities. I'm not going to argue there is never a reason for a fork. LibreOffice itself is proof that forking make sense sometimes. However, each situation is different. One interesting note is that there is no effort inside LibreOffice where people are complaining and wanting to fork. This is the sort of evidence that is relevant that I doubt you have considered.
You don't seem to understand my point about spaghetti sauce. With two divergent office suites, you could get a situation where people want bits from both suites. This situation can't happen with spaghetti sauce, but it can happen with software. When a software fork happens, it could make both products worse.
You don't need separate teams to add new features. Any good feature can be done in LO. You call this a false dichotomy, but I'm just trying to get you to understand the basic point that software is infinitely malleable, which is why the spaghetti sauce analogy to OO / LO is dangerously wrong. In any case, it is so fricking silly to compare tomato sauce to office software.
Another point you don't seem to realize is given that LO can take anything good from OO, but not the reverse, it will create a situation where LO will in general be provably better than. OO + LO > OO This is simple math. This is already true because LO has a head-start, a bigger and better development team, and the support of the community, but it will remain true over time because of the license agreement. It appears that this is also ignored by you.
You conclude with a totally irrelevant list of other "forks" as proof that this one is a good idea: LXDE vs. KDE, etc. Each situation is different.
In order to believe your ideas, you have to ignore a lot of specific information and think only in irrelevant generalities. You have an interesting perspective and method of reasoning. Your last sentence is illustrative:
"There is no reason to assume that office suites are different."
In other words: Assume I am correct.
Posted May 20, 2012 21:45 UTC (Sun) by rcweir (subscriber, #48888)
Software is absolutely nothing like how you describe it. You cannot just take an application and say it can be extended to do anything and to meet all user needs. Only someone with no practical experience in software development would claim that.
Sure, at a theoretical level you could say that all features could be included and exposed to users who want them, in an infinitely extensible model. But what about opposing priorities? One group wants to add Mono dependencies to LibreOffice while removing Java dependencies, but another wants to remove Mono dependencies and use Java for extensibility? Sure, do it all. It is only an "if" statement, right?
Another group wants to make the product be light fast, with only core features. But maybe another group wants to add new features. No problem, it is only code. We'll do everything.
The problem is doing A+B is not really cheaper than doing just A or just B. And even if you have more cooks in the kitchen to do A+B jointly this will necessarily come at increased complexity, and that increased complexity is the bane of quality, performance and schedule.
Remember, software reuse (and working together on one application is just a form of software reuse) is never free. It always comes with integration and coordination costs. The benefit is not always worth the cost.
If this were not true, then everyone would just be working on LibreOffice. Not just me, but everyone from AbiWord, Gnumeric, Calligra Suite, even Microsoft Office.
Posted May 21, 2012 1:12 UTC (Mon) by keithcu (guest, #58738)
You make a theoretically valid point that it would be hard if one group of people wanted to add Mono and remove Java, and another group wanted to do the reverse. However, that example is a dumb one for many reasons. The codebase is C++ and will stay that way for some years. Mostly development is about adding little features here and there, and there won't be such diametrically opposing interests. Consider a feature to support a new DOCX keyword. Or make it startup faster. Some users might want the former, and some might want the latter, but you can do both.
Here is a data point: Go through LibreOffice changes and find out how many AOO does *not* want. This is real data as opposed to the made-up reasons you offer. This is something you should have done at the beginning. If you find you want 99% of LO code changes, what does that tell you?
To understand why one team can meet all user's needs, learn about Wikipedia or the Linux kernel. The kernel supports many filesystems, and many other methods of extensibility, but the code is shared. Some want to run it on cellphones and some want to run it on supercomputers, and they've done it in one codebase. Stop me if you've heard any of this before.
Part of the reason why those products worked out so well is because lots of people worked together so the product could be the best of everyone's ideas. Your experience apparently ignores the existence of Linux and Wikipedia.
However, you are actually making a bigger mistake. You are giving made-up reasons for why the AOO project should exist. You are one year into this, and you still can't list actual reasons for what you are doing. Otherwise, you'd have come up with a better one than Java vs. Mono.
Compare your fork to the Ubuntu one. When Mark created Ubuntu, he did it because he wanted features that Debian didn't support. We can argue whether he could have added those features to Debian, but he at least *had* reasons. You apparently still do not.
I have never argued that people working on AbiWord should be working on LibreOffice. This is only about AOO versus LO. You like Chithanh bring up irrelevant facts. You also didn't sufficiently consider all the minuses to your plan. You also didn't retract and refine it when people objected.
The current AOO plan helps Microsoft and hurts LibreOffice. I know you work hard, but unfortunately it is basically a waste of time. It is something like building a house out of sand instead of concrete. You can spend a lot of time working on your sandcastle, but it will still be flawed at the end.
Posted May 21, 2012 13:42 UTC (Mon) by chithanh (guest, #52801)
I already mentioned previously in this thread "there is a lot of diversity and there are very few high-profile exceptions where one project was able to fulfill the needs of everyone."
Linux kernel is almost an exception, though not even fully. Or why do you think that Debian GNU/kFreeBSD exists? Of course GNU/kFreeBSD does not satisfy everyone either. Some people call it a toy OS even.
Wikipedia is the largest online encyclopedia, but that doesn't mean it satisfies everyone. Their crowdsourcing model is great for accumulating information. It is not so great if you depend on the correctness of a particular piece of information.
Posted May 21, 2012 14:49 UTC (Mon) by keithcu (guest, #58738)
Of course Wikipedia doesn't meet all needs yet. It is only 11 years old. And Wikipedia will not be the only resource. But the point is that it was able to incorporate diversity you care so much about.
You argue diversity is a good thing and therefore AOO should exist. It is an analysis so simplistic, it is possibly a tautology.
Posted May 21, 2012 13:16 UTC (Mon) by chithanh (guest, #52801)
You claim that I said "Any good feature can be done in LO" is a false dichotomy. That is misrepresenting what I said. Saying that an idea is either good one or not it is is a false dichotomy. This is what spaghetti sauce producers have been doing before: trying to achieve some platonic idealism of "best spaghetti sauce". Since being proven wrong, they have embraced diversity.
The problem that people want bits from two different spaghetti sauces does exist and is also described by Malcom Gladwell. Some people like plain and other prefer spicy. Some people large chunks and others like small chunks.
So if you increase the chunk size you make the spaghetti sauce more palatable to some consumers and less palatable to others. This does not mean that the idea "increase chunk size" is good or bad per se.
Then you say that "you could get a situation where people want bits from both suites. [omg! a generality] This situation can't happen with spaghetti sauce". Of course this can happen in spaghetti sauce too. With the two parameters spice/chunk size you can divide consumers into four (let's assume non-empty) groups according to preference:
With one brand of spaghetti sauce you can only satisfy one group fully. The classic platonic-idealism approach is that you should just go with the largest group.
With two brands however, you can satisfy two groups fully.
The fact that there remain users who are not fully satisfied by either does not disprove the point at all. On the contrary, it indicates that there might be an audience for a third office suite! (call it RedOffice, BROffice, OOo4Kids or whatever).
Whether the trade-off is worth it is a different issue. Your "OO + LO > OO" inequation suggests that you think it is not worth it. The sheer number of decisions that are made during development, and the fact that tastes are clustered according to Mr. Gladwell, makes me think that on the contrary diversity is preferable.
Posted May 21, 2012 14:33 UTC (Mon) by keithcu (guest, #58738)
You seem to think that with 2 products, you will make more users happier. You therefore don't understand the idea that people could want some of the AOO unique features and some of the LO. Unfortunately, in the real world of software, it is not possible. This is perhaps the biggest reason why comparing spaghetti to software is a bad idea. Another big reason is that the challenge with LO is not whether it needs more salt, but how are they going to get done everything they want to do. There isn't time to sit and taste the sauce. There are many reasons why I think the spaghetti sauce analogy is confusing you.
It also causes you to not recognize that you can add new features in a way to make the product more customizable. I remind you that Linux supports many file-systems. They don't bother trying to unify them, but they didn't need to make a separate team. You seem to pretend this scenario is not possible either.
Another reason it can be confusing to compare to spaghetti sauce is that people can customize LO to a massive extent already. The major point, however, is that you are arguing about spaghetti sauce because you don't have any real features. You might be able to explain the spaghetti sauce analogy very well, but you appear to be missing many more relevant facts about your own situation. I recommend becoming more curious.
"Whether the tradeoff is worth it" is actually a very big issue. Everything has tradeoffs. Do you believe considering the negative trade-offs is somehow an optional part of decision making? If you consider that your plan has lots of minuses, and that you are building a house of sand, it can also help you realize that thinking about spaghetti sauce isn't helping you.
Posted May 29, 2012 1:40 UTC (Tue) by chithanh (guest, #52801)
It seems you are still struggling to understand the results from the spaghetti sauce experiment. The premise is the following: A product has certain properties that are decided by the manufacturer and not customizable by the consumer. Some consumers prefer one outcome, and others prefer another outcome.
The hypothesis is that several products, each taking the decisions to meet a different consumer preference cluster, can lead to greater total satisfaction than one product that tries to accommodate everybody.
The data gathered from the spaghetti sauce experiment, and a number of follow-up experiments, supports this hypothesis.
In particular, the following are totally inconsequential (ie. not part of the premise):
1. Whether the products have other unique features
2. Whether any given number of products can fulfill the desires of everyone
3. Whether the decisions are discrete or continuous
4. Whether the products are customizable in other regards
Don't forget that "customizability" itself is a decision that can attract or repel users.
That the premise applies to LO was shown by pointing to the bug about empty spreadsheet cells. That AOO can make the same decision does not invalidate the premise.
If you want to argue against applying the spaghetti sauce results to office software, you have to either say that Mr. Gladwell introduced additional premises that don't apply here, or that the spreadsheet cells behaviour is actually customizable, or that everybody prefers the same behaviour. (For the latter two cases, the counter-argument would be pointing to the next bug of that kind.)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds