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."

24 of 208 comments (clear)

  1. Because free software is not planned by Anonymous Coward · · Score: 5, Insightful

    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.

    1. Re:Because free software is not planned by akadruid · · Score: 5, Interesting

      Unfortunatly a lot of code writing is done with inadequate planning, but this is an inherant problem. Without a crystal ball you cannot predict every twist and turn you will face.
      This is not just a problem with free, Free or open source software, but also with planned, structured development of commerical model software such as Windows.
      After all if we could predict the future why would ever need new versions? :)
      However I don't think that a neatly integrated environment is impossible, just difficult.
      Besides, getting around integration issues is part of the fun!

      --
      "Those who cast the votes decide nothing; those who count the votes decide everything." (attrib. Joseph Stalin)
    2. Re:Because free software is not planned by You're+All+Wrong · · Score: 5, Interesting

      Your subject line says it all. Well, nearly...

      I'd say the two biggest sins of the open-sourcers are
      a) over-generalisation (it'll be able to do everything)
      and
      b) over-specialisation (it does one task, but can't do similar ones)

      I'm finding it hard to think of examples, but I guess GNU grep's an OK example of something that's just about right.
      Expanded to do enough things like context greps (e.g. give me 4 lines before the line containing "Name:" and 1 line after), and a few other features (e.g. '-c' so that you don't need to '|wc-l') that add to its functionality, so it isn't over-specialised. Likewise, it's not sed, awk or perl, they realised that just keeping it simple and lightweight was the way to maximise its usefulness.

      YAW.

      --
      Your head of state is a corrupt weasel, I hope you're happy.
    3. Re:Because free software is not planned by akadruid · · Score: 5, Funny

      So you're telling me that all those managers have actually been useful over the years?

      some sort of functional and or design specification
      That just about covers some of the best stuff I've been given to work with :)

      --
      "Those who cast the votes decide nothing; those who count the votes decide everything." (attrib. Joseph Stalin)
    4. Re:Because free software is not planned by truthsearch · · Score: 5, Informative
      From an interview with Rob Short, the vice-president of Windows Core Technology, regarding Microsoft® Windows(TM) Server 2003:

      Why is there no command line only version?

      We're looking longer term to see what can be done, looking at the layers and what's available at each layer and how do we make it much closer to the thing the Linux guys have -- having only the pieces you want running. That's something Linux has that's ahead of us, but we're looking at it. We will have a command line-only version, but whether it'll have all the features in is another matter... It's a very tangled subsystem.

      <plug style="shameless">
      As I also explain at MS Versus, Bill Gates has testified in federal court that Microsoft® can't modularize their operating system or document all of its APIs because it's written by groups of developers haphazardly binding software together without any clear overall design.
      </plug>
    5. Re:Because free software is not planned by killmenow · · Score: 4, Insightful

      As a follow-up to this, remember that the *vast* majority of software being developed is not commercial software. It is in-house proprietary software. And the planning that goes into a lot of it is dubious at best.

      In most corporate settings it's like this:

      PHB: "We need software X to do Y by tomorrow."
      Developer: "But we need time to plan and design and..."
      PHB: "That's why I said we need it tomorrow instead of today. Now get to work..."

      Geez, don't you people read Dilbert?!

      Oh, and BTW, what's an EGOE?

    6. Re:Because free software is not planned by jc42 · · Score: 5, Insightful

      Well, I dunno about that. I've worked on any number of "planned" projects, and in every one, the same thing has happened: The managment comes along and changes the requirements. So you have to kludge the plan to handle the new requirements. Then they do it again, and again ...

      I don't think I've ever seen a planned, commercial project that interoperated with anything else. Usually you even have to write new editors because all the file formats are proprietary. Just looking at the data in a file often requires a new program, because it's a new, proprietary format, and not even your vendor's software can read it.

      OTOH, I have some "C/unix" programs that I wrote 20 years ago. I've reused them on dozens of different kinds of computers, and usually about the only problems are that the #include lines need to be rewritten. Sometimes I have to change a few variables to a different size int. But there is rarely any problem with my programs interoperating with other programs. This is shown by the fact that I always have a lot of scripts that combine my programs with other programs.

      The project I'm working on now consists essentially of "raiding" the data at a big corporation, and extracting as much info as I can from their old, poorly-documented files that are in formats that can't be read on any new computer. My code converts them to plain text, mostly flat files, a few HTML and XML files. They can be read on any computer that we copy them to. They can be dropped into a web directory and read from any browser on any computer.

      I'm doing all my work on linux boxes. I keep pointing out to them that my converted files no only work ("interoperate") with most any linux software, but will work on nearly any computer out there, and will continue to work for years. They believe me, because when they copy the files to their other random computers, their programmers don't seem to have problems with the file formats.

      Of course, one of the things they really want is to take the data and stuff it into a commercial database. The result will be data that can only be used by a timy amount of software from that database supplier. Well, that and the perl DB package (which we will note is Open Source). But note that they are doing what corporate management always wants to do: Put the data into a format that can't be easly read by other programs.

      In summary, I'd say that the Open Source environment, and more generally the non-proprietary parts of commercial unix systems, are by a large margin the best place to find interoperability. Closed, commercial systems can generally be summarized as "Your data won't work anywhere else, and won't even work on the same vendor's systems 5 years from now."

      At least that's the history that I've seen so far.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    7. Re:Because free software is not planned by kasperd · · Score: 4, Informative
      Even Linus is against the creation of standard interfaces internal to the Linux kernel.

      First of all it is important to keep in mind, that there are two different kinds of interfaces:
      1. Internal interfaces between parts of the kernel and kernel modules.
      2. External interfaces used by user mode applications.
      The later are aiming against complience with UNIX and POSIX standards. It is only the internal interfaces that can be changed without notice. But notice that as long as the interfaces are changed thorugh the entire kernel users are not affected. It does mean you cannot mix code from different kernel versions, but end users are not supposed to do that.

      Of course the changing interfaces are a problem for anybody who wants to develop closed source driver modules. But Linus and other kernel developers does not like closed source modules, the modules impose a problem on anybody who wants to debug kernel problems. So Linus certainly doesn't want to stop kernel development in some areas just to help developers of such closed source modules.

      Interfaces are not changed without a reason. Some developers of closed source modules might think interfaces are changed to annoy them, but of course that is not the case. However they do have to understand, that support from the Linux community cannot be expected before they open their own source. Hardware vendors must understand, that writing a closed source module does not make their hardware supported by Linux, a open source driver is needed before full support is existent.
      --

      Do you care about the security of your wireless mouse?
  2. One factor is obviously... by Anonymous Coward · · Score: 5, Interesting

    ...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.

    1. Re:One factor is obviously... by gl4ss · · Score: 4, Insightful

      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.
  3. It's the ego. by Martigan80 · · Score: 4, Insightful

    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!)
  4. Hrm by The-Bus · · Score: 4, Funny

    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.

  5. OpenSource creates de-facto standards by tjansen · · Score: 4, Insightful

    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.

  6. The real reason it doesn't happen is ... by nuggz · · Score: 4, Insightful

    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?

  7. Various comments by srichter · · Score: 4, Informative

    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
  8. Dubious conclusions using a limited data set by Anonymous Coward · · Score: 4, Insightful

    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.

  9. A vicious cycle is... by heretic108 · · Score: 4, Insightful

    ...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...
  10. Blindered developers by wowbagger · · Score: 5, Interesting

    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."

    1. Re:Blindered developers by aaribaud · · Score: 4, Insightful

      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

  11. Because it's hard? by IamTheRealMike · · Score: 4, Interesting
    I'm trying to create a packaging metadata spec at the moment to allow standardised LSB RPMs to be installed on all compliant distros using native dep resolvers etc - in short, making a standard that the relevant people can work to and are interested in is fantastically hard work. It's not just a case of writing something down and say "Agree to it!", everything has to be discussed, specified and of course there is always a slight worry in that you might be heading in the wrong direction etc.

    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.

  12. The Other Side of OSS development by jalilv · · Score: 4, Insightful

    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

  13. Advogato's number by infinite9 · · Score: 5, Funny

    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.
  14. It's quite simple, really by Fefe · · Score: 4, Insightful
    The main reason standards are not or only poorly supported are:

    1. the standard is not freely available (MPEG, all IEEE and ISO standards)
    2. the standard encompasses every other standard under the sun, and nobody can possibly support it all without licensing all the crap from everyone (this is actually quite typical these days. 100 companies come together and define all their combined "intellectual property" as an "industry standard" and thus force everyone else to license their crap from them. This is what happened to MPEG-4, and to an even greater extent, MHP (set top box standard, includes DVD, MPEG-2, Java, and much more))
    3. the standard sucks because it leaves ambiguities or simply assumes a lot of stuff that is not stated clearly. This is most often a problem of incompetence, because almost nobody is good in writing standards. You have either technical people who know what they are talking about but assume too much to write a good standard, or you have the technical writers who don't assume anything but don't understand what they are writing and thus produce absolutely unusable documents. This is an increasingly bad trend in RFCs, unfortunately.
    4. The standard is bad because it was written by an utter moron. This happens if marketing companies are trying to participate in a standards process because they think it will give them more credibility. The results are desastrous.


    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.
  15. Re:Great Article on Open Source by NewbieProgrammerMan · · Score: 4, Insightful
    From the eightballmagazine.com article:
    Of course they still need to learn to design with the user in mind. Make the software easy to use and install. The shorter the learning curve the better the design. And for gods sake write things that are what the end user wants... not what you want them to have. There is nothing more irritating to me then an arrogant nerd who can't understand why nobody will listen to him.

    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']