Miguel de Icaza's startup
El Volio writes "Yahoo is running a story about Miguel de Icaza's new company, focusing on GNOME software development." The new company's called "Helix Code", although that name's temporary. The plan is for all the products to be given away for free, and then charge for support, a common revenue model.
The title of this comment may be a little facetious, but for the most part it's true. Most home office users don't buy support contracts, either. Not even all small offices do, unless it comes with the site license.
The entire "give the software away for free and charge for support" concept--it seems to me--came from people used to the traditional market for Unix software and applications: enterprise customers, research facilities and universities. In those markets, commercial software is supported constantly by the vendor. It's most of what you're paying for--you're more or less buying the support for $20,000 (or whatever) a year and that includes "free" updates to the systems you've purchased. In this environment, charging for support for open source software is pretty natural.
In home and SOHO environments, though, this model is unprecedented, in a canonical sense of the term. Some software comes with 90 days of free technical support, and some companies have a "knowledge base" of software. And that's it.
The question is: are people really crying out to change that? Don't give me a "yes" answer too fast. Even most newbie Linux users are net-savvy enough to find a newsgroup to ask for support on or to use Red Hat's free knowledge base, and anyone can manage to get to their local Borders and pick up "Linux for Dummies."
And this is just for the operating system, which is generally the most complex piece of a desktop OS. The chances are that most users aren't going to have any problems with a desktop app that require a support contract--they might have trouble with installation, but that's it. Nearly anything else they can ask a friend, find a web page, get a book, post a message on a news group, and so on.
At risk of sounding doom-and-gloom, this is a problem I see with the entire "give it away" philosophy. Flame if you will, but as has been observed before, all software has development costs associated with it; the free software world has had the fortune that most of those costs have effectively been eaten by universities and a select few companies.
When you try to make money by starting commercial projects as open source, though, they need to end up paying their way somehow. Red Hat and Linux distributors to date have essentially sold neither software nor support, they've sold convenience. Red Hat wants to move to a subscription-based model, it seems, and that's understandable--each "unofficial Red Hat" CD someone buys with no support is an indirect material harm to their business. (Again, that sounds harsh, but if you sell at a profit margin of 50% and 60% of your potential customers get your product without giving you money for it, you're losing money.)
But can that really work for a "desktop application"? I'm not sure that it can't... but I'm not convinced that it can, either.
If control-C copies text in KWrite, try using control-C to copy text in KWrite and using Alt+V to paste it in Netscape. Control-C copies text in GTK+, so I copied a bit of text from a GTK+ application using control-C, and pasted it to Netscape using Alt+V. (The text was "eat me", a phrase that sums up my personal attitude towards Netscape's Alt-oriented key bindings.... Yes, there's presumably some reason why Netscape works that way. That's unlikely to make those key bindings less irritating to me....)
Probably not a bad idea.
Note that "X" has many levels - the core X protocol only specifies, as I remember, that the notion of "selections" exist, and the ICCCCCCCCCCCCCCCCM (Inter-Client Communications Conventions Manual, or so) specifies only that there exist selections with names such as PRIMARY ("the stuff that's inverse video because you selected it"), SECONDARY (does anything use this other than XView?), and CLIPBOARD ("the stuff that got copied to the clipboard, unless the CLIPBOARD selection holder exited - xclipboard will at least allow that to survive said owner exiting, although it may only preserver the text version of it) and, I think, the way they're intended to be used.
It's the toolkits and applications that implement stuff such as control-{X,C,V} as cut/copy/paste, and "paste primary selection" with the middle mouse button, so not everything running on X necessarily implements all those conventions, or implements them using the same mouse and keyboard bindings (for example, XView, being an OPEN LOOK toolkit, has its own keyboard and mouse bindings; the middle button, as I remember, means "extend selection" there, rather than "paste current selection").
If you have no such infrastructure, then everybody is left reinventing the same wheels, over and over again, in much the way that there is a host of graphics libraries for X.
And if you do have some such infrastructure, then you'll have to choose between "library sets.
Set up common document formats; note that both are using XML and SGML, and notably are using DocBook for managing the documentation. Improve the Docbook tools, and you help both.
Set up services that can be usable for BOTH. Both GNOME and KDE, for instance, have calendar programs that use common data storage formats; a "killer app" would be to create a calendar server that could allow multi-user access to schedules, and allow management of common resources.
But instead, you have to take a focus that assumes that they are mutually exclusive, when reality is that They are not exclusive.
And, in any case, how does Star Office resolve the "window manager and GUI classes" issue taht you seem focused on? It doesn't; it merely places control over the selection of such into Sun's hands.
If you're not part of the solution, you're part of the precipitate.
By the way, if you're interested in playing with selections, XEmacs is a great way to do it, since it provides direct low-level access, which otherwise you'd have to write C code to get. For example:
In a Netscape window, select some text with the mouse.
Fire up XEmacs, and switch to the *scratch* buffer. (This is a lisp-interaction buffer, if you type a lisp expression and then type Ctrl-j after it, it will evaluate it and show you the result.)
[TARGETS TIMESTAMP TEXT STRING LENGTH FILE_NAME OWNER_OS
HOST_NAME USER CLASS NAME CLIENT_WINDOW PROCESS COMPOUND_TEXT]
That just asked Netscape what data types it is capable of converting the PRIMARY selection to. The list was returned. Let's try type TEXT:
"xterm"
There's the text I selected in Netscape. Pretty basic, let's try another:
(0 . 5)
That says that 5 characters are selected (for not very good reasons, it's returning the high and low 16 bits of the 32-bit number as a pair of shorts. This is an emacs quirk.)
"file:/tmp/foo.html"
That's the URL of the document in which the selection exists.
(19110 . 3060)
That's a time_t of when the selection was made.
And so on... By letting the owner announce the types to which the selection can be converted, and letting the requester of the selection look at that list and decide which one they would prefer, very complex and efficient interations are possible. It allows format negotiation, and good decisions about pass-by-reference versus pass-by-value (e.g., if an image is selected, do you want its name, or its bits?)
Wouldn't it be nice if when you selected some text in Netscape, and you pasted it into a text editor, it was pasted as plain-text, but when you pasted it into an HTML editor, it was pasted as raw HTML, with formatting intact? Sadly, Netscape doesn't do that, but that's the sort of thing the X selection mechanism is for.