Open Source and software leverage

I was reading this enlightening entry (several folks are already pointing to it in their weblogs) in Ray Ozzie's weblog when I realized that Open Source software has much of the same potential for leverage as building software on Windows. (I never gave much thought to how hard it must have been to build desktop apps when I was a teenager...)

Well, my first thought after reading it was "gee, he just explained a lot of why I can be so productive with Perl on a Linux/Unix box." By using the tools that are always there and some code from CPAN, I can build relatively sophisticated applications. Those other tools are really platform technologies--things like Apache as the web server, MySQL/InnoDB, and any sendmail compatible MTA. (It's interesting to notice how virtually every popular MTA is "command-line compatible" with sendmail. An effort to commoditize sendmail itself? Maybe.)

There is a lot of what Ray describes going on in the parts of the Open Source world that I tend to inhabit--mainly the server side and middleware as well as scripting. In my job at Yahoo, most of the code I work on is behind the scenes stuff that end-users never interact with. Recently I've been working more on a user visible stuff, but it is still on the server side.

That made me happy. He was affirming what I and many others do for a living. We're building software efficiently by reusing code and components.

But none of what I do is in the space of desktop applications, but that that's where Ray's story kicks in.

On the "desktop," Linux has a lot of well understood problems. However, I think they really run a lot deeper than some folks understand. The fact that we have both GNOME and KDE, for example, isn't great when it comes to "conquering the desktop" but that's a side issue. Look at the applications, not the window managers and eye candy.

As Jon Udell pointed out in Byte (back in 2000), summarizing Miguel de Icaza:

major Unix applications such as Samba, Apache, ftpd, and ssh share essentially no code beyond the primitive facilities in the standard runtime library, libc.

I know what you're thinking--Samba, Apache, and so on... They're all server-side applications. Hang with me.

He brought this up again in 2001 in his "Embrace and Extend" article in Linux Magazine (go read it). His points are still valid today. Linux application developers haven't built the necessary cultural infrastructure to enable the level of component reuse needed to make Linux an appealing platform for application developers.

Things have come a long way since Ray Ozzie had to worry about:

having to write a ton of junk from scratch e.g. custom memory managers, code component managers that did all sorts of trickery for memory conservation, multi-byte character handling, rich text editing, MDI window handling, and all sorts of grunge

You get some of that when you select the right libraries. By using glibc and Qt or [pick your favorite GUI toolkit], you can assemble the beginnings of a foundation--the sort of foundation that Microsoft has provided developers for years in the form of the Win32 API.

However, when you begin to move up to the next level or two, things get shaky again. How should your application store configuration data? There is no Registry on Linux. So the developer has to build that. You could use plain text file (common on Linux), XML (common in Java), or something else.

(Speaking of Java, a lot of this isn't an issue for Java developers. But that's largely because Java itself is a platform full of moderately well thought out APIs. Sun wasn't stupid. They know what it takes to build applications. Of course, Java on the desktop has been less successful than on the server side... But that's a whole 'nother discussion.)

What about a common database API? That depends on the language you're working with. Python? PHP? C++? Java? Perl? They're all different. There really is nothing like ODBC, ADO, or OLEDB on Linux/Unix that has much traction.

What about printing...?

The list goes on. There's a lot of common plumbing that's not there. Not like it is in Win32 (or Java) at least.

What am I getting at? Basically, I'm agreeing with Jon. But this time I've arrived at that conclusion in a why that surprised me. I realized how much of a different world it is on the desktop vs. on the server when you're using Linux or Unix (and leaving Java out of the picture) by thinking about why I never build desktop apps (even for fun). I could probably still do it on Windows if I had to. But it'd be quite a battle for me on Linux.

It's hard to explain this to folks who haven't experienced it before. But in my previous job, I lived in the loving clutches of the Microsoft world. I built mostly server-side code for our corporate intranet. I used Perl, ASP, VB/VBScript, Access, and Oracle. But on occasion I needed to build desktop applications--quick interfaces to something or a prototype. Amazingly, I was able to re-use a lot of the tools, knowledge, and APIs from the server-side and middleware development when it came time to build desktop apps. It's really not like that in the Linux/Unix world. Until it is, there may not be significant commercial interest in building applications for Linux desktop.

Is .NET and SOAP the solution as Jon suggests? No, it's not the solution, but it may be part of the solution (or a solution). This really isn't a technological problem. It's a cultural problem. Open Source is good as solving technical problems. If that's all it was, we'd have solved this years ago.

So what do we do?

Posted by jzawodn at August 11, 2002 10:51 PM