Simon Richter: Package management and components (aka "our users and free software")
Ian, I am not sure that “good package management” is a real selling point for anyone but system administrators.
Home users do not care, as there is not that much difference between double-clicking an executable (that pops up a window, asks a few questions and then installs the software) and selecting a check-box in a list and clicking “apply” (followed by window, questions, etc.).
In a business setting the users usually do not have permission to install software anyway, so they could not care less how it was installed, the only thing important is that it is there.
In my opinion, the single technology that has had the most impact would be COM, the “Component Object Model”, because this is what the ISVs want: an easy way to define a (binary) interface that will allow components from different vendors to work together, ideally in the same virtual address space for maximum efficiency.
The registry provides the necessary lookup functionality, so that you can construct an object of a given type by giving its class name or GUID to
CoCreateInstance, and you get something back that provides the interfaces that this class implements, which is either the object directly or an RPC proxy. The latter happens, for example, when a multithreaded application wants to call methods in an object that is not threadsafe (COM will then serialize the calls) or when the object is provided by a system service (where we have dbus).
The fact that the only thing you can rely on is the defined interface (a set of methods and data objects that map to getter/setter methods) makes it necessary to define the interface first and invest lots of Interfaces become immutable as soon as they are published, incompatible changes need a new interface name (that's where all the interface names ending in …2 or …3 come from).
Under Linux, the closest thing is GNOME and their use of CORBA. If you were to write an application that runs within the GNOME framework, and if you wanted third party vendors to be able to plug into it, then you would probably publish an IDL file for it. Lots of “if”s there.
Licensing is also an issue here. One thing the GPL fails to address, even in version 3, is the integration of components without linking into the same address space (which ORBit never does IIRC). Technically, the component provider and the component user communicate via sockets using a well-known protocol, so the component user is not bound by the GPL; the only thing that could be argued is that the IDL file defining the interface would be GPLd (although most jurisdictions consider interfaces as not copyrightable and/or permit “reengineering” for interoperability purposes). Some people might consider this “cheating” around the GPL, as any GPL'd program or library providing components could be used freely by any closed source application as long as the source code to the GPL'd portions was made available.
Last (but not least) it is a matter of developer motivation. Third party vendors are, for most of us, not our target audience, and properly supporting them is going to be quite a bit of work. I've written about mixing different C libraries in the same executable image before, as a “nice to have” item. For components that should share the same image, like COM does, it is an absolute must, and COM goes to great lengths to make sure this actually works. For example, allocating memory that is to be passed to a COM method must be allocated using midl_user_alloc() from the RTC DLL and freed using midl_user_free() from the same; as this is a system library and compiler vendors are forbidden from bringing their own, everyone uses the same allocator pair (that internally just calls malloc() and free() from the Microsoft C library, but that is an implementation detail you are not supposed to know).
On the Linux side, people do not care much about matching allocator functions, because in essence it all ends up in glibc's malloc()/free() anyway. When glib introduced their own allocators and started using them for their own structures, a number of applications started crashing unless you set a certain environment variable that told glib to pass everything through to glibc.
Personally, I've spent the last days compiling toolchains in order to provide compiler packages that work “out of the box” on at least Debian etch, lenny and sid, and Ubuntu dapper, edgy, feisty and gutsy. Right now, I feel a lot like shipping statically linked binaries. Where Windows has mostly gotten out of the “DLL hell”, Linux has built its own variant of it:- The Windows DLL hell
- is a hot place. Everyone is bringing their own grill lighter they believe does not cause cancer, starts a small fire and begins to roast marshmallows. The problem there is that the floor is covered with a sticky mixture of lighter fluid and everything is burning.
- The Linux DLL hell
- on the contrary is freezing cold. It has small isolated fires where a few friends are sitting, and they suddenly decide to move on and pour water over the fire and your marshmallows without asking first. Getting into a group is difficult, and if you manage it, all it means is that you are told to pick up your marshmallows before they extinguish the fire.
But how about keywords not being availble in grml-tips collection yet? What about keywords other users request but don’t get a match? Thanks to 
Do you want to submit the keyword 'nfs' to grml's keyword database?
The grml team will write tips for the most requested and useful keywords.
To use and contribute to this feature you'll need a working networking connection.
No personal data will be transmitted to the database.
Send "nfs" to grml's keyword database? [y N]
Keyword 'nfs' has been submitted to grml's keyword database.
Thanks.
%
All what’s missing now is a bot that writes all the missing tips on its own. 
Conclusion: make it easy for your users to submit information you might be interested in - to help your users.
