Editors' Note: The following is the text of the current SuitWatch newsletter, by LJ senior editor Doc Searls. Subscribe to SuitWatch here.

Hollywood movie sets make a distinction that would be good to borrow for software. Sets that are actually useful--kitchens with running water, floors that bear weight, roofs that keep out rain--are called "practical". On a typical set one commonly sees signs that say, "WARNING: This is not a practical balcony." The Old Tuscon movie set, for example, was built in 1939 by Columbia Pictures, and for decades it served as an all-purpose Western town for dozens of movies: The Last Roundup, Winchester '73, Gunfight at the OK Corral and many more. These days it's a tourist trap that boasts "75 buildings including 32 practical buildings." Meaning 43 buildings are there only for appearances.

We might say the same thing about software boasting features that exist for the sake of appearances. The features might work, but how many of them are actually practical? Or barely practical? That's what you tend to get with a lot of commercial software. To keep you buying, the vendor piles on features that attract purchase more than use.

What if software did what you wanted it to do, for as long as it could, without breaking down or causing problems for everything it touched? What if less really is more?

Those questions are old hat for free software and open-source hackers, but they're new hat for big enterprises. Two years ago, the purely-practical software hat looked weird on the average corporate IT department, like a Stetson on a monk. Now it looks like a fit.

Still, we're not reading much about it. Instead we read about other reasons for Linux's success, such as cost and ROI. Cost is an unavoidable topic, of course. Linux's platform costs range from cheap to free, while its commercial competition ranges from expensive to prohibitive. It's hard not to make comparisons. As for ROI, it's an issue only because Microsoft has been funding FUD about it (most recently with a commissioned survey by IDC). But ROI is a non-starter in a depressed economy. These days suits get fired for calling expenses "investments", especially when the purchased goods perish so rapidly that the costs of replacing them might as well be charged as rent.

I think the Linux hat fits corporate IT because there's a good value match between Linux and the way large organizations like to work. That may sound a bit oxymoronic to some, because Linux is not by nature a commercial operating system, and many businesses built on commercializing Linux have notoriously failed (Mandrake Linux being the latest example). In fact, though, most software at big organizations isn't commercial, either. As Eric Raymond says in The Magic Cauldron, most IT software has use value, not sale value.

What are those use values, exactly? There's usability itself, of course, plus reliability and security. But those are the obvious ones. What are the subtle, less obvious ones?

For an angle on that, take a look at what's going on with Chandler, the new open-source personal information manager being developed by the Open Source Applications Foundation. OSAF is funded and run by Mitch Kapor, the commercial software veteran who founded Lotus and the Electronic Frontier Foundation. On Chandler's Architecture page, a list of "Guiding Principles" includes these items:

Now port that list to the inside of any IT shop, and you see why Linux just keeps seeping on in, pulling in other open-source software along with it.

Where that software faces the Web, open-source components tend to fall in the LAMP family: Linux, Apache, MySQL and various other pieces that begin with P, including PHP, Perl, Python and PostgreSQL. Elliot Noss, President & CEO of Tucows, recently told me that most of his company's use-value software is in the LAMP family, primarily using Linux, Apache and PostgreSQL. (I just noticed on Netcraft that Tucows has gone 400 days since rebooting its Linux servers.)

I find myself wondering what happens to the bureaucracy, or what replaces it? As companies shake off their dependencies on outside commercial vendors and consultants, what internal groups take over? Is there a categorical name for them? What are the new policies? How does bug tracking change? To whom do employees report problems, and how are they handled? Is discussion software used? Wikis? Mail lists? IM? Something else?

If you have any answers to those questions or better ones of your own, please send them along. I'm doc@ssc.com.

Doc Searls is senior editor of Linux Journal.