On Mon, Dec 29, 2008 at 7:29 PM, Andrew Sayers <andrew-ubuntu-de...@pileofstuff.org> wrote: > Speaking as someone with a strictly armchair interest in this topic, I'd > like to make a few observations here - > > The way (non-Sun) people talk about OO.o reminds me of the way people > used to talk about the pre-Firefox Mozilla project - worthy and > important, but with low developer morale due to an ugly, hostile > codebase. A certain amount of mud will always get slung at a project of > OO.o's size, and Sun often have valid excuses for the mud that gets > thrown their way, but I've never heard a community member stand up and > defend Sun's behaviour, or give examples of how Sun went the extra mile > to help them out. That silence speaks more to me than the noise on the > other side.
Political argument. On that field, are you suggesting +1 for sun's side "This has happened before, it's not a disaster, it'll iron itself out;" or -1 for sun's side "this happens, but they are handling it particularly bad and digging their own grave"? > Developing a good vocabulary of actions will be important in order to > improve the development process without suffering the upheaval that > would come from an x.org-style fork. If it's going the way of X, the better action once it's clear that this either can't be reversed or would take far too much effort to do so, would be to fork, and (from the sidelines) to encourage or "push" a fork. It's entirely up to each distribution how they decide to play politics in this case (see Debian/Iceweasel vs Ubuntu/Firefox, neither is "correct" in how they're handling it, it's just the distro maintainers' opinions), but they do have that weight and their visible actions cause those kinds of shifts. Up until that point, obviously, we either A) expect that things will get better; or B) expect such a shift will be more damaging (to reputations, to development of the new fork, to the community, etc) than helpful right now. > > Towards the subtle end of the scale, Go-oo makes it possible to start > referring to the Sun codebase as "Sun's tree" rather than "upstream", > forcing Sun to earn their reputation as the "true" version of OO.o. > Towards the drastic end of the scale, Go-oo could request that Sun pull > the patches they're interested in, rather than getting patches pushed at > them with whatever extra paperwork they request, putting the cost of > Sun's bureaucracy back on Sun's balance sheet. Interesting strategy; however Sun has shown either A) they don't care enough to integrate feature X; or B) they do, but since you won't dual-license it and sign an agreement transferring copyright to them, they'll just expend their resources writing their own. Forcing Sun to pull would, in essence, be an attempt to force them to abandon their practice of having contributors sign a JCA, as anyone dissenting against this can contribute to the fork (Go-OO), effectively forcing most developers away and creating a bigger community draw to the fork, stagnating OOo or forcing them (as I said) to simply abandon the core goals of the JCA and pull, pull, pull... In other words, the "Pull" strategy WILL hurt Sun, and WILL take OOo out of their hands; the workload to reproduce significant features submitted to Go-OO would pile up too fast, and the project will become more and more feature-complete over time. With the ability to pull from Sun's tree without consequence, Sun simply can't catch up to this, and can only shut down open source OOo development. Eliminating their JCA would prevent them from shipping Star Office as-is, presumably; although Go-OO is LGPL and Sun could get away with using modules without LGPL-ing their code if they integrated such code. That, of course, would be the action of Go-OO or such a fork (though Go-OO is probably the largest; OxygenOffice and a few others are based on it). If it does happen, be very worried for Sun's continued control over OOo, as it'll be in jeopardy as soon as that fork gains momentum. > > So what does this mean for Ubuntu? Mainly that we need to weigh our > actions not only in terms of what produces the best short-term results > for users, but also whether the message it sends will improve the > process in the long-term. True. Again, my interest is in understanding the current situation and figuring out what'll happen in the long term; although I wouldn't mind getting there faster... > As Joe said, publicly ditching the upstream > OO.o would send far too negative a message right now. Depends on what message you want to send. Again with Debian/IceWeasel, if Shuttleworth and friends want to send the message, "Abandon ship, Sun sucks," and try to force an X fork, this would be the strategy to use; maybe now, maybe later. If that is NOT what Ubuntu wants to do (I'm pretty sure it's not), then they need to simply be quiet. On an aside, the drama would be academically amusing. I think Sun would actually shit bricks. Maybe I'll make a Demotivation poster satirizing this... > If Sun continues > to drag its heels, the next move might be to start talking about how > Ubuntu adds value over the "basic" OO.o, putting some gentle corporate > pressure on Sun to get their act together. > Talking yourself up is just that--Ubuntu ships everything with patches that improve it, every distro does. We're a little ahead of the curve here, good for us, install our software! It still says "OOo" and people aren't going to say to their Windows-using friends, "Install OOo Ubuntu Edition, it's better;" nor will Fedora start using Ubuntu's OOo. This would just talk up Ubuntu, and the net impact would be the same: people would use OOo on Ubuntu and install it on their non-Ubuntu machines too. I had a relationship with a company that did security consulting once. We had a partnership with another product-based company that made very poor software. The software had to be configured basically to handle multiple sites if your site was too big-- not a licensing restriction, but rather a technical problem with scalability. It was also fairly unintuitive and prone to misbehave anyway. Our relationship was rather interesting: we could supply Product X, but also point out how we could relieve your frustration with Product X by helping to configure/improve it. This is the same sort of relationship with pushing OpenOffice.org and advertising that you ship some "Improvements": our business resulted in more sales and increased popularity for Product X, and lessened corporate pressure because we handled the mess they made by alleviating their clients' frustrations with our expertise. It's kind of all-or-nothing; "pressure" comes in the form of arguing with someone, or publicly criticizing them. Hints don't work. Stepping into that arena makes things rough, because you can't maintain good faith; and once you put your foot down on the "it's time to fork" or "this fork is simply better than the source" line, you can't backpedal, because the whole atmosphere changes. It kind of sucks, actually. > - Andrew > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
