Linux Development Call To Arms

Hell O'World writes "This ZDNet Article points to the direction that Linux developers need to follow. Many people think that Linux needs an Office clone to gain acceptance, but the truth is that monolithic software is not the future. To get all of the functionality that anyone could possibly need in one place, the Office paradigm is to have everything there at once, and that takes a huge amount of resources to load, and years to learn. Linux will not gain converts by giving users the same thing, that they will then have to relearn. The power of UNIX is in connecting small, fleet-footed tools. What we need now is to create an environment, where users can easily create customized tools for the way they work, and developers can easily add new functionality."

Comments

Bundled/monolithic software

[syates21]

Microsoft killed all other word processor/spreadsheet vendors by having a more integrated package.

What makes anyone think people don't want bundled software?

Plus what he's talking about has already been done. Office is basically a consistently skinned collection of COM controls.

Re:Bundled/monolithic software

[_Quinn]

It's not /bundled/ software, it's software /that works well together/. Traditionally, the only route to integration was a single (or a few very tightly coupled) binaries. Now there's COM, which MS wrote basically because it was painful to make the office apps work together without it. However, the end-user can't choose what parts of office not to install (changing, with the `don't install until used option'), but certainly don't have the ability to to replace a crappy component that MS supplies with a better one from elsewhere.

The problem is more general than office software, though; the tendency in interfaces with GUIs has been to add complexity to the application and make it nearly impossible to use one part of it over another. KDE and GNOME's object models are working to address this; in fact, KOffice is (or shortly will be) `a skinned collection of KParts'. However, it's still hard -- and requires special tools -- to stitch these components together. There's no GUI equivalent to the command-line pipe/redirect paradigm, except for (rarely) in RAD tools for a specific toolkit/OE (e.g. QtBuilder(?), KDevelop); but these don't really function on the user level.

The most important part is that Linux has succeeded, until now, in replacing UNIX systems, because the cost of migration, especially in skills and time, is low (Linux is-a UNIX, runs basically all your standard UNIX tools, runs on commodity on NT-obsolete boxes, etc). The same is NOT true for migrating desktop boxes; I would argue a substantially lower TCO, but to make people /want/ to switch, you have to do _better_ than MS, not just match it/them (as worked for UNIX, except in price :))

-_Quinn

Comment removed

[account_deleted]

Comment removed based on user account deletion

Is this a battle Linux needs to fight?

[Infonaut]

I'm going to play Devil's Advocate here. I like the idea of small, lightweight software components for desktop computing, but this has been tried before. Here's the only link I could find to OpenDoc.

Basically, Apple's idea was to build small software components that could talk to each other and be loaded as necessary to accomplish specific tasks.

It was a great idea, and still is. I think the problem isn't so much the technology implementation as it is getting developers to see the benefits of such an approach.

Yes, developers. If you're running a software company, creating small components allows you less room to innovate on features. This in turn makes it more difficult to market your products.

I know your suggestion was that Linux adopt such a component-based approach for productivity apps, and it wouldn't seem that the limitations of the commercial world would apply. But the dominant paradigm in office computing is still the monolithic app, because that's what commercial developers are providing.

So for now at least, Linux developers will probably have to fight this fight alone. In order to convince users to make the shift away from MS Office, et. al., Linux apps have to offer a solution that's easier to use and faster by a factor of at least two. It's been shown time and time again that in order to overthrow a paradigm, the resulting benefits have to be not just incrementally better, but exponentially better.

Finally, is it even worth the effort? See the October issue of Wired, for an article by former Red Hatter Russ Mitchell, about why going after the desktop is a bad idea.

I don't think so

[elmegil]

What we need now is to create an environment, where users can easily create customized tools for the way they work

No. Not any more than we need to create an environment where users can easily create customized furniture, cars, or whatnot. The mass users you need to attract to make Linux *really* popular want these things built for them and delivered to them--they are not do-it-yourselfers like most of us who read Slashdot are. That is why, despite all their bugs, Microsoft continues to sell.

The "I Just Want to Type a Damn Letter" test

[mikosullivan]

While Soegaard provides some interesting ideas for tools that may be useful, his analysis of What Users Want is sadly off target. He seems to assume that users want lots of nifty features and inter-functionality. My experience providing tech support and teaching computers indicates something quite different: users mostly want a few basic functionalities, and they want them Right Now.

I call it the I Just Want to Type a Damn Letter test: can the user turn on the computer for the first time, understand the basics of how to operate in a few minutes, then get to work on things they want to do? If not, we'll meet with resistance at every step.

Soegaard provides some nice ideas on how to structure the back-end, but the front-end needs to Give the People What They Want: an interface to do word processing, another to do email, another for web browsing, and a few others for other less-common tasks. That is what is going to help open source win the battle of the desktop.

OpenDoc, NextStep -- GNUStep?

[Blitter]

As others have mentioned, the failed OpenDoc initiative was very much in this vein. NextStep (the "new" Apple initiative, now renamed Cocoa) has long had a reputation of allowing one to quickly string together custom applications from preexisting object classes, making it very popular in businesses that custom made in house applications. It is also worth noting that this framework allows for what are called "Services". Applications can "export" functionality to other applications. So for example you can hilite text in a text editor, then go to the mail services submenu in the system menu and from there tell the mail program to open a new message window with the hilighted item pasted inside. This also enables generalized filters, etc, in some ways like Unix shell pipes.

Of course, it's not open source, but what is GNUStep doing these days?