Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Software Sun Microsystems

Lack Of Developers Delays OpenOffice.org 84

Posted by timothy from the it-will-be-good-though dept.
bonch writes "OpenOffice .org contributors spoke this week at a conference in Canberra. Among other things, one of the issues raised was the lack of developer contributions and a source tree that is 'just too big.' Version 2.0 was originally going to be released around this time but will now be delayed until at least June or July."
This discussion has been archived. No new comments can be posted.

Lack Of Developers Delays OpenOffice.org More

Lack Of Developers Delays OpenOffice.org

Comments Filter:

  • break it up (Score:5, Interesting)

    by QuantumG ( 50515 ) <qg@biodome.org> on Wednesday April 20, 2005 @05:57PM (#12297468) Homepage Journal
    seperate all the different apps so users have the choice of which components to install and developers can focus on a single part of the code.

    • Re:break it up (Score:1, Interesting)

      by Anonymous Coward
      Too much of the code is shared by all the apps, as it should be... no need for all the apps to reinvent the wheel. The framework on which the individual apps are built is simply too big and bloated for some people to cope with.

      • Re:break it up (Score:5, Insightful)

        by QuantumG ( 50515 ) <qg@biodome.org> on Wednesday April 20, 2005 @06:17PM (#12297655) Homepage Journal
        Yeah, I was just lookin' at their "solver". Pfft. All well and good for developers but the user's options are basically install-OpenOffice-or-not. It's not like GNOME doesn't have the exact same issues. The problem there is solved by the packagers who make apt and rpm dependancy trees. Of course, what's going to happen is that people are going to keep contributing to other projects and they will soon supercede anything OpenOffice has to offer simply because they are easier for people to get.

      • Re:break it up (Score:3, Insightful)

        by Bastian ( 66383 )
        What, has the world suddnely become a bizzaro parallel universe where it's impossible to componentize frameworks or use shared libraries?

        Somebody better make sure that the operating system developers realize that they are all living in violation of the laws of nature, and make them quit before they destroy the fabric of space-time.

    • Re:break it up (Score:4, Informative)

      by Bastian ( 66383 ) on Wednesday April 20, 2005 @06:15PM (#12297633)
      This is something that I agree that OO.o sorely needs. I imagine that many users find it particularly annoying that if they want to, say, create a new spreadsheet, they must launch OO.o, which puts them in Writer, then go to File->New Spreadsheet in order to get to Calc. Possibly it is different on other platforms - the OS X port is certainly messy in a lot of other ways - and possibly there is a way to create a set of executables that open different portions of OO.o, which is good. But it's the default behavior on my port, and it's nothing but asinine.

      Normally I'm very dedicated to using OSS, and am willing to put up with a rough GUI and give a Free project some slack. But OO.o makes even Microsoft Office seem clean and intelligible, and that's frightening.

      In a development culture where there is a very direct connection between loss of user base and loss of developer base, maybe the biggest thing that OO.o needs to do to attract developers is quit focusing so hard on creeping featurism and put some serious time into giving the interface a major overhaul.

      • Re:break it up (Score:3, Informative)

        by kosmosik ( 654958 )
        > I imagine that many users find it particularly
        > annoying that if they want to, say, create a new
        > spreadsheet, they must launch OO.o, which puts
        > them in Writer, then go to File->New Spreadsheet
        > in order to get to Calc.

        I don't know what you were using but it is like that:

        * On Windows you either choose "New spreadsheet" from quicklaunch menu (one in system tray). Or choose "OpenOffice.org Calc" from Start Menu.

        * On Linux it is basically the same - you choose your app from menu or from
        • Hmm. . . I suspected that.

          I imagine the problem is because the OO.o binaries I downloaded were provided in the form of an application bundle, which isn't conducive to having a single executable that can varying runtime behaviors.

          It would have been a lot better to provide the OO.o binaries as standard Unix-style executables stored at some standard place on the hard drive, and then provide a separate set of OSX-style apps that act as covers which just fire up X11 and then can send the proper command-line a
        • OO is usable on the Mac, however having to use the X11 interface is annoying...

          NeoOfficeJ is the Mac Clone of OO and is perfectly usable in the native OSX environment..

      • Possibly it is different on other platforms - the OS X port is certainly messy in a lot of other ways - and possibly there is a way to create a set of executables that open different portions of OO.o, which is good.

        The Windows port does exactly that.

        Start/Programs/OOo/various clickies to different OOo apps.

      • I imagine that many users find it particularly annoying that if they want to, say, create a new spreadsheet, they must launch OO.o, which puts them in Writer, then go to File->New Spreadsheet in order to get to Calc.

        Hey, why not run "oocalc" instead of "ooffice"? That opens up the spreadsheet program instead, at least in 1.1.4 that I'm using. I'll leave it as an exercise to the reader to discover oodraw, ooimpress, oowriter, etc.
      • What are you two on about? The installer lets you choose which apps to install, and there's a separate icon for each one.
    • I don't think giving the users a choice as to which components to download and install is going to help with the developer shortage.

      I've downloaded the code, and it seems to me like the reason they don't have enough developers is because the project is so big that it takes a very long time for developers to learn enough about how it all works to be productive. Also, there is a lot of missing documentation that helps to make the software look very overwhelming to a programmer wanting get started on helping

      • The two are intimately related. Developers start out as sophisticated users. They are the people who will do apt-get install oo-writer look at the dependancies, grab the -dev versions of those dependancies if applicable, and then go download the source to the one component they are interested in working on. Documentation is great and all, but I don't know all that many programmers who go looking for it first. I went to the OpenOffice web site today to download the source, saw the bastard that is the "so

  • unjavaize it (Score:2, Interesting)

    by chris_mahan ( 256577 )
    Nuff said.

    • They're using Java, in part, because it makes it easier to write the code. I don't think that would help. (But they are short on numbers, apparently, so feel free to join and recode it in OOo's C++ if you want.)

      • Re:unjavaize it (Score:3, Insightful)

        by BRSloth ( 578824 )
        They're using Java, in part, because it makes it easier to write the code.

        Well, that's a good reason. But, in other hand, if you look the communities of developers in the FLOSS world, you would see that very few really accept the terms in Java licence. So, by using it, they make easier to write the application, but turn some developers around.

        Easier to write or more developers: pick one.

        (Note: I'm not saying that FLOSS developers hate easier to write languages, they are more interested in the licence of
    • Even C would probably be faster to develop.

      I'd like to see the hardest stuff done in C or something else a bit (faster and) more debuggable than C++ and invoked from a Ruby shell. Development would flog along, then, and anything that turned out to be really useful (ie invaluable to a few people or mildly useful to many) can if necessary be converted to C and hand-optimised for speed. I say "if necessary" because Ruby turns out to be startlingly efficient from time to time.

      But yes, divorcing it from the re

      • Re:And convert it from C++ to something useful? (Score:3, Insightful)

        by Anonymous Coward
        I'd like to see the hardest stuff done in C or something else a bit (faster and) more debuggable than C++ and invoked from a Ruby shell.

        Wait a minute - you think the solution to a lack of developers is to switch from a mainstream language to what is, if you'll forgive the intrusion of cruel reality, a language known only by a vanishingly small minority of coders, which has a reputation for being very slow (not good for desktop apps) and for not being able to do Unicode (not good for office apps)?

        As I sus
        • That said, Ruby is not lightning compared with C, but OTOH you can get reliable, functional things written in it far faster than either C or Java. The advantages are that Ruby:
          • is far lighter weight
          • is more likely to be actually enjoyable to write code in
          • is completely Open
          • is highly portable
          • has already been integrated into lots of other stuff

          It might also cause some rearchitecting, which has done other projects (Samba4, KDE, Mozilla, Apache) a world of good. Ditching the jmillstone and debloating the mon

        • Ok fair enough ruby is not on the scale of java , but it is not in the realms of a toy language .
          Ruby has a rather large amount of librarys , it has projects like Ruby on rails and allows extremly rapid prototyping and full blown applications (GUI , web or shell) .
          It may not have the users base of the big boys ,but its well beyond toy language status. infact technocrat.net is replacing an ammount of slashcode with Ruby IIRC as an example.

          Your right its not known by as many people as it deserves to be , h
    • How will moving it off of Java make for faster development?

      • Short story: more people will be able to work on it, it will be more portable and more fun to work with, such a change is likely to cause beneficial rearchitecting.

  • Mozilla Suite? (Score:3, Interesting)

    by xPhoenix ( 531848 ) on Wednesday April 20, 2005 @06:00PM (#12297506)
    Maybe what happened to the Mozilla Suite needs to happen to OpenOffice? No doubt this would be a huge undertaking, but I wonder how plausible it would be to componentize OpenOffice? Instead of OpenOffice.org Writer, how about Writerfox, or BirdWriter, or .... um... ThunderWriter...

    • Re:Mozilla Suite? (Score:3, Informative)

      by bcrowell ( 177657 )
      If you were to break OOo up into smaller parts, then you'd have a word-processor, a spreadsheet, etc. But wait, there are already open-source word-processors (AbiWord, KWord, ...) and open-source spreadsheets (gnumeric, Kspread, ...). So then what would be the reason for OOo to exist? What would make it distinctive?

      The article just seems like a clear admission that the whole project was badly conceived from the start. Some things that just seem like obvious blunders to me:

      1. The design is monolithic. That
      • I've bashed OOo in the past, but you're wrong on two of three points.

        Monolithic Design

        The OSS world *needs* a consistent set of office-suite apps. Preferrably as many as necessary, sharing as much as they care to. There are lots of word processors, and spreadsheets, and all that, but if you can't take your extant intermingled data and toss it to and fro, or teach your entire bundle in a single one-week course to a bunch of users, your application is needlessly expansive.

        Would it be good if OOo was mo
        • The OSS world *needs* a consistent set of office-suite apps.[...]but if you can't take your extant intermingled data and toss it to and fro, [...]
          I agree with you that inconsistent UIs are a problem in OSS, but that's a whole separate issue from interoperability. Two programs could share a consistent set of user-interface conventions, and yet be totally incompatible in their file formats. On the other hand, LaTeX and GIMP have completely different user interfaces (if LaTeX could even be said to have one :
          • Even if all 10^7 lines of code could be thoroughly stabilitized today, it could get completely broken tomorrow because MS would come out with a new version of .doc.

            Except that MS cannot do that.

            If Word 2005 had a brand-new format, they would lose their biggest selling point to have everyone who uses Word 2000, XP, or 2003--the constant .DOC format

            And MS *did* introduce a new format in 2003. WordML, an ugly XML format, that OOo *already* has an importer for. MS breaking DOC isn't just an urban legend--
          • Part of the problem OOo has with attracting developers from outside Sun is that its codebase is too big, and part of the reason its codebase is so big is that it supports .doc. .doc support is one of it's biggest selling points. Any office suite that wishes to gain any kind of market/mindshare MUST support .doc, simply because that is the format currently in use by the vast majority of office suite users. Dropping .doc support would be the kiss of death for OOo.
      • We'd be better off if OOo had never even existed.

        That's a terrible thing to say, considering that OO.org works pretty well. You try to be so pessimistic about OO.org, but the fact is that only Gnumeric is really a solid alternative (the others are nice but not as mature). Also, the .doc compatibility is a 100% must-have feature, there's no way around that.

        Overall, the only problem with OO.org is that it is just freakin' huge. They just need to cut out the dead stuff, refactor the non-dead stuff, and g
      • When was the last time you tried AbiWord? I help with Windows QA, and we've advanced by leaps and bounds recently. Recently a really great QA guy has been methodically finding just about every obscure and non-obscure crasher bug you can imagine, and a similarly great coder who's been with the project a lot longer than me has been fixing them lickity-split. It's worth another look.

  • heck yeah (Score:5, Insightful)

    by LeninZhiv ( 464864 ) * on Wednesday April 20, 2005 @06:07PM (#12297562)
    I can vouch for this... the OO.org 2.0 beta has so far required non-RPM Linux users (or those who want to have a single-user installation of the beta version) to build from source--and I can say that it is a frightening endevour! (This coming from one who has built Gnome from source in the past and who is still daunted by the prospect of building OO.org)[1].

    I was recently looking at open source projects that I might contribute to, and-- in my case at least --OO.org was counted out on the basis of build complexity. Cloudscape and other projects are where I've been putting my free time simply because becoming a 'casual contributor' to OO.org seems to be an unduly complicated process.

    The solution? Simlplify the build process for the casual coder. This will have the added benefit of helping other Linux distros and UNIX versions more easily support bleeding edge OO.org. And on the development side, potential contributors of the odd functionality (as I would characterise myself) will not be scared off.

    As I understand it (probably imperfectly), Linux has gone through the same growing pains in arriving at its current module architecture. I think this is a housekeeping step OpenOffice.org needs to dedicate resources to, and needs to dedicate them NOW, to clean things up to at least the level of the what the 1.x versions had where it was easy to compile[&|]install a single-user version, unlike the 2.Xs where it's a real workout.
    ----
    [1] And this is also from one who also has no problem with contributing Java code despite the recently publicised Java issues [slashdot.org] in OO.org 2.0.
    • Mozilla had this same issue as I recall. Abandoned code and a gigantic, ugly code base were real problems back at Moz's inception.

      Hopefully the OO.o guys can break through this barrier and attract some new blood to bring it to a Firefox level of popularity.

    • In the case of debian, OO need to figure out the -dev.apt system. If I want to hack on some component of GNOME that has a lot of dependancies, I can just grab all those dependancies as -dev packages and compile the source for the component I'm interested in against those .so files. No need to compile the freakin' universe.
    • > the OO.org 2.0 beta has so far required non-RPM
      > Linux users (or those who want to have a single-
      > user installation of the beta version) to build
      > from source

      No it has not. You could build from source but in fact you just could unpack RPMS and copy files to their locations - and it would probably work (I don't know which obscure Linux distro you was using). Also most Linux distros worth using has something like developement versions - so you simply grab packages from developement tree. It is
    • It is possible extract the rpms and use them on practically any linux distro. I've been using the 2.0 beta release on gentoo and we have an ebuild that does it automatically. You can extract an rpm like this: rpm2cpio foo.rpm | cpio --extract --make-directories
    • I can vouch for this... the OO.org 2.0 beta has so far required non-RPM Linux users (or those who want to have a single-user installation of the beta version) to build from source

      I just used rpm2targz which is a standard utility on Slackware.

  • ugh (Score:1)

    by orufet ( 873172 )
    it's been too long waiting already, damn it!

  • This is mostly a 'well, duh!' moment (Score:5, Interesting)

    by SunFan ( 845761 ) on Wednesday April 20, 2005 @06:37PM (#12297848)

    OO.org is 10 million LOC, now. That's bigger than most developers ever touch let alone see. Hell, I used to work full time on a program that was only 100K LOC, and I couldn't imagine wrapping my head around 10 million.

    As much as I love using StarOffice/OO.org, I'd be hard pressed to become a developer in my spare time. I think what would serve Sun best is to invest heavily in their dedicated OO.org devlopers--give them the best workstations, the best debugging tools, the best profilers, etc. No holds barred, just make their time well spent.


    • Sorry to reply to myself, but one other idea would be to dedicate a developer or two at just using 'lint' on the whole darned thing. Getting some of that bloat down always helps new developers.
      • Better yet, the whole thing needs a good dose of refactor mercilessly [extremeprogramming.org], similar to what X.org has been doing.
        • It's good to hear X.org is stepping back and refactoring. I think all the major FOSS projects could use a breather, where new development is stalled for a few months while things like memory consumption are addressed, known performance bottlenecks are given a little more attention, etc.

          GNOME, Mozilla, OO.org are all useful enough feature-wise, right now, that doing some serious polishing work would take them to the next level against Microsoft. I find GNOME, for example, to be very adequate in most every
        • "Better yet, the whole thing needs a good dose of refactor mercilessly, similar to what X.org has been doing"

          Sure. If you can't get developers to create new stuff I'm sure you can find more who would be willing to work on a refactoring effort that won't add any functionality for a few years.

          If the design is really that bad you'd be better off rewriting it from scratch than refactoring it.
          • Um, better performance is a functionality. Faster startup times is a functionality.

            Also, refactoring isn't an either/or, it's both. Nothing precludes you from refactoring while you add features. In fact, Martin Fowler (who wrote "Refactoring") says:

            When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

            As for "rewrite vs. refactor", that mig

            • Um, No. Performance may be important, but it's not functionality.

              In any case, refactoring isn't necessarily about performance (note that Martin Fowler's quote is about refactoring to change the structure of a program, not to make it faster).

              "As for "rewrite vs. refactor", that might be true for relatively small changes, but when you're talking about a large project like OOo, you don't want to throw the baby out with the bath water."

              Rewriting isn't necessarily throwing everything out but rather creating a
        • Since you ask we need someone to refactor out the three string classes to just one. Thanks for your offer, we accept.

  • "Only 4 active community developers" (Score:3, Insightful)

    by Truth_Quark ( 219407 ) on Wednesday April 20, 2005 @08:09PM (#12298499) Journal
    I wonder if the problem is partly Sun's PR issues with the OS community.

    They certainly have a worse public image than IBM, and I wonder if people use OO because its free, but don't really feel part of the project because the SUN associtaions.

    Phipps said Sun welcomes contributions from both individuals and organizations that use the productivity suite, including big names Like IBM. "Ask IBM why it uses OpenOffice but doesn't contribute to it," he said.
    It seems to me that IBM and others (like Oracle), aren't playing nicely with SUN so much.

    Which is all a bit of a pity, because OpenOffice is the single main application that advances Linux as a useful OS on the desktop.

  • Rip out the custom widget set (Score:1, Interesting)

    by Anonymous Coward
    Really! How many of those 10 million lines is the widget set? I know ripping it out would be a huge job, but maybe OO would become maintainable as a result.
    • Actually I think it's wierd that noone else has mentioned this really.

      I'm a kde developer, and have from time to time contributed to OO.org, and actually signed the agreement they force you to sign to contribute.

      But because I'm a KDE developer, I feel that my time is better spent with koffice. Having the word processor integrate seemlessly into KDE is very important to me.

      I think a very large percentage of developers are are GTK or QT/KDE developers, and don't like to develop outside that as it doesn't
      • I'm a kde developer, and have from time to time contributed to OO.org, and actually signed the agreement they force you to sign to contribute.

        *sigh* You have to sign an agreement to contribute to OOo?

        I had no idea things were that bad.

        • Yeah - it basically says that they are allowed to joint license all your code under GPL and under a proprietry license that they use for StarOffice so that they can use your code in StarOffice.

          I'm surprised people haven't mentioned the agreement as a barrier - i guess most just haven't even gotten that far :)

          P.S. What does your sig mean? All 'laws' in physics are theories. Everything in physics is just a theory.

          • I used to work for Sun until very recently. I am very frustrated by their methods of communicating with "the community." I fear that the PHBs still don't get it.

            P.S. What does your sig mean? All 'laws' in physics are theories. Everything in physics is just a theory.

            The religious loonies are going around saying, "Evolution is only a theory," just now.

            • Ah, the religious loonies.

              The example I use is gravity. Just because every time before you dropped a glass it fell to the floor doesn't mean we can prove that it will fall when I drop it now. It's just that all the overwhelming evidence points to that it will.
    • The point I made in my talk was that you HAVE TO find a specific part of OOo and carve out your niche. Trying to understand the whole thing is an impossible task as you say.

  • I guess I'm one of the four (Score:5, Interesting)

    by LoveMe2Times ( 416048 ) on Wednesday April 20, 2005 @09:57PM (#12299178) Homepage Journal
    At any rate, I was one of the first non-Sun employees to contribute. This was before Novell, if I recall, about 3 years ago. I believe I'm still one of the few people outside Sun and Novell to hack on the C++ side.

    So here's a little insight from the inside. I have had a *lot* of frustrations over the years working on OOo. I know why there aren't many other developers outside Sun working on it. Getting to the point where you can hack on stuff and do your edit/compiler/debug cycles requires dedication. If you aren't being forced into it, it'll never happen. I work on OOo at my job, or I'd never have made it either. It took 2 or 3 weeks to get the OOo 2.0 enivornment set up to where I could edit/compile/debug. Part of the problem is that they aren't distributing solvers for 2.0 snapshots due to resource limitations. The reason it takes so long is because I don't have a spare machine to compile on, so I let it build overnight. Of course, when there's an error, you don't see it until the next morning. If you're not comfortable editing makefiles (and non-standard makefiles, OOo uses dmake, not gnu-make), or working with CVS (some files had to be manually retrieved from the attic), working with a unix shell (I'm a bash guy, but they use tcsh which drives me nuts), etc, you stand no chance in hell. And yet, I am *thrilled* by the progress that's been made over the last few years. The build is a million times better/easier than it was. I'm pretty confident that these last few wrinkles will get ironed out, and when 2.0 final comes out, you'll be able to follow the instructions and it'll "just work."

    Now, once you get to the point where you can hack, you'll run into the next problem. While the code may be open, the development process is only sort-of open. Since all the main coders work at Sun, you pretty much stand no chance in hell of doing work on core components, except bugfixing. So, for example, don't expect to sign up to the mailing lists and have any clue what people are working on. Don't expect to be informed of major changes coming down the line unless you have somebody on the inside to give you the scoop. Don't expect to get involved in design discussions, don't expect to have any input on scheduling, don't expect to be consulted about anything except when you're going to fix bugs in your code, don't expect to gain influence in the project over time as you become an established, respected developer. In short, don't expect anything that you would normally expect from an open source project. You will perpetually be an outsider, a non-employee, unpriviledged. Don't get me wrong, you'll gain respect and credibility over time--it's just that won't turn you into Sun management (duh), and Sun management makes decisions for the benefit of Sun (duh) without consulting Joe Random Developer (not too surprising). However, that said, if you want to work on peripheral things, plugins, extras, etc, and don't care much about when or if or how your stuff gets included in OOo official, the devs are really good about helping you out. Also, if you do this as your day job, you may be able to muster some more clout, especially if your company is going to make serious ongoing contributions.

    So I'm hopeful that once OOo 2.0 comes out, more of a community will form as the build difficulties ease up. Will the community ever take control and set the direction of OOo, where Sun is just one player? Doubtful. Will the community fork OOo becuase of this? Maybe. Does it matter right now? No. Sun's doing a pretty good job, IMHO.
    • Will the community fork OOo becuase of this? Maybe.

      Maybe? It's already happened. [neooffice.org]
    • If 100 people grabbed the codebase and started extending or refactoring it independently of Sun, how would Sun react? I don't know how NeoOffice interacts, but maybe think NeoOffice on steroids?
    • Nice post, informative.

      The piece that most interests me is the "If you don't work at Sun you don't participate in the core stuff", which means what while they open-source the software they don't open-source the design process (public mailing list with public archives, irc) which means they are still in a command and control mode.

      This is most likely why they don't have more than 4 active contributors.

      On a personal note, I want to thank you for your dedication to this project. I can detect just enough frus

      • Re:I guess I'm one of the four (Score:4, Informative)

        by LoveMe2Times ( 416048 ) on Wednesday April 20, 2005 @11:31PM (#12299851) Homepage Journal
        What you *really* ought to thank me for is convincing my employer that OpenOffice.org was the answer, thus letting me work on it. Although, it has taken some dedication on my part or the project would have failed, so thanks :)

        Also, I want to re-iterate that I'm hopeful things will improve after the 2.0 crunch. The Powers That Be are not unaware of what's going on, and some effort is being expended to improve things. But 2.0 is a monster that really needs to get out the door, and once that's done will be a good time to revisit some of this.

  • Poster for Sun-Dresden walls: It's the API, stupid (Score:3, Interesting)

    by jensend ( 71114 ) on Wednesday April 20, 2005 @09:58PM (#12299192)
    To those saying "it's the legal troubles and fear of Sun": it's true enough that Sun's copyright assignment stance, licensing, etc are responsible for the NeoOffice fork and, to a large extent, the lack of corporate contributions, but the fact that contributors do retain (dual) copyright and that the GPL/LGPL licensing is irrevocable should mitigate that enough for community contributions.

    To those saying "Break it up into components, like Moz": I don't think the problem is that OO.org comes as a whole as that the framework on which all of the apps are built is extremely complex.

    To a smaller extent, Mozilla did have the same problem. Splitting the suite was a relatively minor (and thus far somewhat uneffective, as the problems with getting a shared GRE show) move for Moz compared with the momentous decision to ditch so much of the NS 4.x- pre5.x codebase in favor of Gecko, Seamonkey, etc. Even after that and years of improvement, Mozilla development is still known as rather difficult to get into well. Cleaning and simplifying the framework of StarOffice will be even harder.

  • Koffice has the same problem: lack of developers. And reading the comments I'm sure that Koffice is much easier to develop. (but I have never looked at OOo source so I can't be sure) OOo is better, but Koffice is coming along nicely, and in many cases is better designed, in part because they started from scratch a few years ago, while OOo is an old app that was open sourced.

    • Koffice is frankly amazing. There's about half a dozen developers in total on the whole project, and yet they manage to develop at a fairly decent pace. QT helps a huge amount indirectly. For example the rendering problems we have been having in kword will hopefully be sorted out by simple switching to the new QT4 widgets. No code in koffice needed. OO.org on the other hand has to reinvent all that itself.

  • Magnitude of community effort (Score:3, Informative)

    by Chemisor ( 97276 ) on Thursday April 21, 2005 @09:06AM (#12302111)
    > Sun is still the largest contributor to the
    > project with some 50 developers in Germany,
    > followed by Novell with about 10 contributors,
    > and only four active community developers. [italics mine]

    This gives you an idea what degree of community support an OSS project can expect. Ought to be quite a shock for those who think that they can attract hordes of developers just by opening the source.

Slashdot Top Deals

Do you suffer painful hallucination? -- Don Juan, cited by Carlos Casteneda

Close