To be honest: No, because I wouldn't be anonymous anymore
Nice - so you say we have a load of bugs, but you don't want to tell us what they are ? the Coward title you hide behind is perhaps well chosen. Please file your bugs in an appropriate way. If we are chucking un-verifiable allegations around, I will infer from your reticence that you work for Sun, shame on you for hiding that.
Novells Cowboy Coders might be successful in hacking minor features on the OOo codebase. However: they add instabilities and bugs because these "small hacks" arent sufficiently designed, documented and tested
Give some examples of such instabilities and bugs please. Perhaps they are worse than some of the amusing howlers in Sun's OO.o 3.0 - lets see.
having this kind of development in the core elements of OOo would render the codebase unusable in a few years (yes, the current code quality is bad - so everything possible should be done to raise to quality, and rotting the code further should be avoided)
Ah - this is definitely a Sun developer talking, and yes the code quality is pathetic in places - but it is amusing that your "everything possible" excludes the inclusion of a large volume of new code re-writing and fixing the older more broken code, even at the expense of the occasional regression.
Yes, they where communicated to the Novell guys. I cant go into specifics, because I wouldn't be anon in the OOo microcosmos anymore.
So - thinking back over the last year and the (non-)communication of bugs I can think of perhaps a single instance here which is basically a mis-understanding. This also suggests that you work in the writer team; as a brief example of the outstanding engineering going in there, I personally love things like the comment in calcmove.cxx:
Workaround for inadequate layout algorithm: suppress invalidation and calculation of position, if paragraph has formatted itself at least STOP_FLY_FORMAT times and has anchored objects. Thus, the anchored objects get the possibility to format itself and this probably solve the layout loop.
Nearly every paragraph in the "article" begins with a disclaimer that the data (and/or the analysis) are flawed
So - you really should read more than the first few paragraphs. Try the 'Activity Graphs' section:
Extending this metric to the entire project we see perhaps a more interesting picture
So, it should be clear that OO.o is a profoundly sick project
Clear? Clear based on all those assertions they made about their data being dodgy? Yeah, umm, ok.
I'm sorry, but this is article is very hard to take seriously.
is hedged with equivocation to be sure, with extensive and clearly labeled caveats. Having said that by processing the noisy data we get a meaningful signal out of it I argue - the data is available if you want to reproduce it, and as yet there is no published analysis of it that I'm aware of that looks any different. The underlying reality should be clear. Given that I use the same metric on the Linux kernel - and the comparison shows a huge gap in terms of growth and activity I hope people can make up their own minds; seriously or otherwise. Better still - people can help fix the problem by getting involved in OpenOffice development - that is my hope at least.
OOo is quite healthy. However, Novell seems to be profoundly sick: They arent even keep their employees in line.
Your proof by assertion is substantially un-convincing. What line should employees be in ? read the disclaimer at the bottom of my blog: this is my point of view as a long time OO.o contributor. Can you substantiate any of the big problems you allege in go-oo - I'd love to help fix them - I am not aware of any. Is it really negative PR to point out a serious problem that afflicts us all, and ask people to help fix it ? how about showing the growth of Linux contribution - is that negative PR for Open Source ? - there is some kick-ass success happening there to emulate: why does Linux succeed and grow where OO.o shrinks ? you know my answer - what is yours ?
Either that, or its just incompetence.
Hey ho - mindless, incompetent rants - more than likely, but ones actually backed by data: if you can't play the ball try the man instead - sometimes he is softer. My data set is public, as are the scripts to generate it - be my guest: point to the error in the analysis.