I never said they are making a profit... Are they making money?
Um, er, what's the difference again? Making revenues is not particularly useful if they don't exceed your costs of doing business. There are definitely open source companies making revenues, but "making money" in its usual usage means that one is making more money than one is spending, and Red Hat is spending more than it is bringing in.
(Yeah, I know that's an oversimplification, but I don't feel like going into the whole issue of goodwill and intangible losses right now. Not all the money Red Hat is losing is money it is spending, technically speaking. But by GAAP it is losing money. This may change soon, or it may not.)
That's good. Like I said, you may have good prospects. I just think it's a little early in your corporate history for the company to start getting cited as a success story. Sustained profitability is the measure of business success, and you're not yet there. But I hope you do become a success story, and it sounds like you have a pretty good shot at it.
I work for MontaVista Software, an open source company. I'm not sure I'm free to discuss our financial situation, but suffice to say we're going through this "slump" just fine.
Really? It looks to me like your growth has stopped -- there's only one job opening for the whole company. Your end of 2000 announcement discussed ten-time revenue growth (from what? it's your first full year), and growth from twelve people to 160, but it was conspicuously quiet on the question of profit. Meanwhile, at that resource load, you're probably burning through the $30 million in investment fairly quickly, though by my back of the envelope it shouldn't be all gone yet.
Don't get me wrong -- you may have good prospects in the future, but it does not appear to me that you are now a profitable company, and the dearth of new job openings is a disturbing bellwether for future growth potential. If you're doing "fine" now, that may only mean that you haven't yet spent all your investor capital.
I am very happy these people are making money off of Linux.
They're not. Red Hat is losing money on Linux, and has been for years. Check out their profile: "For the six months ended 8/31/01, revenues fell 1% to $46.7 million. Net loss totaled $82.9 million, up from $37.4 million." Their loss more than doubled from the previous six months, and their loss was 177% of their revenues. Revenues are declining, though only slightly. Funny way to make money if you ask me.
Why is it that statements on/. about particular open source companies being profitable almost never seem to get corrected, even when many of the readers know better? Is the profitability falsehood one that has been designated as socially acceptable?
Michael Tiemann: Well, as a matter of fact, we were profitable, increasingly profitable, every single year until we attracted so much attention that people wanted to invest money in Cygnus. That happened in 1997.
Red Hat S-1A Filing, January 28, 2000 (search under "3. BUSINESS COMBINATION (CONTINUED)") says that Red Hat lost $1.5M in fiscal 1996, $2.9M in fiscal 1997, $5.7M in fiscal 1998, and $6.4M in the nine months before it was acquired.
Sleepycat employs under twenty people, as does ACT. Peter Deutsch is one person, and may well be discussing a modest retirement in Wisconsin, which is dirt cheap.
So that's less than forty people, none of whom have had the payoff of a second-tier engineer in a moderately successful IPO.
So you get this impedance mismatch and a pile of code whose sole purpose is to rewrite the data structures used in the program so that they match the data structures used in the persistence store.
Exactly. What's more, this pile of code takes months to write even for a few dozen object types; it doesn't understand the idea of dependencies between objects so you have to add a whole layer to make sure that objects get persisted in the right order; it's incredibly hard to change, so the system design can't iterate; and simple objects like collections proliferate tables to the point of significant performance losses. It's a terrible way to build a software system unless the user model just happens to be adequately modeled by a fill-in-the-blanks table.
This is why serious applications traditionally roll their own file formats. It's actually less work to manage most data models from scratch than it is to map them into the straitjacket of a relational database. Custom file formats serve in essence as hand-rolled object databases. Unfortunately, the rise of the three-tier client-server architecture has made the RDBMS layer an unquestioned assumption, with the result that modeling two dozen object types winds up generating over 50,000 lines of convoluted, slow and buggy source code. Modeling the same objects from scratch on a custom B-tree would take less than one fifth the code size. Doing it in a good ODBMS would be almost as trivial as specifying the data structures in XML.
On my latest project, we ran into a strange issue when specifying the user interface of a discussion system. The designers wanted to mark read and unread messages per user -- in other words, functionality critical to providing a friendly user experience, which rn had fifteen years ago. The engineers hit the roof and said it was impossible. It turned out the reason was that this is an intrinsically hard problem on an RDBMS, although it's a trivial problem to solve in a hand-rolled.newsrc text file. Over the course of the project we ran into tons of these issues, and the interface design took a severe beating because of compromises to the limitations of an RDBMS back-end.
I was surprised to see so many questions of the form "what's wrong with relational databases"? Relational databases have a well-known problem called "impedance mismatch" when mapping multi-linked object structures. Many links on the impedance mismatch issue can be found at this Google search.
Anyone who has tried to take a natural set of application-side objects and map them onto a relational database is already quite familiar with the problems created by the proliferation of tables needed to map simple application data structures, as well as the large amount of development effort needed to deal with simple relationships that would be trivial to specify in an object model such as Java's or XML's.
There is clearly a need to move on to object databases, but installed base and skill set inertia have blocked this transition, with the result that database-oriented applications have remained hamstrung in their friendliness and feature set.
The waste from a hydrogen fuel cell is water. There are certain problems disposing of the water in a way that will not make the surroundings wet, which is a particular problem for electronic circuits. Current hopes are that the water can be harmlessly evaporated, but at worst, you might need to empty the unit's water waste into a sink or toilet from time to time.
The graphic front end gives you NO indication as to what it's doing or how long it'll take (or how much it's done).
Gad. That's such an elementary design mistake. It's bad GUIs like this that convince people that GUIs suck. Most of the graphical software I see on free platforms seems to be written by people who hate graphical programs and want everyone else to hate them too.
I'm having a hard time reconciling the Yahoo page with the Annual Report from October 19. The Yahoo financials report a non-recurring charge of $230,092,000 exactly in each of the four quarters. I believe this is an error. The annual loss is only $525,268,000 on $134,890,000 in revenues, whereas a quarterly loss of the size given would make for almost double that loss.
It does not appear that VA has any reason to expect continuing non-recurring expenses in the quarter-billion range per quarter. It appears that they have already paid their non-recurring expenses for goodwill from unfortunate acquisitions and from reorganization.
What's happening to SourceForge is more interesting in how it bears on the overall health of the open source and free software movement. Rather than repeating myself, I'd like to refer to this post, which suggests that we may be looking at a world where free software is relatively crippled compared to proprietary versions of the same software.
the Open Source model has enough advantages that the community should be able to keep up and even surpass them.
I don't think there's any historical evidence for the popular idea that open source software improves faster than proprietary software. As this post from an IBM open source developer points out, there are serious management overheads and inefficiencies associated with the model.
One of the advantages of being closed is control. You get to choose exactly where each programmer works; you get to choose exactly which pieces of the system change, and which don't.
When you open it, suddenly, you lose control. You can't just make decisions anymore; you need to work with your contributor base, which is a much slower process than managerial decree. And you need to deal with the fact that people will be changing things all over the place, and be capable of integrating those changes into your own ongoing work. That costs time(possibly a lot of time), and time costs money.
If managing engineers under normal conditions is like herding cats, open source development is like harnessing a swarm of bees.
In a polarized situation of the kind you describe, where the review process is dysfunctional, then yes, written plans may become a hindrance. The fault there lies with the review process, though, not with the idea of written architecture.
For user experience, an interactive prototype can often speak louder than a written specification. Again, it's too bad the review process was so dysfunctional that you had to sneak the prototype in, but in a well-functioning organization, creating a prototype build and showing it around to the stakeholders would be a valuable part of the user interface specification process.
The release announcement by Covalent on top of this week's announcement of a proprietary version of SourceForge by VA [2001-11-06 20:04:54 VA Embraces Closed Source (articles,va) (rejected)] should have us all wondering where things are heading during this period of revision for open source business models. Are we headed for a world where ostensibly free programs are deliberately crippled relative to proprietary versions of the same code?
Covalent funds a great deal of Apache development directly, as well as contributing board members and other members to the Apache Software Foundation. It's clearly not doing this primarily to help the open source version of Apache along, but to advance its own proprietary version of Apache. Eventually Apache 2.0 may come out in an open source version, but it doesn't seem to be a priority of the main contributor to Apache to make that happen. A conspiracy-theory approach might even suggest that they are deliberately applying a flawed, destabilizing model to the open source tree (commit then review, no feature freeze) while presumably they use a tighter and more controlled process to get the proprietary version out.
People have suggested that the internal versions of GNAT distributed in a semi-proprietary way by ACT may be better than the open source versions, while ACT says the opposite -- that their private versions are less tested, require technical support, and would only hinder those who don't have support contracts. I don't know the truth of the matter there, and this is not meant to point the finger at ACT, but this phased-release strategy by Covalent raises some of the same questions.
VA's proprietary SourceForge conjures a similar spectre. There will still be a free SourceForge, but improvements are going primarily into the proprietary version. Perhaps outside engineers will start playing catch-up and adding clones of the proprietary features to an open source branch of SourceForge, but at best the open source version will still lag behind, and it may happen that it will always be so far behind as to be relatively crippled compared with the proprietary version.
Is open source heading toward a model where some of its dominant programs are available for free only in crippled versions lagging behind the proprietary releases? And if so, what does that say about unpaid volunteer contributions? Are they really for the public benefit, or for the benefit of a proprietary developer? If the latter, why volunteer?
Other problems with crippled free versions have been noted here before, such as having to pay for documentation on ostensibly free software, or needing a proprietary installer to effectively install a supposedly free system. This week's events involving VA and Covalent show that this may be becoming a trend with significant impact on the whole open source and free software movement.
I think most programmers are better advised to write clear code first and worry about the actual act of commenting second.
Clear coding is very important, but clear coding only happens in the context of a clearly defined and well thought out code architecture. Such an architecture ought to come before anyone codes a line of anything except prototypes for feasibility investigations. A clear architectural document is more important for new programmers on a project than any amount of comments or of well-chosen class and member names.
Isn't it ironic that these companies claim that open source software's disadvantage is that 'no one is held accountable' YET the first thing you do when you agree to a simple software license is agree that 'this company shall not be held responsible for any damages caused by this software, (etc)'?
You know, that's a really good point. I wasn't defending the liability argument so much as showing that it is of concern to many companies, including one that was strangely listed as an open source proponent in the paper. You have a good point to make about why it's a non-argument, but from a business scholarship perspective, the paper should at least have discussed this concern since many businesses share it, rightly or otherwise.
The piece is lucid and interesting. However, it is intended to advocate rather than to critically examine the principles of the open source/free software movement. It admits that this movement is a kind of "religion," and like a religious propagandist, the author shies away from asking hard questions about central points of doctrine.
E. Raymond describes this phenomenon in this way - "Given enough eyeballs, all bugs are shallow" - pointing out that security is an aspect of reliability. And such reliability can only be achieved through massive and parallel peer review.
A clear principle, to be sure, but is it a valid one? When bugs are tracked on major open source projects, such as Debian and Mozilla, the number of outstanding bugs only increases as a trend. When ESR turned up recently on the Linux kernel mailing list, he was jeered for the above maxim and told that it was demonstrably false. Robert Dewar of Ada Core Technologies -- a small business frequently cited as an open source success story -- has said that his organization is not particularly interested in outside bug fixes, since they are usually incorrect or incomplete. These anomalies and disagreements are not mentioned in the paper. A false picture of doctrinal consensus is painted instead.
Linux is synonymous to decentralisation since the project is developed by thousands of dispersed people who collaborate under no central planning.
Is it really true that Linux employs a decentralized network structure supported by volunteers? In fact it appears that hierarchical control is maintained, and maintained primarily by people who are paid to perform that job.
Nowadays, increasingly more 'big players' are joining the web: IBM, Dell, Oracle, Intel, HP, SAP and others have been tantalised by Linux and its Open Source development model, that have started investing heavily in the 'Linux platform'.
Tantalized? Oracle and SAP are proprietary par excellence. At a recent meeting with SAP in Frankfurt, I was told directly that the use of free software development tools would thwart SAP participation due to the lack of a liability structure. Dell offers Linux on its servers but that's the extent of its open source software development. This company list appears to be fabricated -- only IBM is clearly an open source backer, and even there, this year's open source campaign may have been a flash in the pan.
The management of this web depends heavily on the fact that every member of the web does not place any restrictions or rules on the other participants.
This is not at all true. In fact the large projects are tightly controlled by their inner circle, who place many restrictions on would-be volunteers. This is not news to the/. crowd.
Calling Emacs editor an editor is like calling the Earth a nice hunk of dirt. Emacs is an editor, a web browser, news reader, mail reader, personal information manager, typesetting program, programming editor, hex editor, word processor, and a number of video games. Many programmers use a kitchen sink as an icon for their copy of Emacs. There are many programmers who enter Emacs and don't leave to do anything else on the computer. Emacs, you'll find, isn't just a program, but a religion, and RMS is its saint.
This final passage is plainly ideological and even hero-worshipping. It is where the author drops all pretense at objectivity. In fact emacs is a design nightmare. It is wholly unsuitable for the use of non-engineers. If emacs is the free software ideal, that demonstrates why free software may never break out of its engineering niche. Strangely for a business-targeted paper, virtually nothing is said about customer satisfaction issues under the open source model. There are a few comments on the topic before the author gets to Linux, but once he's there, there's nothing from a process perspective on how open source development can enhance customer satisfaction. The reason may be that it can't. Programmers left to themselves create software for themselves, and programmers are strange people whose software requirements are very different from those of the public. Unless they are placed under hierarchical discipline by others more attuned to real-world requirements, they are incapable of producing software for end users. Unfortunately, there seems to be little place for that accountability to the customer in the open source development model.
transgenic animals (and chimeras) are a reality today.
There's a difference between transgenics and human-animal hybrids a la Cordwainer Smith. Not that I have anything against him as a writer, but that's not how transgenics work. You don't wind up with a talking humanoid beast of burden, and people would not accept them if you did.
How are you going to deal with the fact that partially assembled molecules are unstable and spontaneously collapse into different molecules from the ones you want?
Atoms are not Legos. They're very sticky and very volatile.
Robert Dewar, the CEO of Ada Core technology, happens to be a frequent contributor on comp.lang.ada, and he has explained the business model of ACT more than once over there.
Thank you for the reference. By looking on Google I found a 1997 thread entitled "Towards a free GNU Ada" that shows that quite a few people are not satisfied that the late-public-release strategy employed by ACT is providing them with free software of adequate quality, and who are not convinced by Dewar's explanations of the policy -- which are, in a nutshell, that they will release no wine before its time. If you don't pay for support (the story goes) a premature version would only hurt you, even if you think you want it. I'm not involved enough myself to have an opinion one way or the other, but it does appear there is a significant divergence in opinion on whether ACT's model is in line with the goals and principles of the free software movement.
One thing I did find interesting was Dewar's statement bearing on the "to many eyes all bugs are shallow" dictum:
Even for those who do know the technology well, formulating a correct
fix to a problem is not easy. We get a stream of suggested fixes from
people who know GNAT pretty well. In nearly every case, the person
has correctly identified a problem, but produced a fix that is either
incomplete or plain incorrect.
I've made a similar argument here myself a few times, with respect to the open source mythology of easy and valuable outside bug fixes. The startup time for any significant bug fix on a large project like GCC or Mozilla is itself quite large, and quick fixes in a complex system are likely to be the cure that is worse than the disease.
I also found this message which is instructive on ACT's history and size. It's still in the under-twenty-employees mom-n-pop category, or was in 1999.
I remember fifteen years ago when I first heard about nanotechnology from a Drexler acolyte. I was told that in five to twenty-five years, we would have assemblers capable of producing anything from a computer to a hot pizza instantly on demand. I read the book and saw only a slew of completely unsupported speculations about autonomous nanobots, general assemblers, and other apparently impossible things.
Now it's well more than half of my friend's worst-case estimate later. We have nothing approaching any of those things. What we have is exactly one thing, C 60, also called buckminsterfullerene. It's a very interesting thing, but it's a material, not a machine. Its co-inventor, Dr. Richard E. Smalley, explained in the Sept. 2001 Scientific American that the Drexler assembler is and always will be impossible, because molecules are not tinkertoys that you can put together an atom at a time.
In his 1999 Senate statement, Dr. Smalley said this about potential natural security ramifications of nanotechnology research:
National Security. The Department of Defense recognized the importance of nanostructures over a
decade ago and has played a significant role in nurturing the field. Critical defense applications
include: (a) Continued information dominance, identified as an important capability for the military,
will depend on U.S. nanotechnology. (b) Nanostructured electronics will provide more sophisticated
virtual reality systems that enable affordable, effective training. (c) Reduction in military manpower
must be compensated by the increased use of nanostructure-enhanced automation and robotics, both of
which will benefit from nanostructures. The use of uninhabited combat vehicles is desired, both to
reduce risk to human life as well as to improve vehicle performance. For example, several thousand
pounds could be stripped from a pilotless fighter aircraft, resulting in longer missions. In addition, the
fighter agility could be dramatically improved without the necessity to limit g-forces on the pilot,
increasing its combat effectiveness. (d) Nanostructured materials hold the promise for the high
performance (lighter, stronger) needed in military platforms while simultaneously providing
diminished failure rates and lower life-cycle costs. (e) Advances in medicine and health enabled by
nanoscience will provide badly needed chemical/biological/nuclear sensing, protection and
improvements in casualty care. (f) Changes are also possible in the design and weight reduction of
nuclear weapons and systems used in non-proliferation.
As you can see, it promises some incremental advances, but no basic revolutions -- certainly nothing on the level of the atomic bomb. Stronger armor, lighter planes, faster computers, smaller missiles, absolutely. But hordes of nanobattlebots? Get real.
The Drexler revolution has fallen flat on its face. We do not yet have even a semi-autonomous microbot, much less any kind of nanobot. Even at the microscale it turns out the laws of mechanics are too different from the mesoscale to allow for something as standard as a gear, and the nanoscale is much more different than that. We do not have anything vaguely resembling an assembler, and chemists say that the assembler will always be impossible.
Yet for some reason people are still concerned with these fantasies. It's just bad science fiction, like warp drives and human-animal hybrids. It's not important. We will have nanotechnology but it will be far more modest and less dangerous than the whacked-out speculations of fake futurists. Start dealing with the technology issues we really do face, like cloning, nuclear proliferation, and social monitoring. They're important. Drexler and his cult are not.
Remember, though, as stated in the article, much of sleepycat's position in their proprietary licensing market comes from their open-source software strategy.
Indeed. Open source as loss leader, with traditional licensing for revenue, may have possibilities. If so, this will require substantial changes to the open source/free software mythology, from a revolution model to a peaceful coexistence model. It's not compatible with the slogan that in the future, all software will be free.
It does look like dual-license strategies do significantly better than the "write free software and charge for services" model, doesn't it?
Yes, although in this case, not enough to get past the mom-n-pop level, at least not so far.
I wonder how well sleepycat does compared to other niche "embedded" database vendors like Polyhedra or Solid.
Hard to say. They're all privately held. The Polyhedra site doesn't say how big they are, though it offers a wide variety of product, service and support options. It shows no current job openings and does not have an "about the executives" page, which are not good signs. Oh wait, there's this inconspicuous note -- they were acquired in whole by Enea Data AB in March 2001 for their RTOS. Doesn't exactly sound like a high-ticket sale.
The Solidtech site says they closed a $50M venture capital round in 2000, which implies that they are probably not profitable but were seen as having the potential to become profitable. They have only one job listing at present, an account manager, which as bellwethers go is not a particularly good one.
There are other reasons why people do not give away their supported GNAT version.
What are those reasons?
You elided the above. Please answer the question. Thank you.
Do you really assume that the ACT business model is built around the fact their supported customers get access to new GNAT releases 15 month ahead of non-supported customers? This is completely off target.
Do you have some basis for that assertion? It seems to make commercial sense that they would be keeping the latest and greatest for paying customers. Fifteen months is a lot longer than it would take to put it into CVS for GCC, especially as an unstable build -- an accepted practice in the open source community.
In contrast, ACT is selling support for their GNAT technology. The exact version number of the product does not matter much if you can contact the vendor in case of a problem, and hours later it has been analyzed, and a solution is proposed.
Do you have some basis for that assertion? In Sleepycat's case, there is a three-to-one ratio in favor of licensing over support revenue. Do you have some verifiable reason to believe that ACT's revenue model is primarily based on support rather than on selling software?
I'd like to, but the ACT website is not very forthcoming on the open-source question. It left me with the impression that they'd rather you didn't know you could get GNAT for free.
There are other reasons why people do not give away their supported GNAT version.
What are those reasons? Don't disincentives to copy stand against the whole free software/open source philosophy?
Again, it seems that to make money on open source, you need to find a way to make it not really open source. We get back to the issue that the commercial value of something that can be freely copied is effectively nil.
If the day and age ever comes where most people are using Free Software then there will be a great deal more customers for Sleepycat's service and support contracts.
And that conclusion is derived from... what?
If Free Software were to become the de-facto standard, then they would certainly see more people interested in their software, many of whom would be willing to pay for their particular expertise.
Again, whatever chain of reasoning may underlie your conclusion is not apparent to me.
Free Software is going to be developed whether you like it or not. The smart thing to do is to make sure that some of it is yours.
Why? What benefits accrue to me by making sure that people are using software that I wrote, if they're not paying me for it? The wonderful satisfaction of a job well done? Great, but I got bills to pay.
So essentially, they are helping to support the Free Software revolution at the expense of those less enlightened.
I think you may hev missed the point. They're only able to make money developing free software because they sell it under non-free licensing arrangements. In the hypothetical post-proprietary world, they would not be able to continue improving the software because they would not be making any money.
Similarly, for ACT, the income stream seems to be based on a similar dual licensing agreement, with the latest and greatest only available under a proprietary license. If all software were free, they would not have sufficient revenue -- they only make money from their software by protecting it, not by giving it away.
It's very interesting that free software can be part of the business model of a successful business, even if only a small mom-n-pop operation. However, it also needs to be noted that neither of these business models is compatible with free software utopianism. The legend of the future will need to be revised if these companies are paradigmatic.
Slashdot Mirror
I never said they are making a profit ... Are they making money?
Um, er, what's the difference again? Making revenues is not particularly useful if they don't exceed your costs of doing business. There are definitely open source companies making revenues, but "making money" in its usual usage means that one is making more money than one is spending, and Red Hat is spending more than it is bringing in.
(Yeah, I know that's an oversimplification, but I don't feel like going into the whole issue of goodwill and intangible losses right now. Not all the money Red Hat is losing is money it is spending, technically speaking. But by GAAP it is losing money. This may change soon, or it may not.)
Tim
That's good. Like I said, you may have good prospects. I just think it's a little early in your corporate history for the company to start getting cited as a success story. Sustained profitability is the measure of business success, and you're not yet there. But I hope you do become a success story, and it sounds like you have a pretty good shot at it.
Tim
I work for MontaVista Software, an open source company. I'm not sure I'm free to discuss our financial situation, but suffice to say we're going through this "slump" just fine.
Really? It looks to me like your growth has stopped -- there's only one job opening for the whole company. Your end of 2000 announcement discussed ten-time revenue growth (from what? it's your first full year), and growth from twelve people to 160, but it was conspicuously quiet on the question of profit. Meanwhile, at that resource load, you're probably burning through the $30 million in investment fairly quickly, though by my back of the envelope it shouldn't be all gone yet.
Don't get me wrong -- you may have good prospects in the future, but it does not appear to me that you are now a profitable company, and the dearth of new job openings is a disturbing bellwether for future growth potential. If you're doing "fine" now, that may only mean that you haven't yet spent all your investor capital.
Tim
I am very happy these people are making money off of Linux.
/. about particular open source companies being profitable almost never seem to get corrected, even when many of the readers know better? Is the profitability falsehood one that has been designated as socially acceptable?
They're not. Red Hat is losing money on Linux, and has been for years. Check out their profile: "For the six months ended 8/31/01, revenues fell 1% to $46.7 million. Net loss totaled $82.9 million, up from $37.4 million." Their loss more than doubled from the previous six months, and their loss was 177% of their revenues. Revenues are declining, though only slightly. Funny way to make money if you ask me.
Why is it that statements on
Tim
Michael Tiemann: Well, as a matter of fact, we were profitable, increasingly profitable, every single year until we attracted so much attention that people wanted to invest money in Cygnus. That happened in 1997.
Red Hat S-1A Filing, January 28, 2000 (search under "3. BUSINESS COMBINATION (CONTINUED)") says that Red Hat lost $1.5M in fiscal 1996, $2.9M in fiscal 1997, $5.7M in fiscal 1998, and $6.4M in the nine months before it was acquired.
Sleepycat employs under twenty people, as does ACT. Peter Deutsch is one person, and may well be discussing a modest retirement in Wisconsin, which is dirt cheap.
So that's less than forty people, none of whom have had the payoff of a second-tier engineer in a moderately successful IPO.
Tim
So you get this impedance mismatch and a pile of code whose sole purpose is to rewrite the data structures used in the program so that they match the data structures used in the persistence store.
.newsrc text file. Over the course of the project we ran into tons of these issues, and the interface design took a severe beating because of compromises to the limitations of an RDBMS back-end.
Exactly. What's more, this pile of code takes months to write even for a few dozen object types; it doesn't understand the idea of dependencies between objects so you have to add a whole layer to make sure that objects get persisted in the right order; it's incredibly hard to change, so the system design can't iterate; and simple objects like collections proliferate tables to the point of significant performance losses. It's a terrible way to build a software system unless the user model just happens to be adequately modeled by a fill-in-the-blanks table.
This is why serious applications traditionally roll their own file formats. It's actually less work to manage most data models from scratch than it is to map them into the straitjacket of a relational database. Custom file formats serve in essence as hand-rolled object databases. Unfortunately, the rise of the three-tier client-server architecture has made the RDBMS layer an unquestioned assumption, with the result that modeling two dozen object types winds up generating over 50,000 lines of convoluted, slow and buggy source code. Modeling the same objects from scratch on a custom B-tree would take less than one fifth the code size. Doing it in a good ODBMS would be almost as trivial as specifying the data structures in XML.
On my latest project, we ran into a strange issue when specifying the user interface of a discussion system. The designers wanted to mark read and unread messages per user -- in other words, functionality critical to providing a friendly user experience, which rn had fifteen years ago. The engineers hit the roof and said it was impossible. It turned out the reason was that this is an intrinsically hard problem on an RDBMS, although it's a trivial problem to solve in a hand-rolled
Tim
I was surprised to see so many questions of the form "what's wrong with relational databases"? Relational databases have a well-known problem called "impedance mismatch" when mapping multi-linked object structures. Many links on the impedance mismatch issue can be found at this Google search.
Anyone who has tried to take a natural set of application-side objects and map them onto a relational database is already quite familiar with the problems created by the proliferation of tables needed to map simple application data structures, as well as the large amount of development effort needed to deal with simple relationships that would be trivial to specify in an object model such as Java's or XML's.
There is clearly a need to move on to object databases, but installed base and skill set inertia have blocked this transition, with the result that database-oriented applications have remained hamstrung in their friendliness and feature set.
Tim
The waste from a hydrogen fuel cell is water. There are certain problems disposing of the water in a way that will not make the surroundings wet, which is a particular problem for electronic circuits. Current hopes are that the water can be harmlessly evaporated, but at worst, you might need to empty the unit's water waste into a sink or toilet from time to time.
Tim
The graphic front end gives you NO indication as to what it's doing or how long it'll take (or how much it's done).
Gad. That's such an elementary design mistake. It's bad GUIs like this that convince people that GUIs suck. Most of the graphical software I see on free platforms seems to be written by people who hate graphical programs and want everyone else to hate them too.
Tim
I'm having a hard time reconciling the Yahoo page with the Annual Report from October 19. The Yahoo financials report a non-recurring charge of $230,092,000 exactly in each of the four quarters. I believe this is an error. The annual loss is only $525,268,000 on $134,890,000 in revenues, whereas a quarterly loss of the size given would make for almost double that loss.
It does not appear that VA has any reason to expect continuing non-recurring expenses in the quarter-billion range per quarter. It appears that they have already paid their non-recurring expenses for goodwill from unfortunate acquisitions and from reorganization.
What's happening to SourceForge is more interesting in how it bears on the overall health of the open source and free software movement. Rather than repeating myself, I'd like to refer to this post, which suggests that we may be looking at a world where free software is relatively crippled compared to proprietary versions of the same software.
Tim
I don't think there's any historical evidence for the popular idea that open source software improves faster than proprietary software. As this post from an IBM open source developer points out, there are serious management overheads and inefficiencies associated with the model.
If managing engineers under normal conditions is like herding cats, open source development is like harnessing a swarm of bees.
Tim
In a polarized situation of the kind you describe, where the review process is dysfunctional, then yes, written plans may become a hindrance. The fault there lies with the review process, though, not with the idea of written architecture.
For user experience, an interactive prototype can often speak louder than a written specification. Again, it's too bad the review process was so dysfunctional that you had to sneak the prototype in, but in a well-functioning organization, creating a prototype build and showing it around to the stakeholders would be a valuable part of the user interface specification process.
Tim
The release announcement by Covalent on top of this week's announcement of a proprietary version of SourceForge by VA [2001-11-06 20:04:54 VA Embraces Closed Source (articles,va) (rejected)] should have us all wondering where things are heading during this period of revision for open source business models. Are we headed for a world where ostensibly free programs are deliberately crippled relative to proprietary versions of the same code?
Covalent funds a great deal of Apache development directly, as well as contributing board members and other members to the Apache Software Foundation. It's clearly not doing this primarily to help the open source version of Apache along, but to advance its own proprietary version of Apache. Eventually Apache 2.0 may come out in an open source version, but it doesn't seem to be a priority of the main contributor to Apache to make that happen. A conspiracy-theory approach might even suggest that they are deliberately applying a flawed, destabilizing model to the open source tree (commit then review, no feature freeze) while presumably they use a tighter and more controlled process to get the proprietary version out.
People have suggested that the internal versions of GNAT distributed in a semi-proprietary way by ACT may be better than the open source versions, while ACT says the opposite -- that their private versions are less tested, require technical support, and would only hinder those who don't have support contracts. I don't know the truth of the matter there, and this is not meant to point the finger at ACT, but this phased-release strategy by Covalent raises some of the same questions.
VA's proprietary SourceForge conjures a similar spectre. There will still be a free SourceForge, but improvements are going primarily into the proprietary version. Perhaps outside engineers will start playing catch-up and adding clones of the proprietary features to an open source branch of SourceForge, but at best the open source version will still lag behind, and it may happen that it will always be so far behind as to be relatively crippled compared with the proprietary version.
Is open source heading toward a model where some of its dominant programs are available for free only in crippled versions lagging behind the proprietary releases? And if so, what does that say about unpaid volunteer contributions? Are they really for the public benefit, or for the benefit of a proprietary developer? If the latter, why volunteer?
Other problems with crippled free versions have been noted here before, such as having to pay for documentation on ostensibly free software, or needing a proprietary installer to effectively install a supposedly free system. This week's events involving VA and Covalent show that this may be becoming a trend with significant impact on the whole open source and free software movement.
Tim
I think most programmers are better advised to write clear code first and worry about the actual act of commenting second.
Clear coding is very important, but clear coding only happens in the context of a clearly defined and well thought out code architecture. Such an architecture ought to come before anyone codes a line of anything except prototypes for feasibility investigations. A clear architectural document is more important for new programmers on a project than any amount of comments or of well-chosen class and member names.
Tim
Isn't it ironic that these companies claim that open source software's disadvantage is that 'no one is held accountable' YET the first thing you do when you agree to a simple software license is agree that 'this company shall not be held responsible for any damages caused by this software, (etc)'?
You know, that's a really good point. I wasn't defending the liability argument so much as showing that it is of concern to many companies, including one that was strangely listed as an open source proponent in the paper. You have a good point to make about why it's a non-argument, but from a business scholarship perspective, the paper should at least have discussed this concern since many businesses share it, rightly or otherwise.
Tim
The piece is lucid and interesting. However, it is intended to advocate rather than to critically examine the principles of the open source/free software movement. It admits that this movement is a kind of "religion," and like a religious propagandist, the author shies away from asking hard questions about central points of doctrine.
/. crowd.
E. Raymond describes this phenomenon in this way - "Given enough eyeballs, all bugs are shallow" - pointing out that security is an aspect of reliability. And such reliability can only be achieved through massive and parallel peer review.
A clear principle, to be sure, but is it a valid one? When bugs are tracked on major open source projects, such as Debian and Mozilla, the number of outstanding bugs only increases as a trend. When ESR turned up recently on the Linux kernel mailing list, he was jeered for the above maxim and told that it was demonstrably false. Robert Dewar of Ada Core Technologies -- a small business frequently cited as an open source success story -- has said that his organization is not particularly interested in outside bug fixes, since they are usually incorrect or incomplete. These anomalies and disagreements are not mentioned in the paper. A false picture of doctrinal consensus is painted instead.
Linux is synonymous to decentralisation since the project is developed by thousands of dispersed people who collaborate under no central planning.
Is it really true that Linux employs a decentralized network structure supported by volunteers? In fact it appears that hierarchical control is maintained, and maintained primarily by people who are paid to perform that job.
Nowadays, increasingly more 'big players' are joining the web: IBM, Dell, Oracle, Intel, HP, SAP and others have been tantalised by Linux and its Open Source development model, that have started investing heavily in the 'Linux platform'.
Tantalized? Oracle and SAP are proprietary par excellence. At a recent meeting with SAP in Frankfurt, I was told directly that the use of free software development tools would thwart SAP participation due to the lack of a liability structure. Dell offers Linux on its servers but that's the extent of its open source software development. This company list appears to be fabricated -- only IBM is clearly an open source backer, and even there, this year's open source campaign may have been a flash in the pan.
The management of this web depends heavily on the fact that every member of the web does not place any restrictions or rules on the other participants.
This is not at all true. In fact the large projects are tightly controlled by their inner circle, who place many restrictions on would-be volunteers. This is not news to the
Calling Emacs editor an editor is like calling the Earth a nice hunk of dirt. Emacs is an editor, a web browser, news reader, mail reader, personal information manager, typesetting program, programming editor, hex editor, word processor, and a number of video games. Many programmers use a kitchen sink as an icon for their copy of Emacs. There are many programmers who enter Emacs and don't leave to do anything else on the computer. Emacs, you'll find, isn't just a program, but a religion, and RMS is its saint.
This final passage is plainly ideological and even hero-worshipping. It is where the author drops all pretense at objectivity. In fact emacs is a design nightmare. It is wholly unsuitable for the use of non-engineers. If emacs is the free software ideal, that demonstrates why free software may never break out of its engineering niche. Strangely for a business-targeted paper, virtually nothing is said about customer satisfaction issues under the open source model. There are a few comments on the topic before the author gets to Linux, but once he's there, there's nothing from a process perspective on how open source development can enhance customer satisfaction. The reason may be that it can't. Programmers left to themselves create software for themselves, and programmers are strange people whose software requirements are very different from those of the public. Unless they are placed under hierarchical discipline by others more attuned to real-world requirements, they are incapable of producing software for end users. Unfortunately, there seems to be little place for that accountability to the customer in the open source development model.
Tim
transgenic animals (and chimeras) are a reality today.
There's a difference between transgenics and human-animal hybrids a la Cordwainer Smith. Not that I have anything against him as a writer, but that's not how transgenics work. You don't wind up with a talking humanoid beast of burden, and people would not accept them if you did.
Tim
How are you going to deal with the fact that partially assembled molecules are unstable and spontaneously collapse into different molecules from the ones you want?
Atoms are not Legos. They're very sticky and very volatile.
Tim
Thank you for the reference. By looking on Google I found a 1997 thread entitled "Towards a free GNU Ada" that shows that quite a few people are not satisfied that the late-public-release strategy employed by ACT is providing them with free software of adequate quality, and who are not convinced by Dewar's explanations of the policy -- which are, in a nutshell, that they will release no wine before its time. If you don't pay for support (the story goes) a premature version would only hurt you, even if you think you want it. I'm not involved enough myself to have an opinion one way or the other, but it does appear there is a significant divergence in opinion on whether ACT's model is in line with the goals and principles of the free software movement.
One thing I did find interesting was Dewar's statement bearing on the "to many eyes all bugs are shallow" dictum:
I've made a similar argument here myself a few times, with respect to the open source mythology of easy and valuable outside bug fixes. The startup time for any significant bug fix on a large project like GCC or Mozilla is itself quite large, and quick fixes in a complex system are likely to be the cure that is worse than the disease.
I also found this message which is instructive on ACT's history and size. It's still in the under-twenty-employees mom-n-pop category, or was in 1999.
Tim
Now it's well more than half of my friend's worst-case estimate later. We have nothing approaching any of those things. What we have is exactly one thing, C 60, also called buckminsterfullerene. It's a very interesting thing, but it's a material, not a machine. Its co-inventor, Dr. Richard E. Smalley, explained in the Sept. 2001 Scientific American that the Drexler assembler is and always will be impossible, because molecules are not tinkertoys that you can put together an atom at a time.
In his 1999 Senate statement, Dr. Smalley said this about potential natural security ramifications of nanotechnology research:
As you can see, it promises some incremental advances, but no basic revolutions -- certainly nothing on the level of the atomic bomb. Stronger armor, lighter planes, faster computers, smaller missiles, absolutely. But hordes of nanobattlebots? Get real.
The Drexler revolution has fallen flat on its face. We do not yet have even a semi-autonomous microbot, much less any kind of nanobot. Even at the microscale it turns out the laws of mechanics are too different from the mesoscale to allow for something as standard as a gear, and the nanoscale is much more different than that. We do not have anything vaguely resembling an assembler, and chemists say that the assembler will always be impossible.
Yet for some reason people are still concerned with these fantasies. It's just bad science fiction, like warp drives and human-animal hybrids. It's not important. We will have nanotechnology but it will be far more modest and less dangerous than the whacked-out speculations of fake futurists. Start dealing with the technology issues we really do face, like cloning, nuclear proliferation, and social monitoring. They're important. Drexler and his cult are not.
Tim
Hello foog,
Remember, though, as stated in the article, much of sleepycat's position in their proprietary licensing market comes from their open-source software strategy.
Indeed. Open source as loss leader, with traditional licensing for revenue, may have possibilities. If so, this will require substantial changes to the open source/free software mythology, from a revolution model to a peaceful coexistence model. It's not compatible with the slogan that in the future, all software will be free.
It does look like dual-license strategies do significantly better than the "write free software and charge for services" model, doesn't it?
Yes, although in this case, not enough to get past the mom-n-pop level, at least not so far.
I wonder how well sleepycat does compared to other niche "embedded" database vendors like Polyhedra or Solid.
Hard to say. They're all privately held. The Polyhedra site doesn't say how big they are, though it offers a wide variety of product, service and support options. It shows no current job openings and does not have an "about the executives" page, which are not good signs. Oh wait, there's this inconspicuous note -- they were acquired in whole by Enea Data AB in March 2001 for their RTOS. Doesn't exactly sound like a high-ticket sale.
The Solidtech site says they closed a $50M venture capital round in 2000, which implies that they are probably not profitable but were seen as having the potential to become profitable. They have only one job listing at present, an account manager, which as bellwethers go is not a particularly good one.
Tim
You elided the above. Please answer the question. Thank you.
Do you really assume that the ACT business model is built around the fact their supported customers get access to new GNAT releases 15 month ahead of non-supported customers? This is completely off target.
Do you have some basis for that assertion? It seems to make commercial sense that they would be keeping the latest and greatest for paying customers. Fifteen months is a lot longer than it would take to put it into CVS for GCC, especially as an unstable build -- an accepted practice in the open source community.
In contrast, ACT is selling support for their GNAT technology. The exact version number of the product does not matter much if you can contact the vendor in case of a problem, and hours later it has been analyzed, and a solution is proposed.
Do you have some basis for that assertion? In Sleepycat's case, there is a three-to-one ratio in favor of licensing over support revenue. Do you have some verifiable reason to believe that ACT's revenue model is primarily based on support rather than on selling software?
Tim
No, check your facts...
I'd like to, but the ACT website is not very forthcoming on the open-source question. It left me with the impression that they'd rather you didn't know you could get GNAT for free.
There are other reasons why people do not give away their supported GNAT version.
What are those reasons? Don't disincentives to copy stand against the whole free software/open source philosophy?
Again, it seems that to make money on open source, you need to find a way to make it not really open source. We get back to the issue that the commercial value of something that can be freely copied is effectively nil.
Tim
If the day and age ever comes where most people are using Free Software then there will be a great deal more customers for Sleepycat's service and support contracts.
And that conclusion is derived from... what?
If Free Software were to become the de-facto standard, then they would certainly see more people interested in their software, many of whom would be willing to pay for their particular expertise.
Again, whatever chain of reasoning may underlie your conclusion is not apparent to me.
Free Software is going to be developed whether you like it or not. The smart thing to do is to make sure that some of it is yours.
Why? What benefits accrue to me by making sure that people are using software that I wrote, if they're not paying me for it? The wonderful satisfaction of a job well done? Great, but I got bills to pay.
Tim
So essentially, they are helping to support the Free Software revolution at the expense of those less enlightened.
I think you may hev missed the point. They're only able to make money developing free software because they sell it under non-free licensing arrangements. In the hypothetical post-proprietary world, they would not be able to continue improving the software because they would not be making any money.
Similarly, for ACT, the income stream seems to be based on a similar dual licensing agreement, with the latest and greatest only available under a proprietary license. If all software were free, they would not have sufficient revenue -- they only make money from their software by protecting it, not by giving it away.
It's very interesting that free software can be part of the business model of a successful business, even if only a small mom-n-pop operation. However, it also needs to be noted that neither of these business models is compatible with free software utopianism. The legend of the future will need to be revised if these companies are paradigmatic.
Tim