Slashdot Mirror
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.
Quote:OpenOffice + KDE + XFree86** != Productive Desktop Environemnt (for example).
Really? I seem to do just fine with this arrangement. In fact, I would say that I am more productive with open source programs than I ever was with proprietary software.
They say open source is good... They say open source is bad... They say open source is in-expensive when... They say open source is expensive when... They say open source is good when it comes to... They say open source is bad when it comes to...
I wonder who of them is actually using open source for anything than writing redundant articles about it... I can pull as many pro- and contras out of my ass when it comes to windows. But nobody would care. Nobody cares about because everything already has been said. I don't care. I don't read articles before I comment.
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!)
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?
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...
heheh..
this reminds of a very nice company that has had an habit of making closed-source, lock-in products that mostly don't care piss about standards, rather just work enough to them to allow using other products but then be so broken/intentionally closed that those other products can't be well used with it..
open sourced can be just as broken as closed source, but you sure as f* are more probable to get your own product to work with open source solution than closed source one.
world was created 5 seconds before this post as it is.
I agree that it's difficult getting open source projects to interoperate. I think the problem is that interoperation is hard, often harder than developing a program that works in isolation. Writing a simple mail server would be easy, you could build it on top of something like Distributed Ruby and have it working in a day. Writing a mail server that interoperates properly with everything else that's out there is a totally different proposition.
.DOC.
Whatever the situation with open source, it's far worse with proprietary software. No open source project that I'm aware of has anything as difficult to interoperate with as
One of the biggest problems I see with Free Software development is the problem of the blindered developer.
... but then one of the solutions I see with Free Software development is the solution of the enlightened (no pun intended) software engineer.
For you can take this hacker's code and make it work in your environment, or backport it to DRI and/or XFree, and he'll probably be ok with it, as long as he doesn't have to support that
I'm not at all sure that OSS does interoperate poorly. I would rather ask:
Why, when there's a need to interoperate, does OSS invariably fall back on the 'chain of programs communicating via a pipe of characters' model from the 1970s, even though mechanisms for defining rich, concurrent interfaces have been in common use for ages everywhere else?
I know there are many good reasons why pipe'o'ASCII software projects do what they do. I also know that projects like KDE have made considerable steps in what I think of as the right direction. But the lack of componentization and well-defined interfaces in Linux-style software is one good reason why I'm glad Microsoft (and even -- yechh -- Sun) still have a strong role in keeping things moving.
(loud crashing sound as post is modded down for not being unix-centric enough)
Whence? Hence. Whither? Thither.
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
I find open source tools like perl, bash, grep, emacs and so on integrate well. I can process any text file I want!
-- $G
I think it's because Open Source types hate "limiting choice" by enforcing standards. As much as you guys may hate Windows, the beauty of its "standards" is that I can take just about any program from the Windows 95 era and run it "out of the box" on a modern Windows XP system. I don't think it would be quite as easy to take any 8 year old Linux binary and have it run on a modern distro without some non-trivial work. Hell, I wouldn't bet any serious money on being able to take a recently released binary and have it run on a variety of modern distros without a little work.
Eventually, Linux and other Open Source ventures are going to have to "bite the bullet" and learn to enforce standards. When you develop for Windows, since there are a number of "fixed features" of the OS, you can, for instance, be sure that there is a registry you can manipulate in a standard way, be sure that there is a "start menu" that can be manipulated with a certain API, be sure that there will be a web browser that will render things is a predictable way, etc. Linux needs something like this. You need to have consistency across distros. You need to standardize on a directory layout so programs and data can be located in predictable places. You need a standard method of system configuration. You need to standardize on one grahical toolkit and make sure it's shipped standard. And so on.
But don't get the wrong impression -- enforcing standards does not limit "choice". It simply means that you can say with certainty "any given Linux distro will have X, Y, and Z, so don't worry about having to target a million different things." This is the "big thing", in my opinion, that holds Linux and Open Source back. Too many competing standards (do we need 50 GUI toolkits? 20 different variations on a "standard" directory layout?) and no one willing to say "this is the one that's our 'standard'."
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.
I have never participated in an open source project so I can't say but I have worked on projects for pay.
Supporting standards is a lot of work and most of it is not particularly fun or intellectually rewarding. It is just a pain in the butt. Who want's to do that for free?
Once the code is "complete" (code is never complete) it must be tested to insure that your implementation of the standard will work with other implementations of the standard. This testing is tedious, time consuming, and diverts resources from other parts of the project. You usually also have to have programmers who worked on each implementation available so that they can work out any inconsistencies. I've done this before for pay and I still didn't want to do it.
Another thing that always pops up is whose implementation is more standard? When an inconsistency arises one side has to make a change. I've gotten in the middle of pissing contests with programmers who each insist that the other is wrong and they aren't going to change their code to work around their bug. What fun!
I know that there are a lot of OSS developers out there who take their work very seriously and put out the highest quality product but they also have day jobs, lives (I hope), etc. that compete for their time. If I was doing the work on my time, I would probably tend to do the stuff that I found more rewarding. Things like rigorously supporting standards and all of the sh*t work that goes along with that would probably take a back seat to working on a new feature or something else that I considered challenging and exciting.
Almost all of my open source software interoperates. It's the interoperation we call "unix", and which is so graceful and transparent we don't even realize they're different programs using the same rules to pass information around.
If you really believe in what you wrote:
> It's not just a case of writing something down and say "Agree to it!",
> everything has to be discussed
then your harsh criticism of Mosfet seems very rude and misplaced to me.
He didn't ignore what you call a "spec", and is in fact tagged as a "new draft" and only a
"proposition" on the freedesktop.org page.
On the contrary, he carefully looked at it, and issued very well-founded
arguments (here) as to why he thought it was wrong.
Last time I heard, he was even implementing a full set of useful CLI tools
to back up it's own proposal.
So I'd be very curious to hear why you think this very skilled and talented programmer,
with a huge experience in graphics, is not welcome to change a vapor and PR "draft"
into an effective and sound specification?
If even wannabe spec writers can't stand constructive criticism,
then there's few hope for interoperability indeed...
Since when is freedesktop.org a successful example? What did they achieve yet besides specifications?
We have Linux Standards Base -project, maybe we should also have Linux Developers Standards Base -project which defines how you should use/develop libraries and plugins in your projects so you can interoperate with multiple standards.
So if you develop a Mail User Agent it could read all of the mailbox-standards by using the default libraries for these. (technically possible? definitely. hard? harder..)
Ofcourse it should define other standards too: configuration files, commandline parameter styles.. everything that is common with software. But there should be some freedoms due to the nature of OSS-development like freedom to use any GUI-library etc.
There would be a lot of fights over the standards, yes. But it might be worth it in some cases. I can see a few problem cases with this, but it could be useful in many common situations.
The twisted part:
OSS-developers usually wants to code everything by themselves, even if there is a library that does something for you.. they still tend to code one by themselves because the library misses one feature or something. Just add the feature to the library, don't create your own! (From this we will come by the problem of library developer not accepting your addition to the library... try to discuss about it.. why it is useful addition etc.)
OSS-users usually wants to use software that doesn't have a lot of libraries. Have you ever begun to install some software and noticed that it is going to install 20 libraries in addition? Scary huh? We should change our mindsets, repeat with me: "Libraries are good, libraries will liberate us."
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']
What I think would help a lot is if there were more standard conventions for selections. This would make it possible to enable more drag-and-drop features across programs. And using drag-and-drop in, say, GTK, is really quite easy (easier, I believe, than in Windows).
For example, one piece of code I'm working on uses images and palettes; and it would be really nice if I could drag one of my palettes into the Gimp, or one of the Gimp's onto the palette window in my app. Same thing for individual colors and images.
Is there a group or project trying to set standards for selection at the application level? Perhaps this should be an extension to the X drag-n-drop spec.
This article doesn't prove its own premise. Where is the evidence that open software is less likely to implement a standard than closed software? I can think of so many counterexamples, because OSS tends to actually define the standard. See: every major internet protocol.
Then fork it.
This is why forks can be a good thing.
Do it yourself isn't wrong, it is the point of open source.
With closed source you have to take what the "maintainer" decides.
With open source you can take what they give you, or change it. You have choice, you have the power.
With open source you are only as screwed as you let yourself be.
Actually Windows supports command line, DDE *and* OLE/COM. You also get the shared memory, named pipes etc. And if you don't want to struggle with DCOM, .NET has some very easy to use APIs for remoting.
/standard/ component model today is like an OS without IPC in 1990.
Each has pros and cons, use what's best for your situation.
I hear a lot of sneers about COM in the Unix world, but it (and systems like it) are essential if you want to build sophisticated desktop applications. Mozilla (XPCOM) and Gnome (Bonobo) are examples of projects who rolled their own because Unix had nothing to offer them. Unfortunately, no one spent enough time *designing* Unix clones -- otherwise a XPCOM-like subsystem would be a standard part of every Unix distro.
An OS without a