You have an excellent point. Three quarters of their revenue is from commercial licensing, which is to say, selling their software as proprietary under a proprietary license. In an all-free world, there would not be customers for the closed version, and Sleepycat would be making one quarter of the money.
Tim
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
Sorry, you remain mistaken.
The HTML 4.01 spec does not define buttons as generic containers; in fact, it refers explictly to their extra rendering requirements.
You have ignored the clearly defined meaning of "background," which is, in fact, "background."
When I pointed out that CSS3 is explicitly heading in the direction of "system standard renderings", you feigned ignorance of what "system standard renderings" meant. That's just sad.
The Mozilla page you cited does not note anything that could not be done with native widgets. There are no unsupportable requirements for "transparency and z-ordering" that either you or anyone at Mozilla has been able to find. Native widgets on both Windows and Mac have transparent backgrounds and draw in a z-ordered way.
In short, there is not a word of support for your position in any W3C spec, and there are plenty of words that say the opposite. The fact that CSS3 advocates "system standard rendering" is the smoking gun, but the situation was clear enough even without that.
Cygnus was successful because they did exactly this.
Cygnus was "successful" only in that it managed to sell itself for an obscene figure during the short-lived Linux bubble. It had been posting doubling losses ($1.5M, $3M, $6M) for three years previous to the sale.
I hate seeing Cygnus held up as an example of how to be successful, it sickens me.
Then don't. It was a money-losing company that went on to become part of another money-losing company. Not much of a success story....
Tim
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
There is no difference to CSS whether I have: <button>hello</button> or <div>hello</div>
No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.
Also please note that the CSS2 spec explicitly says that backgrounds should not be set for HTML items: The background of the box generated by the root element covers the entire canvas. For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the 'background' property for the HTML element is different from 'transparent' then use it, else use the value of the 'background' property for the BODY element.
For those of you with trouble reading spec-ese, this means a couple of things. First, the allegedly required functionality (widget background setting) is actually recommended against in the specification.
Second, the Mozilla implementation misinterprets the spec. Having a button on a BODY that has a background image or background color would create the same visual effect within the button's bounding box as setting the button's own background image or background color -- which is to say, a surround effect, not a fill effect.
The supposedly required functionality is not required, and Mozilla is interpreting the functionality in a clearly incorrect way.
Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading [w3.org]. Ultimatly while form elements may normally look like they've been rendered with this style sheet [w3.org] there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.
Nope, sorry, you're reading that wrong too. The goal there is to be able to use system default appearances, not to get away from system default appearances. Search for the string "system standard rendering" -- it appears many times -- and note statements like:
Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. This proposal extends them to provide the ability, through CSS, to style elements based upon their various user interface related states, and to make an arbitrary structural element take on the dynamic presentation, or system default look and feel, of various standard user interface widgets.
The exact rendering of check and diamond depends on the user agent, but it is suggested that the same glyph which is used on the platform to render a "checked" menu item be used for "check", and similarly for those platforms which support rendering of a "diamond" next to a menu item. Conformant user agents may render 'diamond' the same as 'check'. The radio- and checkbox- values are rendered as they are by default on the platform.
Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.
Tim
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button. Widgets are not required to be transparent and to show their background image through them. A correct interpretation would show, for instance, a normal platform button sitting within its box surrounded by, not filled by, the background image or color. See the CSS2 spec on this point.
If you were to interpret the background properties consistently as meaning fill color or image, then the text areas shown would be inconsistent. The characters would need to be drawn in their background image or color (as the widgets are), rather than on top of their background image or color.
The things on the page that appear to be correct w.r.t. the spec are doable natively. Widget colors are controllable on both major platforms. Frames and backgrounds for text editing areas are also controllable with native widgets on both major platforms. (Couldn't speak to Linux.)
In addition, no user agent is required to render every possible combination of CSS properties. See the CSS2 spec: A computed value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the computed width. The actual value is the computed value after any approximations have been applied. Sure, the more coverage the better, but does Mozilla render fractional border widths? Approximation of computed values in rendering still leaves a user agent conformant.
Tim
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 2
The widgets provided by the OS in 95/NT simply are not capable of being styled in the way CSS demands.
Can you name a single specific example of a CSS requirement that can't be met by native widgets on Windows and Mac?
If you can, you'll be the first since these discussions started, over two years ago IIRC.
Meanwhile, it is clearly a fact that Mozilla can't draw its widgets in the way that the platform standards on Mac OS (9 or X) and Windows XP demand.
Tim
MacOS's vastly inferior and triumphant rival
on
MS DOS: A Eulogy
·
· Score: 2
What I remember best about DOS as a Mac guy is this. From 1984 through 1994, there was no comparison between the two platforms. Ordinary mortals couldn't even install a font on their DOS machines, and keeping either DOS or the almost-DOS Windows 3.x alive required daily screwing around with the autoexec.bat and windows.ini files by skilled DOS maintainers. Applications and peripherals were opaque, balky, and unstable. The Macintosh worked -- DOS and Windows 3.x did not. Every TCO study showed order-of-magnitude gaps between the platforms, all in the Mac's favor.
Yet for all that time, the majority of the people in the industry insisted that DOS and Windows 3.x were superior, and the market share gap in favor of DOS was enormous.
Finally, when Microsoft won its IP battle against Apple and the reasonably usable Windows 95 came out as a clone of the Mac, the argument shifted overnight to say that Microsoft machines were now as good as the Mac, without any admission that they had been inferior for the last ten years. As soon as the revolution could legally be embraced on Intel hardware, it was instantly admitted that the Mac/W95 way was superior. The people admitting this were the same ones who had been insisting the Mac was inferior for ten years.
This historical hypocrisy was a measure of just how absurd and partisan critical standards are in the computer industry, how little the market can be trusted to select a superior product, and how little honesty is involved in platform advocacy. It has a great deal of bearing on current platform advocacy issues.
I was referring to end-user-oriented software, not server-side stuff targeted at programmers and sysadmins. With respect to Apache you are correct. It is possible that within the small market segment of programmer and syadmin software, open source could become dominant.
There is no reason for closed source software (and in fact no way for it to survive) in a world that has fully embraced an infrastructure of free open code.
I'm not sure if that's meant to be a tautology, but in any case, it won't happen. Open source software has not yet achieved parity with closed source software in key areas like usability and support, and it may never do so. Unless it does, the world will never embrace it.
Unfortunately, some people are still deluded by the notion that software has to be produced by a software company. Bullcrap.
All major open source projects have been financed for many years by software companies, who do most of the development themselves. The idea that open source is largely a volunteer movement is not accurate and has not been for some years.
Read the article again until you see the point: the USERS are the developers.
Which is great, as long as your target users are computer programmers. It doesn't work so well for the more general case.
On the other hand, if you're the owner of a closed source based company, I'm afraid you're SOL. I suggest you start thinking of ways to adapt before you go the way of the Dodo in the next 5 years. Survival of the fittest doesn't play favorites to the underdog.
Pardon me while I snort derisively. There is not a single major software market category where open source software has achieved the levels of user adoption currently enjoyed by closed source software. Predicting the death of an opponent that you have barely begun to even scratch suggests some kind of religious zealotry or Messiah complex. It is delusional.
The biggest problem I have with Open Source software is that there is this myth that because something is open, anyone can fix bugs and contribute updates. Well yes they can. But the problem stems from the lead time required to get the know the project, how it works, what does what and how different functions interact with each other.
You have an excellent point, and yes, startup time on Mozilla is considerable. There is a myth that in an all-open-source world, programmers would be freely dropping in to various programs to fix bugs as they came up. In fact, being able to effectively fix a bug in a large, complex software system requires a great deal of familiarity with that system in order to understand the possible consequences of the fix. Perhaps there is an internationalization standard which means your new dialog won't work for the users in Finland. Perhaps your code was checked in without understanding critical section synchronization locking and will cause the pre-emptive scheduler to crash once a week semi-randomly. Perhaps, as in Mozilla's case, the codebase is simply so vast and sprawling that you would have to practically live there to have a hope in hell of even finding the relevant code.
I've tried to start up on Mozilla several times. The problem is that it takes over a day just to set it up to build on the Macintosh. By that time, I have other pressing priorities demanding my attention. If I am then able to come back to it a few days later, I have to first refresh myself on the arcane build procedure, then start poring through thousands of files and trying to understand the intricacies of XPCOM and XUL, both of which have incomplete, badly written, and out-of-date documentation. I have never succeeded in doing this. I think I would have to carve off two weeks solid to become reasonably fluent and be able to start contributing. Unfortunately, I have a job and a personal life.
I had a similar experience when I thought an interesting project would be to find key performance issues in GCC and bring it closer to CodeWarrior performance. I searched for days to find a performance profiler for Linux that worked -- I was directed to a couple that seemed not to work, and somehow GCC itself doesn't seem to have one, unlike most commercial compilers. Looking into the GCC code itself, I realized it would take, once again, weeks of startup time to understand what was going on. I don't have weeks to spare, so I gave up. Sorry.
It really seems that contributing to large open source projects is less like dropping in to help clean up a house, and more like joining a religion. Which program you will be part of is a lifestyle decision. This does not seem to be factored in to the common idylls of open source distributed bug fixing. Yes, I could probably fix a bug in fetchmail or the average perl module in a few hours from a standing start, but not in any of the more significant software systems.
Tim
Re:Educated people don't need spelling checkers.
on
Mozilla Bug Week
·
· Score: 3, Insightful
If you habitually misspell words in your e-mail messages, the problem is likely to lie with your education rather than the software. Inclusion of software crutches for a wetware problem only makes the latter worse.
Utter nonsense. Typographical errors are a fact of life, especially for those of us with some degree of wrist problem. I was third in my state in the national spelling bee in the eighth grade and yet I thank the gods daily for the passive spelling checker in Outlook Express, which saves me from the errors of my aging eyes and hands. I only wish Explorer had the same capability in text areas.
Yours is more of the "blame the user" philosophy that is endemic to the UNIX world. Errors happen. Humans are fallible. Software should try to prevent them and help you correct them, not laugh at you for making them.
I can see a future version of open source, indeed, a current one for some people, in which writing software is just another part of daily life, like writing prose.
God, I hope not. Even most trained programmers can't program worth a damn. Some activities are intrinsically confined to a minority of the population, like fine art and engineering. They depend on rare aptitudes.
The thought of a world of software written by janitors and marketing people is frankly terrifying.
Given that the people most likely to participate in an open-source project are also users of the application being worked on, what would happen if the customers for a software product actually participated in its design and creation? It would be impossible to create a product that is not what the market wants!
Unfortunately, the only people who are able to participate effectively in the design and creation of an open source project under existing models are computer programmers. So yes, they will be able to create programs that computer programmers want to use, and they already have, which is why the only examples of open source successes the article could cite (Apache and BIND) are targeted at programmer/sysadmins. The problem is that the larger market doesn't want programs for programmers, and programmers are really poor at designing systems for non-programmers.
This is not to say there may not be future open source models which allow the participation of non-programmers, but so far the only way seems to be for companies to take losses investing in open-source development meant to unseat a closed-source competitor -- and this strategic pressure would not exist in the imagined open-source utopia.
How can user-centered design be reconciled with open source?
Tim
Re:There are lots of profitable open source compan
on
Opposing Open Source?
·
· Score: 2
Sorry, my friend, I think you're reaching. First you said that the annually doubling losses of Cygnus were the result of services bookkeeping practices. I checked and found out that an ever-increasing ratio of loss to revenue is not on anyone's playbook, professional services or otherwise.
Then it was that their spiraling losses were to expand their operations. But at the rate they were "expanding", they'd have been in chapter eleven within eighteen months without new funding.
Finally, you said that they were a success because they managed to get bought out during the Linux bubble. That's like saying VA Linux was a success because Larry Augustin got rich off it. Cygnus is now part of another unprofitable open source software company, Red Hat, which seems like a more accurate measure of their success.
The fact is that Cygnus was not profitable. Profitability has a specific meaning, and losing more and more money every year doesn't fit it, even if some of the people at Cygnus managed to make personal fortunes from a bubble-era rescue mission.
Tim
Re:There are lots of profitable open source compan
on
Opposing Open Source?
·
· Score: 2
Hi, foog.
If accounting practices in services businesses are as you describe, and such companies usually post a paper loss, then it seems difficult to determine whether they are actually profitable or not.
As you note, growing revenues would seem to be a useful heuristic in this case. However, what about the ratio of loss to revenue? In the years in question, revenues grew about 20-30% annually, while losses grew about 100% annually. Maybe it's just my software company background speaking, but it seems like that can't be good. If the two tracked each other upward and their ratio remained relatively constant, I could see that as a positive sign for a services business. However, I can't see how it could be a good situation if, with constant rates of change in revenues and losses, the company would face a loss the size of its revenues within one to two years.
Any idea what would cause this disparity in the rate of increase of loss and revenue? It seems to me it might well indicate an actual rather than a paper loss.
Tim
Re:There are lots of profitable open source compan
on
Opposing Open Source?
·
· Score: 2
Appart from the first year, Cygnus had a comfortable profit during their entire run. And that was well *before* the Linux hype started.
This is from their employees, if you have any hard fact showing they lie, show them or shut up.
It's a matter of public record that Cygnus was a money-losing business. Take a look at the Red Hat quarterly statement after the acquisition. The so-called lameness filter insists that it contains too many "junk characters", so I can't give you the table here. Search down for "3. BUSINESS COMBINATION (CONTINUED)". Cygnus lost $1.5M in fiscal 1996, $2.9M in 1997, and $5.8M in 1998. Its losses were nearly doubling every year. It was headed for yet another record loss when it was bought in 1999.
As he said, they have been around forever. That is an indication (not a proof) of profitability. If you have seen anything indicating otherwise, show them, otherwise it is just fud.
"Since 1994" is hardly "forever." It's seven years. Cygnus was around longer than that and they were bleeding money like a stuck pig. As I suspected, you can't support claims of their profitability.
A rule of thumb you might find helpful: When software companies are profitable, they don't remain private. There's no good reason not to take the IPO route and make the big bucks if you're profitable.
No, [Penguin] just had big layoffs
Big layoffs and profitability are not mutually exclusive.
If you're bucking for a (+1, Funny), you're out of luck....
Slackware employs four people. What basis do you have for saying it's profitable?
I don't think anyone denies that an open source business model may be able to keep a small group of hackers fed and housed in modest means, but that's not the kind of money that builds serious software or gets anyone rich. Slackware does nothing but package up software that other people have worked on. It's not a software company. It has no ability to do R&D.
I think your analysis is astute, even though it is speculative. There may turn out to be some countervailing factors you haven't noted.
So far open source solutions have not caught up even with maturing product categories in the application and toolbox space. It's not clear that they ever will -- it remains possible that basic flaws in the open source model will permanently thwart parity. Some of these flaws might include lack of usability testing and of professional graphic design, as well as fundamental hostility to the GUI paradigm .
It's also possible that there is not really such a thing as a mature software category -- that while categories go into local maxima where improvement slows to a crawl, they also will eventually experience paradigm shifts in which the rate of improvement resumes and accelerates. To take an overblown and unlikely example, if computer interfaces switched to direct neural interfaces, all end-user-facing software categories would enter a new period of revolution. Open source may always be in a mode of playing catch-up to commercial R&D when these revolutions happen, since open source's own record on innovation is fairly weak.
Nonetheless, I think your model is quite plausible and well thought out, and you certainly deserve mod points for it which you have not yet gotten.
Cygnus was profitable for years before being bought by RedHat.
No, they weren't. They struggled along for ten years without ever achieving sustainable profitability. The buyout was a rescue.
ADA Core Technology seems to be profitable (they've been around forever),
How do you figure that they are profitable? You get to look at the balance sheets of this privately held company? And how do you figure they're open source? It looks like it's "source included," not open source. There are no source downloads available on their site.
Mandrakesoft was profitable except for a brief stint where they were run by some flashy US CEO.
I've been calling out reasons for a while here. You could try going through some of my back posts for detailed arguments.
In general, though, open source software is inferior to its closed source counterparts in:
usability
aesthetics
integration with other software
performance
feature completeness
support
documentation
stability (at the application level -- not true for kernels)
ease of installation
support for hardware
availability of software
total cost of ownership (TCO)
Very little application or toolbox-level open source code is ready for prime time, in fact, whether we're looking at GCC, Mozilla, GNOME, KDE, OpenOffice, GIMP, or what have you. It's still hacker-oriented, better-enjoy-strolling-through-the-minefield stuff, and measurably inferior to proprietary solutions in most of the ways listed above.
One "killer argument" for many people here recently came in the form of consumer advocate Jamie Love's reasons for shifting his site away from an all-open-source footing.
Once it got into the interior file shares behind the FW there was hell to pay, since none of the users and managemnt want to be bothered with passwords for "communal" shares.... I would never have to accept this level of security with unix machines. The user could not possibly foul up the network with their limited permissions and access.
You might want to re-read your message. You're talking about a matter of administrative policy, not operating system capability. NT networking actually has a more flexible access control model than standard UNIX networking -- it's just as hard to understand, maybe even more so, but it has all the capabilities standard UNIX has as well as others. If your system administrators refused by policy to protect communal file shares under NT, it makes no sense to say they would have protected them better under UNIX, which doesn't have any better access control capability.
If we used the open-source alternative, we might have saved this money.
Ditto if you used Macs. The reason Nimda was targeted at Windows was because Windows was the majority OS. The reason there are fewer viruses for UNIX or Mac is because they are minority OSes. If UNIX or Mac systems were in the majority, then there would be more malware written for them and their advantages against viruses and worms would largely evaporate. It's not about open source, just installed base.
Not true at all. A big (BIG) company can afford to keep a staff of those developers for less than the licensing cost (perpetual or short term.)
There is some break-even point there, to be sure, but as you note, it's only at a very large company size (and this is just for bug fixing, not other TCO factors like support and usability). My observation is true for most companies, all but the very largest.
Another exceptional case is when a smaller company primarily relies on only a single open source product of significant size, in which case it may be feasible to keep someone around to work specifically on that product. But in the imaginary OSS-dominated world, this would be the case for no one -- all companies would be dependent on multiple large OSS products.
Not on a project of any significant size, you can't. Sure, for something simple like Apache, you might be able to do it, but just try to get anyone but a superstar engineer up to speed for major fixes on something like gcc, Mozilla, the Linux kernel, or OpenOffice in less than a few weeks per project. Depending on where you live, a week of programmer time might be between $1000 and $3000+ burdened cost. Most contributors to projects of this size have made a lifestyle decision -- it's not a job for paid mercenaries.
What you're saying seems to be beside the point. Yes, there are profitable services businesses. However, those services businesses do not use their profits to fund open source development. Those businesses that have tried to implement the tCatB business model in which services are used to fund open source development have found that it doesn't work, with Progeny and Lutris among the more recent examples. Services businesses require a significant outlay in terms of payroll and overhead for every dollar made, so they do not tend to have millions of extra dollars lying around for charitable projects; and creating open source software does not create service opportunities which exceed in revenues the cost of the open source development.
Slashdot Mirror
You have an excellent point. Three quarters of their revenue is from commercial licensing, which is to say, selling their software as proprietary under a proprietary license. In an all-free world, there would not be customers for the closed version, and Sleepycat would be making one quarter of the money.
Tim
Sorry, you remain mistaken.
The HTML 4.01 spec does not define buttons as generic containers; in fact, it refers explictly to their extra rendering requirements.
You have ignored the clearly defined meaning of "background," which is, in fact, "background."
When I pointed out that CSS3 is explicitly heading in the direction of "system standard renderings", you feigned ignorance of what "system standard renderings" meant. That's just sad.
The Mozilla page you cited does not note anything that could not be done with native widgets. There are no unsupportable requirements for "transparency and z-ordering" that either you or anyone at Mozilla has been able to find. Native widgets on both Windows and Mac have transparent backgrounds and draw in a z-ordered way.
In short, there is not a word of support for your position in any W3C spec, and there are plenty of words that say the opposite. The fact that CSS3 advocates "system standard rendering" is the smoking gun, but the situation was clear enough even without that.
Tim
Cygnus was successful because they did exactly this.
Cygnus was "successful" only in that it managed to sell itself for an obscene figure during the short-lived Linux bubble. It had been posting doubling losses ($1.5M, $3M, $6M) for three years previous to the sale.
I hate seeing Cygnus held up as an example of how to be successful, it sickens me.
Then don't. It was a money-losing company that went on to become part of another money-losing company. Not much of a success story....
Tim
There is no difference to CSS whether I have: <button>hello</button> or <div>hello</div>
No offense, but that's just not true. An interactive element is not an empty DIV. It has a content area. That content area contains a button.
Also please note that the CSS2 spec explicitly says that backgrounds should not be set for HTML items: The background of the box generated by the root element covers the entire canvas. For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the 'background' property for the HTML element is different from 'transparent' then use it, else use the value of the 'background' property for the BODY element.
For those of you with trouble reading spec-ese, this means a couple of things. First, the allegedly required functionality (widget background setting) is actually recommended against in the specification.
Second, the Mozilla implementation misinterprets the spec. Having a button on a BODY that has a background image or background color would create the same visual effect within the button's bounding box as setting the button's own background image or background color -- which is to say, a surround effect, not a fill effect.
The supposedly required functionality is not required, and Mozilla is interpreting the functionality in a clearly incorrect way.
Having said all that, current CSS recomendations may not be able to adequatly describe the visual rendering of all form elements but that is where we are heading [w3.org]. Ultimatly while form elements may normally look like they've been rendered with this style sheet [w3.org] there's nothing to stop the web author or end user modifying those attributes as they can any other attributes on any other element.
Nope, sorry, you're reading that wrong too. The goal there is to be able to use system default appearances, not to get away from system default appearances. Search for the string "system standard rendering" -- it appears many times -- and note statements like:
Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. This proposal extends them to provide the ability, through CSS, to style elements based upon their various user interface related states, and to make an arbitrary structural element take on the dynamic presentation, or system default look and feel, of various standard user interface widgets.
The exact rendering of check and diamond depends on the user agent, but it is suggested that the same glyph which is used on the platform to render a "checked" menu item be used for "check", and similarly for those platforms which support rendering of a "diamond" next to a menu item. Conformant user agents may render 'diamond' the same as 'check'. The radio- and checkbox- values are rendered as they are by default on the platform.
Again, for those who have trouble reading spec language, that says that CSS3 is meant to use default system widget appearances, and that Mozilla is not going to be able to support CSS3 because it uses its own non-standard widget appearances.
Tim
These are not correct interpretations of CSS. Background image and color are not the same as fill image and color, which is how these specifications are being interpreted in Mozilla. The background image of a button, for instance, is the image on which the button sits, not a fill image contained within a button. Widgets are not required to be transparent and to show their background image through them. A correct interpretation would show, for instance, a normal platform button sitting within its box surrounded by, not filled by, the background image or color. See the CSS2 spec on this point.
If you were to interpret the background properties consistently as meaning fill color or image, then the text areas shown would be inconsistent. The characters would need to be drawn in their background image or color (as the widgets are), rather than on top of their background image or color.
The things on the page that appear to be correct w.r.t. the spec are doable natively. Widget colors are controllable on both major platforms. Frames and backgrounds for text editing areas are also controllable with native widgets on both major platforms. (Couldn't speak to Linux.)
In addition, no user agent is required to render every possible combination of CSS properties. See the CSS2 spec: A computed value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the computed width. The actual value is the computed value after any approximations have been applied. Sure, the more coverage the better, but does Mozilla render fractional border widths? Approximation of computed values in rendering still leaves a user agent conformant.
Tim
The widgets provided by the OS in 95/NT simply are not capable of being styled in the way CSS demands.
Can you name a single specific example of a CSS requirement that can't be met by native widgets on Windows and Mac?
If you can, you'll be the first since these discussions started, over two years ago IIRC.
Meanwhile, it is clearly a fact that Mozilla can't draw its widgets in the way that the platform standards on Mac OS (9 or X) and Windows XP demand.
Tim
What I remember best about DOS as a Mac guy is this. From 1984 through 1994, there was no comparison between the two platforms. Ordinary mortals couldn't even install a font on their DOS machines, and keeping either DOS or the almost-DOS Windows 3.x alive required daily screwing around with the autoexec.bat and windows.ini files by skilled DOS maintainers. Applications and peripherals were opaque, balky, and unstable. The Macintosh worked -- DOS and Windows 3.x did not. Every TCO study showed order-of-magnitude gaps between the platforms, all in the Mac's favor.
Yet for all that time, the majority of the people in the industry insisted that DOS and Windows 3.x were superior, and the market share gap in favor of DOS was enormous.
Finally, when Microsoft won its IP battle against Apple and the reasonably usable Windows 95 came out as a clone of the Mac, the argument shifted overnight to say that Microsoft machines were now as good as the Mac, without any admission that they had been inferior for the last ten years. As soon as the revolution could legally be embraced on Intel hardware, it was instantly admitted that the Mac/W95 way was superior. The people admitting this were the same ones who had been insisting the Mac was inferior for ten years.
This historical hypocrisy was a measure of just how absurd and partisan critical standards are in the computer industry, how little the market can be trusted to select a superior product, and how little honesty is involved in platform advocacy. It has a great deal of bearing on current platform advocacy issues.
Tim
I was referring to end-user-oriented software, not server-side stuff targeted at programmers and sysadmins. With respect to Apache you are correct. It is possible that within the small market segment of programmer and syadmin software, open source could become dominant.
Tim
There is no reason for closed source software (and in fact no way for it to survive) in a world that has fully embraced an infrastructure of free open code.
I'm not sure if that's meant to be a tautology, but in any case, it won't happen. Open source software has not yet achieved parity with closed source software in key areas like usability and support, and it may never do so. Unless it does, the world will never embrace it.
Unfortunately, some people are still deluded by the notion that software has to be produced by a software company. Bullcrap.
All major open source projects have been financed for many years by software companies, who do most of the development themselves. The idea that open source is largely a volunteer movement is not accurate and has not been for some years.
Read the article again until you see the point: the USERS are the developers.
Which is great, as long as your target users are computer programmers. It doesn't work so well for the more general case.
On the other hand, if you're the owner of a closed source based company, I'm afraid you're SOL. I suggest you start thinking of ways to adapt before you go the way of the Dodo in the next 5 years. Survival of the fittest doesn't play favorites to the underdog.
Pardon me while I snort derisively. There is not a single major software market category where open source software has achieved the levels of user adoption currently enjoyed by closed source software. Predicting the death of an opponent that you have barely begun to even scratch suggests some kind of religious zealotry or Messiah complex. It is delusional.
Tim
The biggest problem I have with Open Source software is that there is this myth that because something is open, anyone can fix bugs and contribute updates. Well yes they can. But the problem stems from the lead time required to get the know the project, how it works, what does what and how different functions interact with each other.
You have an excellent point, and yes, startup time on Mozilla is considerable. There is a myth that in an all-open-source world, programmers would be freely dropping in to various programs to fix bugs as they came up. In fact, being able to effectively fix a bug in a large, complex software system requires a great deal of familiarity with that system in order to understand the possible consequences of the fix. Perhaps there is an internationalization standard which means your new dialog won't work for the users in Finland. Perhaps your code was checked in without understanding critical section synchronization locking and will cause the pre-emptive scheduler to crash once a week semi-randomly. Perhaps, as in Mozilla's case, the codebase is simply so vast and sprawling that you would have to practically live there to have a hope in hell of even finding the relevant code.
I've tried to start up on Mozilla several times. The problem is that it takes over a day just to set it up to build on the Macintosh. By that time, I have other pressing priorities demanding my attention. If I am then able to come back to it a few days later, I have to first refresh myself on the arcane build procedure, then start poring through thousands of files and trying to understand the intricacies of XPCOM and XUL, both of which have incomplete, badly written, and out-of-date documentation. I have never succeeded in doing this. I think I would have to carve off two weeks solid to become reasonably fluent and be able to start contributing. Unfortunately, I have a job and a personal life.
I had a similar experience when I thought an interesting project would be to find key performance issues in GCC and bring it closer to CodeWarrior performance. I searched for days to find a performance profiler for Linux that worked -- I was directed to a couple that seemed not to work, and somehow GCC itself doesn't seem to have one, unlike most commercial compilers. Looking into the GCC code itself, I realized it would take, once again, weeks of startup time to understand what was going on. I don't have weeks to spare, so I gave up. Sorry.
It really seems that contributing to large open source projects is less like dropping in to help clean up a house, and more like joining a religion. Which program you will be part of is a lifestyle decision. This does not seem to be factored in to the common idylls of open source distributed bug fixing. Yes, I could probably fix a bug in fetchmail or the average perl module in a few hours from a standing start, but not in any of the more significant software systems.
Tim
If you habitually misspell words in your e-mail messages, the problem is likely to lie with your education rather than the software. Inclusion of software crutches for a wetware problem only makes the latter worse.
Utter nonsense. Typographical errors are a fact of life, especially for those of us with some degree of wrist problem. I was third in my state in the national spelling bee in the eighth grade and yet I thank the gods daily for the passive spelling checker in Outlook Express, which saves me from the errors of my aging eyes and hands. I only wish Explorer had the same capability in text areas.
Yours is more of the "blame the user" philosophy that is endemic to the UNIX world. Errors happen. Humans are fallible. Software should try to prevent them and help you correct them, not laugh at you for making them.
Tim
I can see a future version of open source, indeed, a current one for some people, in which writing software is just another part of daily life, like writing prose.
God, I hope not. Even most trained programmers can't program worth a damn. Some activities are intrinsically confined to a minority of the population, like fine art and engineering. They depend on rare aptitudes.
The thought of a world of software written by janitors and marketing people is frankly terrifying.
Tim
Given that the people most likely to participate in an open-source project are also users of the application being worked on, what would happen if the customers for a software product actually participated in its design and creation? It would be impossible to create a product that is not what the market wants!
Unfortunately, the only people who are able to participate effectively in the design and creation of an open source project under existing models are computer programmers. So yes, they will be able to create programs that computer programmers want to use, and they already have, which is why the only examples of open source successes the article could cite (Apache and BIND) are targeted at programmer/sysadmins. The problem is that the larger market doesn't want programs for programmers, and programmers are really poor at designing systems for non-programmers.
This is not to say there may not be future open source models which allow the participation of non-programmers, but so far the only way seems to be for companies to take losses investing in open-source development meant to unseat a closed-source competitor -- and this strategic pressure would not exist in the imagined open-source utopia.
How can user-centered design be reconciled with open source?
Tim
Sorry, my friend, I think you're reaching. First you said that the annually doubling losses of Cygnus were the result of services bookkeeping practices. I checked and found out that an ever-increasing ratio of loss to revenue is not on anyone's playbook, professional services or otherwise.
Then it was that their spiraling losses were to expand their operations. But at the rate they were "expanding", they'd have been in chapter eleven within eighteen months without new funding.
Finally, you said that they were a success because they managed to get bought out during the Linux bubble. That's like saying VA Linux was a success because Larry Augustin got rich off it. Cygnus is now part of another unprofitable open source software company, Red Hat, which seems like a more accurate measure of their success.
The fact is that Cygnus was not profitable. Profitability has a specific meaning, and losing more and more money every year doesn't fit it, even if some of the people at Cygnus managed to make personal fortunes from a bubble-era rescue mission.
Tim
Hi, foog.
If accounting practices in services businesses are as you describe, and such companies usually post a paper loss, then it seems difficult to determine whether they are actually profitable or not.
As you note, growing revenues would seem to be a useful heuristic in this case. However, what about the ratio of loss to revenue? In the years in question, revenues grew about 20-30% annually, while losses grew about 100% annually. Maybe it's just my software company background speaking, but it seems like that can't be good. If the two tracked each other upward and their ratio remained relatively constant, I could see that as a positive sign for a services business. However, I can't see how it could be a good situation if, with constant rates of change in revenues and losses, the company would face a loss the size of its revenues within one to two years.
Any idea what would cause this disparity in the rate of increase of loss and revenue? It seems to me it might well indicate an actual rather than a paper loss.
Tim
This is from their employees, if you have any hard fact showing they lie, show them or shut up.
It's a matter of public record that Cygnus was a money-losing business. Take a look at the Red Hat quarterly statement after the acquisition. The so-called lameness filter insists that it contains too many "junk characters", so I can't give you the table here. Search down for "3. BUSINESS COMBINATION (CONTINUED)". Cygnus lost $1.5M in fiscal 1996, $2.9M in 1997, and $5.8M in 1998. Its losses were nearly doubling every year. It was headed for yet another record loss when it was bought in 1999.
As he said, they have been around forever. That is an indication (not a proof) of profitability. If you have seen anything indicating otherwise, show them, otherwise it is just fud.
"Since 1994" is hardly "forever." It's seven years. Cygnus was around longer than that and they were bleeding money like a stuck pig. As I suspected, you can't support claims of their profitability.
A rule of thumb you might find helpful: When software companies are profitable, they don't remain private. There's no good reason not to take the IPO route and make the big bucks if you're profitable.
Big layoffs and profitability are not mutually exclusive.
If you're bucking for a (+1, Funny), you're out of luck....
Tim
Slackware employs four people. What basis do you have for saying it's profitable?
I don't think anyone denies that an open source business model may be able to keep a small group of hackers fed and housed in modest means, but that's not the kind of money that builds serious software or gets anyone rich. Slackware does nothing but package up software that other people have worked on. It's not a software company. It has no ability to do R&D.
Tim
I think your analysis is astute, even though it is speculative. There may turn out to be some countervailing factors you haven't noted.
So far open source solutions have not caught up even with maturing product categories in the application and toolbox space. It's not clear that they ever will -- it remains possible that basic flaws in the open source model will permanently thwart parity. Some of these flaws might include lack of usability testing and of professional graphic design, as well as fundamental hostility to the GUI paradigm .
It's also possible that there is not really such a thing as a mature software category -- that while categories go into local maxima where improvement slows to a crawl, they also will eventually experience paradigm shifts in which the rate of improvement resumes and accelerates. To take an overblown and unlikely example, if computer interfaces switched to direct neural interfaces, all end-user-facing software categories would enter a new period of revolution. Open source may always be in a mode of playing catch-up to commercial R&D when these revolutions happen, since open source's own record on innovation is fairly weak.
Nonetheless, I think your model is quite plausible and well thought out, and you certainly deserve mod points for it which you have not yet gotten.
Best,
Tim
Cygnus was profitable for years before being bought by RedHat.
No, they weren't. They struggled along for ten years without ever achieving sustainable profitability. The buyout was a rescue.
ADA Core Technology seems to be profitable (they've been around forever),
How do you figure that they are profitable? You get to look at the balance sheets of this privately held company? And how do you figure they're open source? It looks like it's "source included," not open source. There are no source downloads available on their site.
Mandrakesoft was profitable except for a brief stint where they were run by some flashy US CEO.
Nope, they've never been profitable either.
Penguin has jumped back into profitability.
No, they just had big layoffs.
Tim
In general, though, open source software is inferior to its closed source counterparts in:
Very little application or toolbox-level open source code is ready for prime time, in fact, whether we're looking at GCC, Mozilla, GNOME, KDE, OpenOffice, GIMP, or what have you. It's still hacker-oriented, better-enjoy-strolling-through-the-minefield stuff, and measurably inferior to proprietary solutions in most of the ways listed above.
One "killer argument" for many people here recently came in the form of consumer advocate Jamie Love's reasons for shifting his site away from an all-open-source footing.
Tim
Once it got into the interior file shares behind the FW there was hell to pay, since none of the users and managemnt want to be bothered with passwords for "communal" shares.... I would never have to accept this level of security with unix machines. The user could not possibly foul up the network with their limited permissions and access.
You might want to re-read your message. You're talking about a matter of administrative policy, not operating system capability. NT networking actually has a more flexible access control model than standard UNIX networking -- it's just as hard to understand, maybe even more so, but it has all the capabilities standard UNIX has as well as others. If your system administrators refused by policy to protect communal file shares under NT, it makes no sense to say they would have protected them better under UNIX, which doesn't have any better access control capability.
Tim
If we used the open-source alternative, we might have saved this money.
Ditto if you used Macs. The reason Nimda was targeted at Windows was because Windows was the majority OS. The reason there are fewer viruses for UNIX or Mac is because they are minority OSes. If UNIX or Mac systems were in the majority, then there would be more malware written for them and their advantages against viruses and worms would largely evaporate. It's not about open source, just installed base.
Tim
Not true at all. A big (BIG) company can afford to keep a staff of those developers for less than the licensing cost (perpetual or short term.)
There is some break-even point there, to be sure, but as you note, it's only at a very large company size (and this is just for bug fixing, not other TCO factors like support and usability). My observation is true for most companies, all but the very largest.
Another exceptional case is when a smaller company primarily relies on only a single open source product of significant size, in which case it may be feasible to keep someone around to work specifically on that product. But in the imaginary OSS-dominated world, this would be the case for no one -- all companies would be dependent on multiple large OSS products.
Tim
You can fix it yourself.
Not on a project of any significant size, you can't. Sure, for something simple like Apache, you might be able to do it, but just try to get anyone but a superstar engineer up to speed for major fixes on something like gcc, Mozilla, the Linux kernel, or OpenOffice in less than a few weeks per project. Depending on where you live, a week of programmer time might be between $1000 and $3000+ burdened cost. Most contributors to projects of this size have made a lifestyle decision -- it's not a job for paid mercenaries.
Tim
What you're saying seems to be beside the point. Yes, there are profitable services businesses. However, those services businesses do not use their profits to fund open source development. Those businesses that have tried to implement the tCatB business model in which services are used to fund open source development have found that it doesn't work, with Progeny and Lutris among the more recent examples. Services businesses require a significant outlay in terms of payroll and overhead for every dollar made, so they do not tend to have millions of extra dollars lying around for charitable projects; and creating open source software does not create service opportunities which exceed in revenues the cost of the open source development.
Tim