Wasted Efforts in F/OSS – Office Suites

This is the first of at least a two part series. I say that because I hold a stronger opinion today than when I first began formulating this premise. Initially, I had'nt thought out all the implications and due to the interactive nature of this format, I expect further ideas to arise. Oddly enough, for this one instance I see a modicum of truth in one insult Microsoft throws at Linux. And that's what we'll explore together. Please don't take the polite wording of this editorial as an indication of any uncertainty on my part regarding the premise I will present. The politeness exists only because those involved seem so talented. It caused me some difficulty understanding how they arrived at the point they did. Read on and feel free to comment with vigor as this conclusion or its consequences is not one to take lightly. Furthermore, the next part may seem quite disturbing.

Premise:

I may be a bit naïve, however, I wonder if many efforts in the creation of free and (so called) open source software* are wasted efforts particularly regarding the Office Suites and components. Since I am essentially asking if my impression is valid, I would gladly admit to an error if I can be refuted by logical argument with readily seen, fact based examples. Nonetheless, this paper begins with the premise that this article's title is true.

Fundamentals:

If building infrastructure is the true forte of Free/Open Source Software, why is there so much duplicative efforts to build so similar edifices seen in Office Suites? Would it not be better to put the initial efforts into construction a software scaffold as the first fundamental step in building the structure to allow all suites components to be placed upon it from any interested source? While I do not consider myself a competent software architect, conceptually the proposal in the previous sentence seems reasonable. Moreover, it could attract talent that is more attuned to fundamentals of process control, i.e. information exchange rather than the attributes seen in a keystroke binding to an action upon a gui that a class of users expects from an application.

Choice:

Such a Suite skeleton could be built akin to the process that is used to create and modify the Linux kernel. Then we might move back to a concept from the early days of PCs, that is users could select only those application components they consider to be the best of the breed. It would be the users' choice to ignore both the less attractive and even those worthy applications that many users have no interest in employing. If such a structure existed then many more application developers could focus their best efforts on perfecting their respective tool. Moreover, the competition would not be limited to those having the resources to produce a full application suite with portions that even by these few with sufficient endowment still contain substandard elements. Think of it: a Suite of only the Best.

Legalities:

There are, however, some fundamental considerations that cannot be altered: this edifice must be distributed only under GPL so that any modified release must contain the details of any vendor altered component at the time of distribution. Moreover, this must not seen to be an option by those proprietary vendors that employ this Free/Open Structural components, to withhold details until they are ready. It must be clear that the complete code must accompany the product. Simple: code delayed means the distribution too is delayed. Furthermore, while everyone would be granted equal access, the attempt to embrace and extend should be demarcated as legally actionable in the base licensing.

Practicalities:

The ownership of the core infrastructure should be inviolate, whereas the components attached may be any combination of Free, free (no charge), Open Source, closed source and / or proprietary as determined by the original vendor, software packager, corporate site standard or individual user. Attachment of any component is at the discretion of the user and theirs alone. Consider how this could radically alter the software development landscape: the application packages might at the core be considerably simpler. Take one example, of academic usage in the sciences in contrast to a full featured word processor a lighter text version could suffice combined with a superior, independent equation writer. The latter combination would suffice for article writing, however, when a full length book or several chapters are to be composed other components could be added to fulfill the extra demands. The mix and match mind set could revise how differing sets of developers approach software applications. Perhaps the Unix mind set will come into play where the combination of small, specifically honed tools will result in the wholesale replacement of the over sized generalized tool that relies upon too many compromises.

The preceding paragraph gives the impression that there are two components comprising the scientific word processing application. That, however, is a misapprehension due to the components are both more simple and more numerous. To begin there would be a very simple text editor (bare bones), this would be attached through the application skeleton to a selected formatter component. The next item on the list would be a base set of text fonts that itself would be connected to scientific font set including at very least a Greek alphabet set, that is attached to a mathematical symbol set, that may include or be attached separately to a set of physics symbols. How would this be accomplished? Using configuration files for each component.

The actual application would be seen as a gui, which would be a wrapper. It would have its own configuration file that taps into the application components respective configuration files. The latter would have numeric values that determine how early each component is loaded and how tightly it is bound to the entire application per se. For example, as seen in the exhibited widgets and their availability for immediate use.

Commercial vendors could combine any combination of small component parts to create unique “products” that seem to stress important end user virtues. For example, where apparent quick loading is perceived as a paramount characteristic, the image (gui) can be made to appear quickly albeit non-functional in short order. Moreover, certain functionality might not be even present until after its widget is activated by user action to further boost perceived loading speed. Hence, where applications receive commendation based on bogus “bench marks” some might find early commercial viability whereas others may take the longer road stressing quality components and optimized interaction. Most users, however, will accept the system as delivered by the OEM or the corporate standard issue.

What a world that might be. Open to all comers, but the infrastructure must be built first with care and be forever free.

Last Word(s):

What a world that might be. Open to all comers, but the infrastructure must be built first with care and be forever free.

__________________________________________________________________________________________________
Please register to become part of the discussion and suggest where this topic content should flow.
Feel free to be critical, but while simple opinion is a prior equal, only informed opinion will be
given credence. Thank you for your input.

* As too are the proprietary, however, my focus is upon F/OSS.