Why Open Source Doesn't Interoperate
bergie writes "There is an interesting article on Advogato on why it is so difficult for Open Source projects to interoperate or support common standards. Often cultural differences between projects, egoes, and many other issues stand in the way. The article outlines some practical ways for improving the situation, based on experiences from OSCOM efforts to get support WebDAV, SlideML and other standards into Open Source CMSs. Examples of successful interop projects include freedesktop.org, the cooperative effort between GNOME and KDE."
To make software interoperate, developers need to create interfaces before writing their software. Often no planning is done and developers start writing their code without a clear vision of what they want to write.
There is a certain overhead in creating interfaces. They can take time to develop and they aren't any good, you'll be stuck with them for years. Even Linus is against the creation of standard interfaces internal to the Linux kernel. That decision inhibits the creation of a truly modular system.
...that open source authors prefer solutions they like over "standard" solutions.
Industry standards, particularly those created by committees, are often abominations that people only use if they have to. In my experience, the extent to which people like things like CORBA and XML often seems to be inversely proportional to their level of technical sophistication.
RFCs have much more respect in open source circles than committee-created standards.
The hardest thing to break is the ego barrier. And it is very evident in many aspects in open source. Take for example the kernel source and different programs branching off. It's great, and even arguably beneficial, except for the fact that different versions of the same program are competing against each other where the forces should be united. Again this is the beauty of Open Source, where you don't have to rely on a leader/Dictator how ever you see it. The fact of this multiplied by the ego's in different countries just make this a big number. What also does not help is the fact that many programmers are not being paid such good money for the programs either. I will still use open source software at home and love it. If people want to compare M$ "standards" to Linux just remember one thing, M$ has about a ten year head start. ;-)
This SIG pulled due to lack of funding. (This damn war is costing too much!)
You'd think if geeks couldn't "interoperate" with girls, at least they would be able to interoperate with other geeks on their projects.
*ducks*
Small potatoes make the steak look bigger.
One of the reason is that by releasing your source code you can easily create de-facto standards. VNC is a good example. It is not standardized at all, but the original implementation came with source code under GPL. Dozens of VNC projects have been created since, all inter-operable, and most of them are based on the original source code.
The real reason stuff doesn't interoperate is the people that want it to, didn't do so.
If I want my project to interoperate, I will incorporate that feature. If I don't care, I won't.
If someone else wants it to do something else THEY have to add that feature.
Why should I spend my time working on features for you?
This is free software, the interoperability people could make it work, but they don't put the effort behind it, so it doesn't happen. If it isn't worth their time, money and effort, why should it be worth mine?
I have been involved a little bit with the OSCOM efforts and I am impressed again and again on how they all work together. The board members of this organization are leaders from various OS Web Application servers, all having different interests and yet they can work together.
I only know Paul Everitt (one of the authors) personally, who is co-founder and used to be the CEO of Digital Creations (today Zope Corp.) - therefore one of the inventors of Zope (www.zope.org). He started the Twingle project a while ago, trying to generalize the Zope effort to create a content management Mozilla-GUI for Zope 3 to all Open Source CMS solutions.
As the article states this effort is quiet ambitious, but it also shows the power OS can have. When Paul and I started working on the original code, we used heavily XML-RPC (it is just the easiest to use for getting anything done), but Paul has since pushed towards HTTP standards, such as WebDAV. While this is much harder (i.e. I am writing a WebDAV library in JS for Mozilla) than the original approach, it allows a lot of integration possibilities later. For example, in the future we imagine that we will be able to drag and drop objects between Bitflux and Zope and vice versa for example. Also, a unified GUI will allow Content Designers to gain a skill that is much less platform-specific (in the meaning of App Server and Operating System), which makes this skill much more marketable.
BTW, OSCOM 3 will be held at Harvard University on May 15, 2003 if I remember right. So everyone interested in Web-related technologies living in Boston should drop by and check it out.
-- Stephan Richter
To be honest, the headline is sensational and the document itself has limited content from which to draw conclusions. Most critically of all, however is the assertion that Open Source projects refuse to interoperate based upon experiences of a monolithic organisation trying to get OSS CMSs to implement WebDAV.
:)
To be honest, I've written several CMSs, contributed to others, and done 90% code re-writes on others to suit my needs. All OSS.
The thing is, you'll find that many Open Source CMSs don't always support LDAP or a host of other standards. Why? Because they don't need to. PHP Nuke, for example, is a fine project for producing small-to-medium community/corporate content-driven web sites. It isn't perfect, but it is modular, and a bit of work will allow you to produce some very nice, functional projects. It doesn't need to have to support another protocol, WebDAV throughout and then SlideML on top.
PHP Nuke is, in fact, a combination of other projects brought together and welded into a final package. That's interoperation for you...
What about the OASIS initiative, where open source projects are trying to produce XML-based standards for office documents to ensure long-term data access and inter-operability. What about X? VPNs, secure communications, file sharing, standard web protocols and a hundred other examples of OSS collaboration, where proprietory companies are digging their heels in to try and jealously guard their marketshare?
If you want to know why OSS CMSs don't have WebDAV support, it's because they don't need it, plain and simple. If it was important and really would make an incredible difference, they would all be supporting it. As it is, from what I can see, what is on offer is something that their code already does for the most part. They don't see the point of it, neither do their users. Oh, and they probably don't like you writing articles, saying that they don't play nicely when you arbitrarily come up with things and tell them they should implement them.
To everyone else, sorry for the rant, but this article really is nonsense and insulting to everyone who works hard in the open source community on almost any project.
...the fact that doco is often nonexistent or poor, code is idiosyncratically designed/written and poorly commented (if commented at all).
Result is that quite often, it takes less time to implement something oneself than to understand and integrate with a 3rd party piece of software providing the same functionality.
Too many developers think it's beneath them to write good doco, example progs, tutorials, clear easily-learned APIs and clear meaningful comments in the code.
It's a kind of elitist 'techno macho' attitude - 'if it was hard to write, it should be hard to understand'. Too often my questions to authors of unfamiliar software are met with a terse 'RTFS!' (read the fucking source).
This syndrome creates a fragmentation, which destroys opportunity for leverage from well-collated and well-catalogued sharable components. Which in turn makes developers' time more scarce, and further discourages the efforts to make code approachable.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
One of the biggest problems I see with Free Software development is the problem of the blindered developer.
This is the guy who doesn't bother to raise his head from the computer to look at how his project works in any environment other than *his* system. You know, the guy who requires you to have libfoo.so.5.1.2.pl6-thursday-0741am-fred-mutant1 installed just to compile his code, and by $deity no other version of the library will work.
A concrete example: The developer of the GATOS project (a driver for the TV tuner/video capture (but not video out) functions of ATI All-in-Wonder cards) requires you to use HIS kernel module and HIS radeon driver. As a result, you may EITHER use his code XOR the DRI accelerated 3d code, but not both.
True, he does (to an extent) track the DRI development, but rather than working with DRI and XFree and coming up with a way his drivers can play nice with the standard builds (e.g. having hooks in the standard driver and having the standard driver load his modules if present) he is off on his own little branch.
He also uses libraries and packages that are not part of the standard installs of common distros - as a result just getting his code working is a real slog. So many people don't do it, and his project does not get as much support as it might.
Now, I am not picking on him - developing stuff like that is hard, since it is very poorly documented. And with DRI making changes, XFree making changes, and him making changes, you WILL have times when things don't play well together. But rather than that being a transient state of affairs it is the normal state the GATOS project w.r.t. DRI.
Unfortunately, it take time and work to stop, get a fresh install of RedHat/SUSE/Gentoo/... and see what it takes to get your code to build and install. It takes work to make sure that you really NEED the latest version of libfoo, rather than just any version. Especially when your code interoperates tightly with other people's projects it is difficult to plan interfaces that won't change frequently. If you can accept help from others this isn't so bad, but many project "leaders" have the attitude of "HOW DARE YOU IMPUNE MY PROJECT! IT IS PERFECT UNTO ITSELF! I CANNOT HELP IT IF YOU ARE NOT 31337 ENOUGH TO HAVE THE LATEST STUFF! L@M3Rz! IT IS UNDER DEVELOPMENT!"
But that is the difference between a hack and a software engineer - just "getting something to work" and "getting something to work well, under as many circumstances as possible, as smoothly as possible."
www.eFax.com are spammers
Lack of apparent interest from vendors is also somewhat discouraging. There are quite a few specs up on freedesktop.org that are only implemented by GNOME, with KDE "pending". Then for instance Mosfet comes along and claims the thumbnail spec is stupid for reasons x, y and z and proceeds to invent his own (the so-called "professional" thumbnail spec) and ask for it to replace the existing one! Not exactly encouraging.
A lot of Open Source projects are done because the primary developer(s) want something that is either not readily available in existing software (the original mantra of OSS) or they want certain things "their" way. Some developers are not even aware that a standard exists for what they are trying to do and will do it the way they think is the best while other developers would care less about the standards. Its is important to create awareness about standards and their importance (believe me, lot of developers don't understand the importance of standards and think of them as unnecessary burden). When a project idea comes to the mind of a developer, a lot of times the last thing a developer will think about is existence of any standards. Like the article described, ego and NIH syndrome also is a factor. The mentality is also that "if they developed standards, let them develop the product too. I will do it MY way." Again, this boils down to understanding the importance of standards and implementing them in your projects if one exists.
- Jalil Vaidya
No, it's because there are 6.02 x 10^23 developers working on the system at any one time.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
Almost nobody is trying to implement standards badly. But some standards are so bad that you can't implement them without getting a brain tumor. Just have a look at tmpfile() in POSIX, for example, whose semantics make it impossible to use it without creating a race condition. Or look at DVD, which references a hidden trade secret called CSS, which is not part of the standard, but you can't be standard compliant without CSS, which forces you to sign sinister contracts with the content industry cabal.
Maybe I've just missed the point of open source stuff over the last few years, but I always thought the idea was that people contribute to an OS project because it scratches their itch. For example, I find an open source database I would like to use in a project, but I need to tweak on it a bit to make it work on my platform, so I make the tweaks and contribute them to the commons.
I don't care if Joe Sixpack can't use the database, but then again I'm not going to whine because nobody but 'geeks' uses it. I know there are people that whine because nobody uses their hard-to-understand project, and they need to either stop whining or spend some time making their stuff more usable.
Companies worry about market penetration and product name recognition - and making money. When I work on a project, I usually only worry about the first two if I'm also worried about the last one. And most of the time, I'm just learning something cool, not trying to displace some commercial product. I don't like it when people like Uncle Pru get on their high horse and tell me that my goal should be to 'write things that are what the end user wants.'
[b.belong('us') for b in bases if b.owner() == 'you']