Open Source and Interfaces
One of the things that complicates the development of software in the open source world is the enormous variety of different interfaces you have to deal with. This is eminently an architectural problem: interfaces need to be defined ahead of coding, and if you just start developing your own project, you have no need for uniformity across projects.
Initially, of course, there is no standard and hence no interface. Later, separate projects come up and they make a point of having different interfaces to better spread and create incompatible ecosystems. That was the whole enmity between KDE and Gnome, or the many different brands of SQL server implementations.
There is nothing wrong with competing projects, especially nowadays. It dawned on people that copying from successful efforts is a good idea, and the availability of source code makes it easy to get not only ideas, but also implementations moved. It so came to be that the outstanding networking code in BSD became the forefather of the networking layers in many UNIX-ish operating systems.
On the other hand, there are plenty of places where work is unnecessarily complicated by incompatbile implementations – even within a single framework. Getting these incompatible layers realigned should be an important task of Linux and open source developers.
Instead, each project seems to think that being incompatible is a goal, because it highlights the capabilities of your system. KDE, for instance, has this widget system called Plasma that allows you to embed all sorts of things in your applications (especially the desktop). Only KDE has that, so if you like Plasma, you have to use that. Nice.
On the other hand, KDE also has so-called KIO slaves that are plugins that allow you to connect to sources and destinations that are treated as files. They work fine in pretty much all KDE applications, but nowhere else.
Even when the different technologies put their minds together and come up with a common interface, it seems to be dumbed down just because. Such was the result of the unification of DCOP (KDE) and Gnome’s CORBA into DBUS. At least on the KDE end, the implementation of DBUS interfaces is primitive compared to the former power and glory of DCOP.
The main problem I see is that the open source community is empowered by diversity. For everything, there are dozens of different ways of solving the same problem. Some are good, some are not so good. All of them have one thing in common, they are open.
Interestingly, UNIX had its forte in the small utilities you could combine together to achieve enormous power. In the old days, you could either use a Windows tool that could not be automated or scripted, or put together a pipe of shell utilities that did what you wanted automatically.
The new Linux doesn’t do that any more. It has become entirely a commingling of ecosystems that are independent and happy to be so.
For a different (and better) approach, look at one particular GNU project: GNUCash. It’s a “Quicken clone,” a personal finance manager. Its application logic is separated from the presentation logic, and the KDE people could re-use the app layer in their own KMyMoney project.
From an architectural perspective, you would want to separate application logic from presentation logic. You would also want to separate glue code and user interface from the core application. In particular, you would want to script the glue and interface, so that users can change both as they see fit.
I’ll give you an example: one of the things I commonly have to do is to copy a line in a shell and paste it as a new command. There was one shell on DOS that allowed me to do that: copy and paste in one shortcut. Strangely, that’s an enormous improvement over the current state – seems incredible, but the problem is that in Linux, it’s quite unpredictable if the application you are using actually has the clipboard. So you copy, but when you paste you get some old clipboard content.
KDE has a shortcut functionality that confuses a great many beginners. [Note: that’s mostly because every KDE application has a Configure Shortcuts menu item next to the Configure Application, which seems stupid – you’d expect the shortcut configuration just to be part of the app config.] The basic idea there is to connect the functionality embedded in the application to keyboard interaction. Adding scripting logic to this is simple (as a matter of fact, some KDE applications embed a scripting engine, QtScript). But, for the most part, the scripting is just a secondary thought.
Instead, all menus, widgets, buttons, user interface elements should be laid out using a scripting engine, and the user should have liberty to rearrange things and logic as she sees fit.
Why? Because that way, someone else can reuse your widget and embed it in their own application. There is no reason to say they shouldn’t – it’s open source, so what they want, they can steal. But it’s far better if they can steal the thing instead of the code.
The same is true for a variety of other cases. In general, the power of an application is directly proportional to the way it is flexible. The more an application is inflexible, the less likely it is going to be reused and usable.
Finally, the one huge advantage of going about this in the way proposed is that you can finally take those application that have outstandingly horrible user interfaces but equally outstandingly powerful functionality and rationalize them. Sometimes I wonder what would happen to Blender, GIMP, or KDEenlive if someone with a little love of UI could go and change them at random.