tech/OpenSourceDeliveries written at 23:18:38; Add Comment
Open source projects and programs versus products
One of the things that the situation with security fixes and the Linux kernel changelogs illustrates is the difference between programs and products. With a program, what you get is the program; with a product, what you get is the program and a whole ecology of things surrounding it, ranging from documentation to backporting security fixes into older versions.
(This is why it takes a significant amount of effort to turn a program into a product, as Fred Brooks and others have noted. I credit Fred Brooks because I believe The Mythical Man-Month is where I first read about this.)
Some open source projects deliver products, so you get coordinated security fixes for old versions, planned release schedules, and so on (I would say that one example is Firefox). Other open source projects deliver programs, and leave it to other people to create products from them; I would say that these days, the Linux kernel is definitely an example of this. Understanding what you are getting from any given open source project is important, because otherwise you are asking to be disappointed (either in the lack of the niceties you expect from a product, or in a relatively plodding development schedule).
It might be nice if all open source projects delivered products, but there are two problems with this. First, turning a program into a product take extra work, which means that other areas of the project are getting less work; if you demand a product, you are implicitly demanding that the project move slower. Second, much of the work of turning a program into a product is tedious and thankless, which means that it is very hard to find volunteers to do it; at the extreme, if you demand products instead of programs, you get nothing.
My intuition is that the larger, more complex, and faster moving your program is, the more likely it is that you are going to deliver a program and not a product; you simply won't have the resources (in both time and interested people) to do anything else. (In light of this I am impressed with Firefox's ability to deliver an actual product. I suspect that Firefox is not quite as complex and fast moving as the kernel, but it is still pretty big.)
tech/DesktopIndependence written at 00:55:08; Add Comment
We don't really control user desktop machines
Here is something important: regardless of what people in IT like to think, we don't really control user desktop machines if the users feel strongly about it. We can try to dictate hardware and software standards and we can often get away with it for a while, but in the end if the users want something badly enough they are going to win.
This has really been the case for quite a while, but it is especially acute these days with desktops; the ultimate issue is that the users just have too many alternatives to whatever you supply, and thus too many ways around your limits. At the extreme, not only is perfectly capable desktop hardware available for a price that is almost within reach of the petty cash budget but many people have personal laptops that they can bring in and work from, basically ignoring your desktop.
Yes, you can start making policies and enacting technical barriers to keep these 'unapproved' machines off the network. That's the path to a scorched wasteland, where everything that IT provides is stacked up in a corner with a dustcloth thrown over it and the actual work all gets done entirely off your pristine network in whatever anarchic environment the users have built.
* * *
Atom feeds are available; see the bottom of most pages.