Ok, so let's see, that's 99,999,999 licenses then...
You could add up all the Ubuntu-wielding moms in the world, along with all the Ubuntu-wielding offspring, and it won't move that needle in the slightest.
I use Mac, Ubuntu, and ChromeOS, so no love for Microsoft here, but this belief that somehow Linux marks any kind of threat to MS on the desktop or laptop is silly. Most of the world runs Windows on those machines, and always will.
The thing that will shift that is not your mom, or even your mom times 1 million. The thing that will shift that is the move away from those devices, to Android. But Microsoft will still see incredible income from Windows during that shift.
It's worth noting that there's not a psychologist in the world that would agree with this assessment. People aren't 'good' or 'bad' like there some global variable that's been set. Behavior varies by circumstance; many of those girls who were 'good' in circumstances where they were being observed were doubtless 'bad' when they were alone, or only with peers.
It only takes one "Two Girls One Cup" to upset someone, especially a child, and the blithe assumption that 'Good kids will know to do the right thing, and all our girls are good' sounds like a flavor of the No true Scotsman... fallacy, and one that allows her to equate "No one has come to me" with "There is no problem here."
But this assumes that the natural lifespan of a company is infinite. What I think Geoffrey is saying is that when Kodak went out of business, the answer to "what exactly went wrong?" is that nothing went wrong.
Here's an analogy: Imagine I offered you one of two things: 200 millions tons of granite rubble, or a cathedral. Which would you pick?
The cathedral is the obvious choice -- the stone in its raw state is fairly dull, while a cathedral is a spectacular work of architecture, the fruit of countless hours of skilled human effort. The cathedral has value right now, while the rubble isn't good for much without an enormous amount of additional labor.
What if labor was part of the equation, though? What if I gave you a choice between the beautiful cathedral and the chaotic rubble, with the stipulation that, after you chose, it was your job to build a bridge.
Now you want the rubble. Though the cathedral and the rubble are made up of about the same amount of stone, building the bridge out of the rubble will consume all the energy required to build a bridge, but building the bridge out of the cathedral will require all the energy needed to build a bridge plus all the energy required to dismantle the cathedral. For some tasks, it's simpler to start with raw material than with a beautiful structure that has to be dramatically altered to serve your purpose.
Now imagine I offered you one of two things: You have to build a digital photography business, and you can start with Sony, or Kodak. Which would you choose?
The problem Kodak faced wasn't that they couldn't have become a digital photography business. The problem Kodak faced was that the digital business was so different from what they are good at that the restructuring costs were crippling, *precisely because they were perfectly adapted to the previous era.*
> The whole point of using many smaller rockets is some little thing known as the economy of scale.
Economies of scale were supposed to drive the shuttle too, only they didn't, because the original assumptions about the cost of re-use were too low, *even before* any LOC/LOV failures.
So be careful yourself about assuming small multiples assures low cost. If launching and securing *any* vehicle creates a high minimum cost, the remaining cost savings from any economies of scale could be inadequate to lowering the cost of the whole enterprise.
There are two problems with this analysis. The first is that you (as many coders do) assume that tools that require intelligence on the part of the coder is an unalloyed good. Businesses, however, don't see it that way, especially large ones with many coders.
As Dave Clark once said in a different context, and architecture is partly there to tell you what you *can't* do. Programming languages are like that as well. Java is very good at encouraging certain idioms and discouraging others. Perl is not so good at either thing. Organizations that want structure will also want languages that support structure.
The answer "But its their fault for hiring dumb coders!" won't wash, because when you are the gas company working on maintaining a legacy billing system, you have to hire coders of average quality, and a language that allows coders of average quality to do stupid things is inferior to a language that shapes their work, *even if it slows them down*.
The second problem with this argument is fetishization of the individual coder, when most large codebases, esp in businesses, are social affairs. Even stipulating the impossibility that every business should hire only coders of above-average intelligence, different coders are intelligent in different ways. When 'Code as thou wilt' is the whole of the law, confusion abounds.
Did you ever see Rael Dornfest's bloxom blog project? Elegant, tight perl that did stuff like string replace on slashes in a fiel path to get an array of dir names, the file name itself, *and* kept the number of substitutions as a variable for traversal depth, in a single line. It was smart, but it also took other coders a long time to understand the JAPHishness of that single line of code, because it was doing three things at once.
Interestingly, he re-wrote it in Python, and its better, mainly because you can't do stuff like use the Boolean return of an assignment as a side-effect for an if test, and there's no concept of $_. Perl doesn't require JAPHishness and Python doesn't completely banish it, but other things being equal, Python produces more sociable code.
Once you start seeing the business imperative as enabling a group of acceptably competent programmers to work together, rather than being a platform for individual brilliance, the original article starts to look a lot more sensible.
Many people have done this before -- the technique, dated from the earliest example I know (Barbelith) is at least a decade old.
It's just that the social aspects of social software are passed around as lore, not documentation, so they take longer to spread than engineering insights.
That kind of rapid growth is meaningless on such a small base. Barely nudging 2% doesn't say much about the obstacles Linux on the desktop faces in penetrating a workplace dominated by MSFT apps. I run Ubuntu on my desktop, and I'm pretty impressed with its ability to handle MS-format files, but I also recognize that a) my user pattern is nothing like most office workers and b) I don't need to run any obscure Win-only apps.
Linden does not have 2.4 million users, and it does not regularly report how many users it does have. It reports "Residents", a figure that includes people who have signed up for Second Life but never logged in. It also double-counts people who have more than one avatar.
The only person to whom Linden has reported a count of active users is David Kirkpatrick of Fortune, and as of last week, only 252K people had logged into Second Life twice or more in two month -- the rest were bailouts. This 252K figure, which is a much more accurate reflection of Second Life's popularity, is an order of magnitude lower than most of the press is reporting.
This battle has been fought and lost. The term 'cracker' was a belated attempt to create a good witch/bad witch distinction after the press took a dim view of hacking, but it is totally artificial. To take but one example, Ken Thompson's seminal Reflections on Trusting Trust, spends some time moralizing (his word) about the 414 and Dalton gangs, saying "The acts performed by these kids are vandalism at best and probably trespass and theft at worst. It is only the inadequacy of the criminal code that saves the hackers from very serious prosecution." This is from the mid-80s, when breaking and entering was clearly described as hacking by one of the giants of the field. Hacking historically covered all forms of unapproved exploration of computer systems; in a more halcyon time, the gray area was wide, and the black area was not too black. Times have changed, but the fact that some hacking is now explicitly criminal, as Thompson predicted, does not make it not hacking.
You are correct -- people who don't want to hear the truth won't hear it, no matter how clearly presented. You seem, however, to be drawing a false conclusion from that, which is that the truth doesn't matter. In working social systems, accurate criticism creates effective responses, no matter what the disbelievers do. If the study had been well done and well presented, instead of badly done and badly presented, people who do care about the truth could have set about fixing or imporving any bottlenecks in the OS stack. Considered in that light, the study, as presented, simply punts the question of truth, because it is not described clearly enough either to replicate or react to.
Take a look at Physical Computing. It's sub-titled "Sensing and Controlling the Physical World with Computers" and features instructions and projects for basic work wiht sensors and simple chips like the PIC and BX-24. (Full disclosure: The authors are colleagues of mine at the Interactive Telecommunications Program at NYU.)
Cory Doctorow has a fantastic commentary on how wrong this article is, concentrating especially on the authors credulous assertion that DRM is an absolute requirement for the ebooks market. Says Cory: "But the author goes further and asserts that without DRM, there will be no market for entertainment product ever again ("If publishers stop wanting DRM, it's the end of popular creative arts. Not as we know them, but period.") despite the fact that the software industry got bigger when it abandoned DRM, and despite the fact that no new medium has ever succeeded by appealing to the virtues of the medium before it [...]" Well worth a read.
Nope. Flat rate is a different _kind_ of pricing than metered, and consumers strongly prefer flat rate, a pattern in telecommunications pricing that has been true for 150 years, as shown by the economist Andrew Odlyzko in his survey of telecom economics, Internet pricing and the history of communications (PDF). Companies offer flat-rate pricing have an advantage over companies offering metered service, no matter how cheap the metering is. (This, of course, is also why micropayments never catch on among consumers.)
Re:From the viewpoint of meme theory...
on
Saving Digital History
·
· Score: 3, Insightful
"The important information will save itself without outside help."
That's whistling past a pretty big graveyard.
The problem is that time changes the definition of interesting. Would you be interested in the ads from a copy of the NYTimes.com from 1998? Probably not, unless you wanted to chuckle at the 667Mhz Pentia selling for $2500.
Would you be interested in the ads from a copy of the New York Times in _1898?_ Those ads are a view into a world you never inhabited, and expose the preoccupations of the era in a way that the articles don't.
We can look at the 1898 ads, not because the important information saved itself, but because archivists did. Someday the ads from 1998 will have the same interests for historians and anthropologists. Who will do the archiving there?
If we leave it to the present to sort the good from the bad, the future will never know what we considered unimportant. If you'd asked anybody in 1960 what that era's biggest technological revolutions of the time were, they'd have all said atomic energy and space travel. The real answers turned out to be the transistor and the birth control pill.
We are just about the worst possible people to ask what's important now, because we're too close, and it would be hubris to pretend otherwise.
An indefinite storage period is only part of the problem. Even if you keep the 1s and 0s by copying them every five years, file formats go out of scope, and even if you keep the software the file was saved in, the OS that ran it may well be dead (most are, after all) and even if you save a copy of the data _and_ the application that can read it _and_ the OS, what hardware are you going to run it on?
So its a nested set of problems, with no one solution -- copying, conversion and emulation will all be required.
There are two major advantages of analog over digital: the first is that inaction over a period of years does not destroy analog material. If you put a stack of paper in a box in the early 90s, it's probably fine. That degree of inaction, however, can be the death knell for digital material. If you put a stack of CD-ROMs or disks away in the early 90s, chances are at least some of that material is gone.
The second is that while analog degrades slowly, bit-sensitive digital data (encrypted, compressed or executable files) degrades extremely quickly. If you make a mistake handling a book, say, you may end up with one torn page, but if you lose even a small piece of a bit-sensitive file, the entire thing vanishes forever.
You don't need a static IP if you have a static phone number. Once Vonage gives you a phone number, it keeps that at the permanent entry in its db, matching your phone's dynamic IP to that phone number on the fly.
This is the ICQ model, where the IP address is treated as the temporary half of a permanent->temporary lookup table. This is one of the big wins for this version of VoIP.
You're comapring apples and oranges. Don't think that today's Type 3 plain-paper "just plug it in and it works" fax was like the fax machines of 1984. Those fax machines costs thousands of dollars, had poor quality, were difficult to set up, and required lots of maintenance for their toner replacements and special fax-only paper.
The reason we have easy to use cheap fax machines today is that there was a market for difficult expensive ones 15 years ago. The same thing happened with radios, calculators, and, of course, computers.
Today's VoIP and WiFi installations are cheaper and easier than they used to be, and will be both cheaper and easier again by the end of this year. Comparing a mature technology with one still in early adoption phase, and concluding that the latter has no chance, is to mistake the acorn for the oak.
I didn't want to make the article too much of a trip down memory lane about ZapMail, but in fact FedEx _did_ own the underlying technology. They built a proprietary data network to support the service. It was the owners of fax machines who didn't own the underlying technology.
And the bundling of DSL and phone doesn't keep you from keeping the phone for POTS/911 service and moving everything else to VoIP. Unless you have the bare minimum phone service and no LD charges, this may well be a cost-saving option.
First, the "big boys" you name are not the incumbent local exchanges, or ILECs, like SBC, BellSouth and Verizon. The article, written for the general reader, glosses over the difference between local and long-distance service, but its the ILECs who have the most to lose from Vonage et al, because the ILECs are the ones who make their money locking out competition and locking in service fees for things like Call Waiting that VoIP can do for free.
Second, the move from Column A (per-minute fees on a voice-optimized network) to Column B (voice as just another flat-rate app on an IP-based data network) is more than just bookkeeping, because you get to charge a lot less for apps in Column B. If all of ATTs LD revenues were to switch to VoIP style pricing tomorrow, they'd be out of business by the weekend.
(Sounds like a diagnosis of venereal disease, huh?)
The reward of scratching your *own* itch is obvious. The reward of scratching other peoples' itches, especially when they are not likely to even send you a "thank you", are more dubious.
This true, and I address it in the article. LazyWeb, at least as its worked in the past, addresses this in a fashion. Rather than recap, I'll post an excerpt here:
"The canonical motivation for open source developers is that they want to "scratch an itch." In this view, most open source software is written with the developer as the primary user, with any additional use seen as a valuable but secondary side-effect.
Sometimes, though, the itch a developer has is social: they want to write software other people will adopt. In this case, the advantage of the LazyWeb is not just that a new application or feature is described clearly, but that it is guaranteed to have at least one grateful user. Furthermore, LazyWeb etiquette involves publicizing any solution that does arise, meaning that the developer gets free public attention, even if only to a select group. If writing software that gets used in the wild is a motivation, acting on a LazyWeb description is in many ways a karmically optimal move."
To set the record straight, during 2000 and 2001, I worked at an incubator called The Accelerator Group, where my job was to assess new businesses' technologies. I certainly wan't the one writing the checks, and I certainly do think Python (and perl and Ruby) are innovative.
As for successes, and failures, I detect another pattern in your list. Open Source does better the deeper in the stack it is. Deep in the stack == programmers as users. Tools high in the stack, on the other hand, have a strong split between the people writing the software and the average user. I am wondering if LazyWeb can bring about useful communication across that gap, at least among users capable of describing what they want clearly and developers looking for outside inspiration.
Slashdot Mirror
Ok, so let's see, that's 99,999,999 licenses then...
You could add up all the Ubuntu-wielding moms in the world, along with all the Ubuntu-wielding offspring, and it won't move that needle in the slightest.
I use Mac, Ubuntu, and ChromeOS, so no love for Microsoft here, but this belief that somehow Linux marks any kind of threat to MS on the desktop or laptop is silly. Most of the world runs Windows on those machines, and always will.
The thing that will shift that is not your mom, or even your mom times 1 million. The thing that will shift that is the move away from those devices, to Android. But Microsoft will still see incredible income from Windows during that shift.
It's worth noting that there's not a psychologist in the world that would agree with this assessment. People aren't 'good' or 'bad' like there some global variable that's been set. Behavior varies by circumstance; many of those girls who were 'good' in circumstances where they were being observed were doubtless 'bad' when they were alone, or only with peers.
It only takes one "Two Girls One Cup" to upset someone, especially a child, and the blithe assumption that 'Good kids will know to do the right thing, and all our girls are good' sounds like a flavor of the No true Scotsman... fallacy, and one that allows her to equate "No one has come to me" with "There is no problem here."
But this assumes that the natural lifespan of a company is infinite. What I think Geoffrey is saying is that when Kodak went out of business, the answer to "what exactly went wrong?" is that nothing went wrong.
Here's an analogy: Imagine I offered you one of two things: 200 millions tons of granite rubble, or a cathedral. Which would you pick?
The cathedral is the obvious choice -- the stone in its raw state is fairly dull, while a cathedral is a spectacular work of architecture, the fruit of countless hours of skilled human effort. The cathedral has value right now, while the rubble isn't good for much without an enormous amount of additional labor.
What if labor was part of the equation, though? What if I gave you a choice between the beautiful cathedral and the chaotic rubble, with the stipulation that, after you chose, it was your job to build a bridge.
Now you want the rubble. Though the cathedral and the rubble are made up of about the same amount of stone, building the bridge out of the rubble will consume all the energy required to build a bridge, but building the bridge out of the cathedral will require all the energy needed to build a bridge plus all the energy required to dismantle the cathedral. For some tasks, it's simpler to start with raw material than with a beautiful structure that has to be dramatically altered to serve your purpose.
Now imagine I offered you one of two things: You have to build a digital photography business, and you can start with Sony, or Kodak. Which would you choose?
The problem Kodak faced wasn't that they couldn't have become a digital photography business. The problem Kodak faced was that the digital business was so different from what they are good at that the restructuring costs were crippling, *precisely because they were perfectly adapted to the previous era.*
Cached copy here: http://74.125.113.132/search?q=cache:y8CuWLUgkMkJ:beginningruby.org/what-ive-earned-and-learned/+http://beginningruby.org/what-ive-earned-and-learned/
http://beginningruby.org/what-ive-earned-and-learned/ redirects, via seal.verisign.org, to the American Cancer Society. DMCA takedown *plus* domain-jacking?
> The whole point of using many smaller rockets is some little thing known as the economy of scale.
Economies of scale were supposed to drive the shuttle too, only they didn't, because the original assumptions about the cost of re-use were too low, *even before* any LOC/LOV failures.
So be careful yourself about assuming small multiples assures low cost. If launching and securing *any* vehicle creates a high minimum cost, the remaining cost savings from any economies of scale could be inadequate to lowering the cost of the whole enterprise.
There are two problems with this analysis. The first is that you (as many coders do) assume that tools that require intelligence on the part of the coder is an unalloyed good. Businesses, however, don't see it that way, especially large ones with many coders.
As Dave Clark once said in a different context, and architecture is partly there to tell you what you *can't* do. Programming languages are like that as well. Java is very good at encouraging certain idioms and discouraging others. Perl is not so good at either thing. Organizations that want structure will also want languages that support structure.
The answer "But its their fault for hiring dumb coders!" won't wash, because when you are the gas company working on maintaining a legacy billing system, you have to hire coders of average quality, and a language that allows coders of average quality to do stupid things is inferior to a language that shapes their work, *even if it slows them down*.
The second problem with this argument is fetishization of the individual coder, when most large codebases, esp in businesses, are social affairs. Even stipulating the impossibility that every business should hire only coders of above-average intelligence, different coders are intelligent in different ways. When 'Code as thou wilt' is the whole of the law, confusion abounds.
Did you ever see Rael Dornfest's bloxom blog project? Elegant, tight perl that did stuff like string replace on slashes in a fiel path to get an array of dir names, the file name itself, *and* kept the number of substitutions as a variable for traversal depth, in a single line. It was smart, but it also took other coders a long time to understand the JAPHishness of that single line of code, because it was doing three things at once.
Interestingly, he re-wrote it in Python, and its better, mainly because you can't do stuff like use the Boolean return of an assignment as a side-effect for an if test, and there's no concept of $_. Perl doesn't require JAPHishness and Python doesn't completely banish it, but other things being equal, Python produces more sociable code.
Once you start seeing the business imperative as enabling a group of acceptably competent programmers to work together, rather than being a platform for individual brilliance, the original article starts to look a lot more sensible.
Many people have done this before -- the technique, dated from the earliest example I know (Barbelith) is at least a decade old.
It's just that the social aspects of social software are passed around as lore, not documentation, so they take longer to spread than engineering insights.
That kind of rapid growth is meaningless on such a small base. Barely nudging 2% doesn't say much about the obstacles Linux on the desktop faces in penetrating a workplace dominated by MSFT apps. I run Ubuntu on my desktop, and I'm pretty impressed with its ability to handle MS-format files, but I also recognize that a) my user pattern is nothing like most office workers and b) I don't need to run any obscure Win-only apps.
Linden does not have 2.4 million users, and it does not regularly report how many users it does have. It reports "Residents", a figure that includes people who have signed up for Second Life but never logged in. It also double-counts people who have more than one avatar.
n s_second_life_numbers_and_the_presss_desire_to_bel ieve.php#comments
s econd_life_numbers_thanks_to_david_kirkpatrick.php
More about the uselessness of the Residents figure here: http://many.corante.com/archives/2006/12/26/linde
The only person to whom Linden has reported a count of active users is David Kirkpatrick of Fortune, and as of last week, only 252K people had logged into Second Life twice or more in two month -- the rest were bailouts. This 252K figure, which is a much more accurate reflection of Second Life's popularity, is an order of magnitude lower than most of the press is reporting.
More on Kirkpatrick's numbers here: http://many.corante.com/archives/2007/01/04/real_
This battle has been fought and lost. The term 'cracker' was a belated attempt to create a good witch/bad witch distinction after the press took a dim view of hacking, but it is totally artificial. To take but one example, Ken Thompson's seminal Reflections on Trusting Trust, spends some time moralizing (his word) about the 414 and Dalton gangs, saying "The acts performed by these kids are vandalism at best and probably trespass and theft at worst. It is only the inadequacy of the criminal code that saves the hackers from very serious prosecution." This is from the mid-80s, when breaking and entering was clearly described as hacking by one of the giants of the field. Hacking historically covered all forms of unapproved exploration of computer systems; in a more halcyon time, the gray area was wide, and the black area was not too black. Times have changed, but the fact that some hacking is now explicitly criminal, as Thompson predicted, does not make it not hacking.
You are correct -- people who don't want to hear the truth won't hear it, no matter how clearly presented. You seem, however, to be drawing a false conclusion from that, which is that the truth doesn't matter. In working social systems, accurate criticism creates effective responses, no matter what the disbelievers do. If the study had been well done and well presented, instead of badly done and badly presented, people who do care about the truth could have set about fixing or imporving any bottlenecks in the OS stack. Considered in that light, the study, as presented, simply punts the question of truth, because it is not described clearly enough either to replicate or react to.
Take a look at Physical Computing. It's sub-titled "Sensing and Controlling the Physical World with Computers" and features instructions and projects for basic work wiht sensors and simple chips like the PIC and BX-24. (Full disclosure: The authors are colleagues of mine at the Interactive Telecommunications Program at NYU.)
Cory Doctorow has a fantastic commentary on how wrong this article is, concentrating especially on the authors credulous assertion that DRM is an absolute requirement for the ebooks market. Says Cory: "But the author goes further and asserts that without DRM, there will be no market for entertainment product ever again ("If publishers stop wanting DRM, it's the end of popular creative arts. Not as we know them, but period.") despite the fact that the software industry got bigger when it abandoned DRM, and despite the fact that no new medium has ever succeeded by appealing to the virtues of the medium before it [...]" Well worth a read.
$25/mo + state and local taxes, which will probably bring the total to closer to $50.
Nope. Flat rate is a different _kind_ of pricing than metered, and consumers strongly prefer flat rate, a pattern in telecommunications pricing that has been true for 150 years, as shown by the economist Andrew Odlyzko in his survey of telecom economics, Internet pricing and the history of communications (PDF). Companies offer flat-rate pricing have an advantage over companies offering metered service, no matter how cheap the metering is. (This, of course, is also why micropayments never catch on among consumers.)
"The important information will save itself without outside help."
That's whistling past a pretty big graveyard.
The problem is that time changes the definition of interesting. Would you be interested in the ads from a copy of the NYTimes.com from 1998? Probably not, unless you wanted to chuckle at the 667Mhz Pentia selling for $2500.
Would you be interested in the ads from a copy of the New York Times in _1898?_ Those ads are a view into a world you never inhabited, and expose the preoccupations of the era in a way that the articles don't.
We can look at the 1898 ads, not because the important information saved itself, but because archivists did. Someday the ads from 1998 will have the same interests for historians and anthropologists. Who will do the archiving there?
If we leave it to the present to sort the good from the bad, the future will never know what we considered unimportant. If you'd asked anybody in 1960 what that era's biggest technological revolutions of the time were, they'd have all said atomic energy and space travel. The real answers turned out to be the transistor and the birth control pill.
We are just about the worst possible people to ask what's important now, because we're too close, and it would be hubris to pretend otherwise.
-clay
An indefinite storage period is only part of the problem. Even if you keep the 1s and 0s by copying them every five years, file formats go out of scope, and even if you keep the software the file was saved in, the OS that ran it may well be dead (most are, after all) and even if you save a copy of the data _and_ the application that can read it _and_ the OS, what hardware are you going to run it on?
So its a nested set of problems, with no one solution -- copying, conversion and emulation will all be required.
There are two major advantages of analog over digital: the first is that inaction over a period of years does not destroy analog material. If you put a stack of paper in a box in the early 90s, it's probably fine. That degree of inaction, however, can be the death knell for digital material. If you put a stack of CD-ROMs or disks away in the early 90s, chances are at least some of that material is gone.
The second is that while analog degrades slowly, bit-sensitive digital data (encrypted, compressed or executable files) degrades extremely quickly. If you make a mistake handling a book, say, you may end up with one torn page, but if you lose even a small piece of a bit-sensitive file, the entire thing vanishes forever.
-clay
You don't need a static IP if you have a static phone number. Once Vonage gives you a phone number, it keeps that at the permanent entry in its db, matching your phone's dynamic IP to that phone number on the fly.
This is the ICQ model, where the IP address is treated as the temporary half of a permanent->temporary lookup table. This is one of the big wins for this version of VoIP.
-clay
You're comapring apples and oranges. Don't think that today's Type 3 plain-paper "just plug it in and it works" fax was like the fax machines of 1984. Those fax machines costs thousands of dollars, had poor quality, were difficult to set up, and required lots of maintenance for their toner replacements and special fax-only paper.
The reason we have easy to use cheap fax machines today is that there was a market for difficult expensive ones 15 years ago. The same thing happened with radios, calculators, and, of course, computers.
Today's VoIP and WiFi installations are cheaper and easier than they used to be, and will be both cheaper and easier again by the end of this year. Comparing a mature technology with one still in early adoption phase, and concluding that the latter has no chance, is to mistake the acorn for the oak.
-clay
I didn't want to make the article too much of a trip down memory lane about ZapMail, but in fact FedEx _did_ own the underlying technology. They built a proprietary data network to support the service. It was the owners of fax machines who didn't own the underlying technology.
And the bundling of DSL and phone doesn't keep you from keeping the phone for POTS/911 service and moving everything else to VoIP. Unless you have the bare minimum phone service and no LD charges, this may well be a cost-saving option.
-clay
Two points:
First, the "big boys" you name are not the incumbent local exchanges, or ILECs, like SBC, BellSouth and Verizon. The article, written for the general reader, glosses over the difference between local and long-distance service, but its the ILECs who have the most to lose from Vonage et al, because the ILECs are the ones who make their money locking out competition and locking in service fees for things like Call Waiting that VoIP can do for free.
Second, the move from Column A (per-minute fees on a voice-optimized network) to Column B (voice as just another flat-rate app on an IP-based data network) is more than just bookkeeping, because you get to charge a lot less for apps in Column B. If all of ATTs LD revenues were to switch to VoIP style pricing tomorrow, they'd be out of business by the weekend.
-clay
Since I can't mail you from the opportunityservices URL, I'll say Thanks here.
(Sounds like a diagnosis of venereal disease, huh?)
The reward of scratching your *own* itch is obvious. The reward of scratching other peoples' itches, especially when they are not likely to even send you a "thank you", are more dubious.
This true, and I address it in the article. LazyWeb, at least as its worked in the past, addresses this in a fashion. Rather than recap, I'll post an excerpt here:
"The canonical motivation for open source developers is that they want to "scratch an itch." In this view, most open source software is written with the developer as the primary user, with any additional use seen as a valuable but secondary side-effect.
Sometimes, though, the itch a developer has is social: they want to write software other people will adopt. In this case, the advantage of the LazyWeb is not just that a new application or feature is described clearly, but that it is guaranteed to have at least one grateful user. Furthermore, LazyWeb etiquette involves publicizing any solution that does arise, meaning that the developer gets free public attention, even if only to a select group. If writing software that gets used in the wild is a motivation, acting on a LazyWeb description is in many ways a karmically optimal move."
To set the record straight, during 2000 and 2001, I worked at an incubator called The Accelerator Group, where my job was to assess new businesses' technologies. I certainly wan't the one writing the checks, and I certainly do think Python (and perl and Ruby) are innovative.
As for successes, and failures, I detect another pattern in your list. Open Source does better the deeper in the stack it is. Deep in the stack == programmers as users. Tools high in the stack, on the other hand, have a strong split between the people writing the software and the average user. I am wondering if LazyWeb can bring about useful communication across that gap, at least among users capable of describing what they want clearly and developers looking for outside inspiration.