“Small pieces…” down the software stack

John Carroll:

[T]echnology across software domains should be consistent. There should be a standard, however de facto, that works everywhere. Skills should be portable across those markets, so that someone with experience in desktop software development has a decent chance of developing for handhelds. Everything should just work together, and development across all devices should be relatively straightforward to someone with experience in any one of them.

Microsoft has been very good at this. […]

I wonder whether the open source world can match that consistency. Granted, there are movements to make things consistent, such as the LAMP set of technologies for Linux, or the Linux Standard Base project. However, the structure of development for open source products militates against the establishment of any consistent standard.

Open source development relies mostly on voluntary contributions. People don’t tend to contribute to ALL open source products (that would be impossible). Rather, they concentrate mostly on the products that interest them.

This results in a developer version of tunnel vision. Since all that matters is the creation of the handful of products to which the volunteer contributes, what matters is the interests of contributors to a single project, not the interests of technology which should span ALL products.

Great points, though I clearly disagree that the open source community is fundamentally unable to match Microsoft on providing a consistent environment. It’s going to take some work on our part though.

One of the reasons Microsoft has historically been so successful is its unique ability to integrate disparate technologies into cohesive wholes, as well as to leave the mechanisms they use to do this just open enough that others can integrate with them to a degree but never so open that they can do so better than Microsoft can.

Of course, Microsoft can do this because they develop, own, and control each of the pieces and the interfaces between them. Other platforms (Linux, Java, UNIX, even the Web to a certain extent) are comparative mishmashes for the exact reasons John describes, namely that every project is developed independently, and that there’s comparatively little thought put into how the pieces interact.

The only parties that do think about these issues, the Linux distributors, tend to do so after the fact, and, of course, they have no direct control over the projects that produce the pieces to push any integration improvements they might make upstream (in the general case anyway).

Furthermore, once multiple solutions in a given problem domain emerge, it’s not always possible to generalize the interfaces when the projects behind them don’t agree with each other on the “right solution”. In other words, because it’s an after-the-fact thing, “not invented here” and general inertia come into play.

So, while the technical aspect of the problem is important, namely the interfaces between components (APIs at the source level and ABIs at the binary level), there’s a social aspect here too. We need to encourage the kind of competition at the implementation level that results in technical excellence while fostering a sense of cooperation at the interface level to ensure that, collectively, the various implementations fit seamlessly into a larger, consistent environment.

In other words, we don’t want to get in the way of open source project and Linux distro innovation, but we do want to encourage open source projects and Linux distros to innovate in a collaborative fashion so the technology that ultimately wins in the marketplace can be standardized with as few legacy issues as possible (or, in the case where multiple best practices emerge, for legacy reasons or otherwise, we want to collaboratively define a uniform interface, i.e., cooperate on interface, compete on implementation, etc.).

That’s the only way we’re going to get there.

4 comments on ““Small pieces…” down the software stack

  1. Vinay Pawar

    Consistency is such an important matter that shoo’ing it away for political or user-vs-developer-advantage arguments, would take us nowhere.
    Everyone understands that 100% consistency is unrealistic, both technically and otherwise.
    Look at GNOME, KDE, OpenOffice.org, Mozilla, etc. they’re the pillars of the free software and GNU/Linux world. They’re not one or two programs, but more like platforms in themselves. A large number of programs are built over and around them, and standardization here would affect nearly all of them. But look at them, they all have their own file selection dialogs. For such a frequently used dialog, they’re radically different. I’m sure distribution vendors would love if there was an option for a common file selection dialog, which would use native GUI toolkits so other things like the look is consistent.

    Consistency in some places is really critical. And the good thing is it seems achievable without major disruption.

    Vinay Pawar

  2. Pingback: Piece of Mind » Blog Archive » Cooperate on interface, compete on implementation

  3. Pingback: Piece of Mind » Blog Archive » Cooperate on interface, compete on implementation

  4. Ruzsa Balázs

    I think in the future applications running on platforms like KDE and GNOME will be written entirely in scripting languages like Python, Ruby or Lua. The platform will extend these scripting languages with a consistent set of classes (most likely separated into a “system” namespace), which act as proxies to the underlying open source C/C++ libraries handling the details.

    In this model, it is not a problem that the low level libs come from wildly different developer cultures, as the high level app developers never interact directly with those layers, only with the interfaces provided by the platform.

Comments are closed.