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."
Open Source just doesn't work, and never will. That's just how it is, there isn't any control or any integration.
OpenOffice + KDE + XFree86** != Productive Desktop Environemnt (for example).
The only times things do work is when they are centrally controlled, but that defeats the ideals of Open Source (Like Microsoft and Windows XP, well integrated).
**Excellent example of how Open Source doesn't work... on that note - You can't have a usuable desktop with XFree86 anyway.
Open Source works // False. // True.
Post above
sponsored in part, by Budweiser
WTF is a sig?
Heh, that's easy. The Microsoft programmers lost the specs for earlier WMPs and couldn't look at the code for them, so they just reinvented the wheel, rendering previous versions unusable.
Here Interesting reading
I'm not Seth.
RMS is the reason! I GNU it all along!
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.
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.
...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.
Yeah - let's just hope and GNU and Linux can get their act together sometime soon
</sarcasm>
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
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.
Can someone point me to the article that explains why proprietary, Imprisoned Source Software (ISS) does not interoperate well? Oh yeah, it's because of profit motives, monopolies, cultural differences, egoes, and "many other issues".
...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
Am I the only one around here that really doesn't interoperate that much? Aside from pasting the goatsex man picture in my emails, I really don't interoperate that much.
...
I have been known from time to time to use two different text editors on the same file! Egads.
But I never do something like... Write a SQL Query, and want in to be executed from a Word document each time the user opens the file.
In fact, I rarely, if ever, insert a Spreadsheet into a Word document. I know I can. I just don't.
We're starting to use XML, SOAP, WebServices. But really don't need to. Why create then turn a Java object into an XML document, send it over the wire, then convert the XML document back into a Java object. "Well... It's because later, something besides Java will be interacting with the system." I don't think so. Everything new we're writing is in Java. So, just regular Java RMI (EJB) will do.
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.
Interoperation means passing data between two different programs over some common bridge. This means typically writing some sort of connector code. In the best case, someone is able to bundle that connector cod into a library.
Consider coding to a web service interface such as SOAP vs. just keeping your application within one programming language and using its built-in constructs for passing data. With the web service, you either have to marshal into and out of SOAP envelopes on your own or use a library. However, not all libraries themselves interoperate. Hence, you have to test for compatibility by running against a suite of other implementations, all of which are also supposedly standard. It's the browser wars all over again. If you don't bother with interconnectivity, the job is over more quickly.
To get an interoperability standard that you can just code to seems to take the developer community years of effort. Yes, there is value to interoperability, and that is why people do actually undertake things like web services projects and spend years trying to develop standards. But for a first project, or even a mature, successfully functioning product, interoperability is not likely to be a first instinct.
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
> freedesktop.org, the cooperative effort between
> GNOME and KDE."
And Xfce, too.
But on the aspects of cooperation between Software Libre projects, the reasons are fairly dead-on. It's not easy to cooperate with someone when you aren't forced to. Hell, I can't even cooperate with myself somedays.
--
If I actually could spell I'd have spelled it right in the first place.
You might as well ask why doesn't closed source software interoperate.
In a perfect world everyone would write software that works together. One shouldn't only look at getting open source software to support a common standard, we should try getting everyone to support common standards.
It's not my expirience that getting open source software is all that hard. Getting non open source stuff to work with anything is hard. Closed standards is want gets in the way of interoperability. With open source you always have the option of adding the features you need. If two open source applications can benefit from working together, it will be implemented by someone who needs it. The original authors might not always see the need for a given feature.
I don't see it as a problem in the open source community. It's fare worse is commercial closed source software.
The great thing about standards is that there are so many of them.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
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.
> 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?
There is another thing, called 'messaging'. It is part of the OS, at least. I guess messaging is used on many levels... I think there are some standard high-level messaging APIs as well, apart from the low-level OS stuff.. but the problem with those is that they are somehow associated with a particular desktop. I find that strange.
I miss my rubber keyboard.(Homepage)
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
The premise is wrong. Interoperating is hard, often not worth it, and sometimes downright bad. But to the degree that anything interoperates, open source probably generally does a whole lot better than proprietary software.
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'."
I think Unix/Linux integrators keep frittering away opportunities, since they don't want to really standardize on a directory layout/interface for common utilities. I think some of this happens due to laziness (two competing versions are implemented concurrently but the authors don't unify their interfaces), but as djb says there is a short term local reward for fragmenting the interface that the integrators choose in spite of the long term global penalty. This has held Unix/Linux back in my opinion, since code developers and administrators hate how these incompatibilities make it difficult to configure/install software properly.
doing good things, & simply acting out as greed/fear based LIEforms.
turns out only about 1% of US, are FUDging up the hole 'works', buy insisting that being fraudulent stock markup billyonerrors, is good for the other 99% of US. the evidence of that is...?
lookout bullow. consult with yOUR creator regarding matters of the heart/mind/wallet. that's the spirit.
Really? If so it is only because your browser is compatible with a fraction as many p0rn sites.
The OSCOM 3 conference is on May 28th-30th in Cambridge, MA.
Midgard Project - Open Source CMS
Open Source doesn't conform to standards?
DNS?
Sendmail?
These aren't standards compliant?
And now you're going to tell me WINS and Exchange ARE?!
Perhaps the problem is not that "open source software doesn't conform to standards." Perhaps the problem is that "modern software considers itself too good for standards," which is entirely a different problem and isn't open-source specific.
-JDF
The real reason, I believe, has to do with the fundemantal drive behind an open-source project -- find an itch, then scratch it. OSS projects (in general) start because someone sees a specific need or want for software that performs a specific purpose. By its very nature, that project is looking at the world in a bottom-up fashion -- and that inevitably pushes interoperability off until "later".
Integration or interoperability is typicaly an "add-on" to an already successful project -- no one really starts thinking about "well, I'd love to be able to do X from program Y" until both projects X and Y have developed strong user bases. It's sort of a natural selection in software -- the "best" projects survive and eventually breed (interoperate) with other projects to evolve higher-order software.
Of course, that's just my opinion. I've been known to be wrong... though of course, those who discover that have been known to disappear...
I thought that was the reason Perl, Python, and sockets programming are so popular.
This is a non-starter for me; I've never been hampered by interop problems with open source software.
Authors of open source start out to solve their problems, not mine. I can solve my own problems with readily available tools.
... if I'm starting a new project, it's usually because what exisits already, whether a standard or not, just doesn't work for me. Now I may or may not incorporate standards into a project depending on what I need and whats available, but I may not.
Now I'm not working on any grand applications, and I'm not trying to solve the worlds computing problems, just mine. I suppose this could be loosly defined as an ego issue, but I assure you I don't think it's because I'm better then anyone else, it's just because I want something to work differently or work in some specific way.
I would imagine that the majority of open source projects start ou this way. That said, I think there are a number of open source projects (more and more lately) that do adheare to standards more so infact then many commercial projects, it all depends on where you look. The nice thing about the open source stuff... if you don't like it, rewrite it, or use something else, or pay someone to create what you want if you are so inclined... it's all about choice.
--- Nothing To See Here ---
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.
And X Windows is open source - see x.org.
Let's see your toy M$ box do that.
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.
Here are my favourite quotes:
WTF?! It's like Homer Simpson on acid!
These guys are absolutely hilarious! I sure hope it's actually a Monty Python type thing going on there, or else I feel really pityful for them. Just imagine what their standard documents will look like if they can't even state what they are doing on their web page coherently!
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.
djb is a very odd sort of person to be complaining about others fragmenting standards. Consider daemontools vs. how-everyone-else-does-it for a prime example.
"Do as I say, not as I do", perhaps?
But I can display X11 from HPUX or Solaris back to a Linux box no problem - I do it all the time. As for being tied to certain fonts or extensions, that's not "X11-compliant", now is it?
And if you want to see "less than certain" behavior just put your WinNT box on "large fonts" - that's not even "interoperating" and it fubars your display.
For the sake of discussion, here's what I think.
The reason I'm seriously contemplating switching to OS X is because they have shareware that is worth paying for. I don't mind spending $10 on a nice editor or a utility that saves me some time.
On linux, there are a lot of diamonds in the rough in terms of software, but majority is... well, incomplete. I can't complain, because it's free, and because who am I to say how people are to spend their time?
What is true, however, is that there is no motivation for a hobbyist to follow standards if he doesn't want to. If however, there is at least a $5-$20 contribution from the users, then there is at least some weight to the user's request. An honor code if you will.
Simply put, I'm starting to see where shareware might fit in this world, and it's basically a way to transition a hobbyist project to something more mature and useable.
-Nikita.
When standards exist, Open Source projects are frequently better about following them then closed source projects. But not necessarily. If the developers consider that the standard is really broken, then they'll ignore either it or parts of it. The only difference from closed source projects is that they won't break the standard in order to keep you from working with something else.
When standards don't exist, nobody complies with them. If something is patented, then it obviously can't be standard in any meaningful sense, unless the patent is freely useable for all standards conforming uses. Some "standards" bodies don't seem to understand this.
And when personalities come into conflict, all conformance can go by the wayside.
If I look over this list, the Open Source software generally comes out at least as good at standard conformance as the proprietary software. If for not other reason, because if it's easy to put standard conformance into a project, it's reasonably easy to retrofit it in. And features tend to not get removed (though they can be turned into compile-time optional features).
Over cycles of iteration, Open Source software either becomes standard conforming, establishes a standard, or becomes irrelevant. (I.e., evolution in action.)
E.g., would you rather try to read MSWord documents with OpenOffice, or to read OpenOffice documents with MSWord? MSWord has a positive benefit to MS with breaking adherence to the file format used by the previous version. It causes people to buy the new one. OpenOffice has no such benefit to the producer, and this is a benefit to the user.
I think we've pushed this "anyone can grow up to be president" thing too far.
I've read a lot of comments here, with some interesting points, excuses, or disagreements on the premise that OSS doesn't support standards.
/bin/sh. WHY???!!!!
/bin/sh-like shell that I can't `echo "hi!"` in????
:-), consider my question closely. sh, ksh, zsh, ash, and every other shell that uses sh syntax (i.e. not the csh variants) deals with the above statement in the same way. Bash doesn't.
Bash supposedly conforms to Posix standards if you invoke it with the --posix flag. (Why it shouldn't default to posix-compliant I don't know) However, bash is not compatible with
Will someone tell me why bash is the ONLY
In case anyone things I'm just ranting (I probably am ranting, but that's not all there is here
Why would OSS deliberately develop a shell (the default universal Linux shell no less) that breaks such a fundamental and long-standing de facto standard?
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
"cooperative effort between GNOME and KDE"...
one worrd for you RMS
The war with islam is a war on the beast
The war on terror is a war for peace
Since when is freedesktop.org a successful example? What did they achieve yet besides specifications?
Oh, and BTW, what's an EGOE?
Egoe is what you get when you copy-paste part of the summary from the article's original authors.
Midgard Project - Open Source CMS
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."
The nice thing about standards is that they are so many to choose from.
One huge reason is bloat. Some applications have very robust messaging libraries/interfaces for third-party interoperability, but if you have to include tons of libraries and such... it makes you think twice. And that goes for any types of applications.
Though old, the "pipe 'ole ASCII" format is very lightweight. Very easy to write. Extremely fast. Less headache. And requires no library dependecies with the third party software you're trying to talk to.
Lots of people prefer this method as opposed to CORBA, JMS, IIOP, RMI, or any number of interoperability protocols out there. Which is apparrent because of the vast number of projects which still used piped-stream style ASCII communication.
That reminds me about some really big an wide used moleculas simulation program, it has a really big university to support it, and som 12 -15 years in development. The damn program is not compatible with itself even between subsecuent versions, still !!, i have listened experiences of more that 3 simulations with-the-same version, but that is had some errors, that made every simulation inconsistent with the others ! And there is a nice project (Open source) that has proben to be faster, and more reliable, that is used like 10 times less that the other !! nice isnt it ?
I'm positive, don't belive me look at my karma
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.
mechanisms for defining rich, concurrent interfaces have been in common use for ages everywhere else?
.NET now.
You must be talking about OLE. No, wait, DDE. No, now it's COM. Oops, I blinked and everyone's using
(disclaimer: I am not an MS developer, thank god.)
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.
I wrote a ftp API an a network client located on http://j-ftp.sourceforge.net
;)
It is GPL, but it is stable and even javaworld has an interesting html table comparasion (link on the homepage) which shows that it is superiour to most apis out there in many cases, because no api implements *all* standards.
It is that good because it was designed completyle following the rfc and is imho fully rfc 959 compatible. That took its time, almost 3 years now, but i don't think the api could not be used in a productive environment.
just my 0,019725 euro
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
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.
That's an interesting example you used. Because many people, including myself have tried to get an LDAP or pluggable authentication system into Post Nuke and failed. PHP Nuke situation is worse, the guy does not release development versions of PHP Nuke.
The problem was not that they did not need to. Those applications are modular, but not *that* modular. You still have to patch the source a it to abstract the authentication functions. I have, and others as well pleaded to be allowed to contribute pluggable authentication ( at the maintainers discretion ), but with no success. At one point there were 3 or 4 independent implementation of LDAP/pluggable auth modules for Post Nuke, but no feedback what so ever from the maintainers.
My take is. Many projects are very poorly managed. It's that simple. Just the act of reviewing code and providing feedback on code they don't really need themselves is too much for them.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Put like that, it's perhaps not too surprising that the workshop was useful. I'm not being sarcastic here: I think the organisers deserve kudos for recognising an area where cooperation was feasible and taking on the responsibility (and associated hassles and risks) of organising the event with fellow interested parties. Acks also to the sponsors for making it possible, and the more such events the better.
Now, if someone could come up with ways for people to communicate productively without meeting personally and without being predisposed to cooperate in the first place... well, I'd suggest you keep quiet unless you want to be nailed to a tree to die of thirst.
I think this discussion is vital for the future sucess of OSS. As others have noted, some projects take the view that "We don't follow the standard, we make the standard." I don't feel like this is a good approach and I think the article correctly identified cultural biases as a major obstacle to interoperability. We recently saw this taken to the point of actual aggression between two projects with the Firebird DB/Mozilla Phoenix debacle. Maybe a little unrelated, but the reaction of the FirebirdDB team was disheartening, and IMO, a quite devastating blow against the Open Source movement as a whole. This article is very timely.
"It's Dot Com!"
If you bastards have a better way of doing it, why don't YOU develop some of YOUR ideas?!
True the little projects are not planned, but the big ones are. Most developers of things like Apache, Linux (kernel), freeBSD, Samba, etc will tell you that they now plan all their new features. Samba just got a major re-write that was planned (still in progress if I remember right). Note that with the possible exception of FreeBSD all these started out unplaned, but as things grew programers realized that they could not put the changes they wanted in without planning a head. (FreeBSD is only an exception because it started with a large code base that had been planed for years)
For small projects I doupt there is much planning, but then much less is needed. Remember "plan to throw one away, you will anyway"? Many projects are still in the version one throw away code stage. There is no reason to designe your code until you have an idea of what problems you will encounter late. Better to make something that sort of works, and then decide if you need a plan for version 2 to solve those problems, or a plan to solve those problems in version 1. A plan is pointless if you don't know what to plan for.
Most people don't realise how much work is done behind the schene. We don't normally see it. It is there though at some level.
I had been doing an open source project recently for the past few months. I never really attracted any users. I only know of one person who got it to compile and work.
What really perplexes me are the projects which have managed to get people interview them and discuss the project, and yet after 3 years they still have not released anything.
Or those projects that existed for about 10 blips of a microsecond, got lots of hype and coverage, but you can not get them anymore. They are gone.
I at least did what I said I was going to do and it works. Maybe it doesn't look pretty (there is no such thing as an Open Source Artist people). Maybe it is hard to use (WTF do you expect for free? Blood?). Maybe it's a total hack job. But I did it and at least I can walk away from you all feeling doped out buku-good.
The problem is you people expect this stuff to rival professional software on Windows, and yet maybe 1% of you actually understand it is hard work and takes alot of time. Most of us are not getting paid to do this. And when you get cold shouldered, ignored, and flamed by morons about how the program sucks, it doesn't help very much.
I will continue to work on Open Source but I am not trying to impress people nor do I care whether they use it or not. It is open because I know that someone out there might be able to benefit from it who can't afford the pro stuff, and appreicate it, and for that one person, that is who I am working for.
Whatever projects I find useful I always write to the developer and say thanks. Why? Because I've been in there shoes. 99% of them are doing it for free. They do it because they want to do it. They do it because they love it. That is why I do it. That is why I will keep helping Open Source projects, and making more code.
Until you actually have to work hard for what you have you will never appreciate what you have.
The reason Open Source is so diverse and uninteroperable is because it encapsulates the spirit of the whole movement to begin with. It began as the pet project of a bunch of people who wanted to hack on code. They do it because they like doing it. Now it's a clique thing where it's cool to be a part of it. When it first started (and I've been in and out of this scene for 8 years now) nobody knew what open source was about. Linux? What the fuck is a linux?
The system was funky ass and I remember blowing up my monitor trying to get X-windows to work. Yeah it was not anything like what distributions are like now.
The reason the state of Open source is not rivaling the stuff on Windows is because 99% of you expect it but don't want to put the hard work into making it happen.
The Spirit of Open Source is the lone hacker against the system. Hacker's hate standards. They hate coding conventions. They hate shit that is closed and they can't tweak the code. They hate whiney users who are to lazy to figure out how to work shit and won't type man. The whole spirit of it is to make people get off their lazy ass and dig into things and find out how they work. It's not and never will be a plug-n-play system where everyone gets along and everyone speaks the same language and looks the same. It isn't going to happen. It goes against the whole philosophy of what the system is about: being free, rebelling against the corporate bullshit that chains you down and makes everyone write code the same way.
If Linux becomes some standardized, plug-n-play, corporate system, I will find some other operating system to use and be a part of. I come to Linux specifically to get away from that very shit.
I like Linux not because I think it's user friendly but because the people making things are Linux are truly innovative, and yes, it is much harder to get working than Windows, but it's worth it, because it is far more flexible and configurable. But it takes work to figure the stuff out.
I'm not against people taking the system and using it to make money with, or making distributions that do all this stuff for
Bringing this conversation full circle ...
One important thing I think some folks are missing about the standards argument is that no one is suggesting the OSS be legislated to use any given standard. As folks have mentioned, that flys in the face of the OSS ethos.
If lone devs want to work in isolation, then have at it. Some of the most brilliant men in history have worked as hermits. This discussion is not about making the lone wolf feel like he should "get with the program".
Rather, the discussion focuses on making things simpler for teams of OS devs. THe Team for Product X requires standards against which they should develop, else none of the code will fit together. We all naturally do this when working in a team.
All that is being suggested is that Standards are required for Team X and Team Y and Team Z to connect their individual products in meaningful ways while not reniventing the wheel.
If your product can or should operate in complete isolation, don't adopt the standards. No harm, no foul.
UNIX is not object-oriented, so what exactly would be put in a standard unix component model? UNIX has got shared memory, named pipes, sockets, unidirectional pipes, and message passing (System V specifically), RPC, and lots more remote capability than Windows has. What would an OS's base services require from a component object model? Does microsoft use them in the base of their OSes?
COM is primarily for GUI and GUI-development, and X has a multitude of toolkits on top of its native Xlib (which is highly standardized and backward compatible both at compile time and run time). It works quiet well, if not as polished (text cut and paste works in X, but dragging and dropping 'objects' between applications is unsupported). You are confusing 'user interface' with the system: the system can have multiple orthogional interfaces (CLI vs. GUI as one example).
> What would an OS's base services require from a component object model?
An OS wouldn't need a component model if you define 'OS' to be Unix V7. The world has progressed since then (think OSX vs. Darwin).
> Does microsoft use them in the base of their OSes?
Well, insofar as windows shell services is part of the OS (try uprooting explorer.exe from the system, you can't), COM is very much there. (remember, from MS' standpoint, the irreplaceable shell (like Apple's Finder) is a feature, not a bug)
> COM is primarily for GUI and GUI-development
Not necessarily. COM has been used for lots of other things, including remoting and message passing. It's (relatively) hard, I grant you -- which is why both Java/.NET/Mono are the way forward.
> UNIX is not object-oriented
And that is really the root of all this. The services a plain Unix core provides is minimal. IMO Apple did the right thing -- took a core and added some really sweet proprietary stuff around it to make it usable*. Will some company is able to find the courage to do the same under the GPL? I don't know.
*usable to end-users, of course. Unix's bare-metal philosophy actually makes it more usable, not less, to people who actually want to build custom solutions, like Google's cluster or a MASSIVE render farm.