I love LibreOffice.<p>That said, in my spare time, I've been looking through the code base, and my impressions are that it's too large. For instance, looking at the vcl module, which handles widgets, windows, etc. when I look at the number of classes my mind begins to boggle.<p>I possibly (read: probably) speak from ignorance, but I use the function SVMain() [1] as an example. Instead of defining a purely abstract class with architecture specific classes derived from this, they have defined an extern hook function, then they run it, test to see if it returns false, and if so run the standard ImplSVMain function. This seems inelegant for two reasons: the code is somewhat unclear, and there seems to be two functions with lightly different names, one is an SVMain function that does something, the other is an <i>implementation</i> of a function... Yet both implement a functional part of the code base. There is even a comment that reads "the real SVMain.".<p>Then there are the names... There is a "desktop" object that runs the main loop, the desktop being the application. [2] But there is an Application class [3], yet at the same time there's a DesktopEnvironmentContext class [4]. This seems to be some sort of misguided attempt at reimplementing a "desktop" metaphor, which is a legacy of early versions StarOffice. It was one of the first things ripped out when work started on OpenOffice.org, yet the class name still remains, making its purpose most unclear.<p>Furthermore, for some reason they force the Application class to be subclassed. Which they do only once, via Application_Impl. But I have noticed that the base class has lots of empty non-pure functions, and only forces Main() to be a pure virtual function. What is the point of this?<p>Another thing that I find makes the code harder to read is it uses a lot of Hungarian notation.<p>This is a legacy code base, and I wasn't being sarcastic when I said I love LibreOffice. I think people like Michael Meeks and Kohei are amazing. But I see the code base as having been slapped together somewhat pver many years. And there are code smells and, frankly, code rot, throughout the source.<p>It needs to be rearchitected (not rewritten). There is code in the code base that nobody dares touch (the legacy filters). The code is organised strangely, for example there are multiple places to find filters. At the same time, they have a system abstraction layer (sal), which has specific architectural and generic classes, but then I see that <a href="http://docs.libreoffice.org" rel="nofollow">http://docs.libreoffice.org</a> has modules like "android" and "iOS".<p>There are literally thousands of classes in there. Go-oo sometime ago refactored away dozens of classes, I would think they could refactor away a lot more.<p>I'm truly sorry if this seems harsh or ignorant by the way. It's not intended to be that way. It's just this code base is massive, so massive that its hard to understand how it all works. This in turn, IMO, may cause issues getting more volunteers. Not to mention too much refactoring might break things.<p>1. <a href="http://docs.libreoffice.org/vcl/html/svmain_8cxx_source.html#l00211" rel="nofollow">http://docs.libreoffice.org/vcl/html/svmain_8cxx_source.html...</a><p>2. <a href="http://wiki.openoffice.org/wiki/Architecture/Process_Flow" rel="nofollow">http://wiki.openoffice.org/wiki/Architecture/Process_Flow</a><p>3. <a href="http://docs.libreoffice.org/vcl/html/classApplication.html" rel="nofollow">http://docs.libreoffice.org/vcl/html/classApplication.html</a><p>4. <a href="http://docs.libreoffice.org/vcl/html/classDesktopEnvironmentContext.html" rel="nofollow">http://docs.libreoffice.org/vcl/html/classDesktopEnvironment...</a>