Furthermore, I don't want to make ISP's responsible for the content that they are hosting. I think that would set very bad precedent, and the internet as a whole will be much better off if if ISPs are legal regarded as common carriers.
This isn't about content; it's about behavior. If I rant with a bullhorn at 4 am on your street, the cops will happily haul me off for disturbing the peace, even if I'm reading the Bill of Rights.
Sending spam is in the same category as running DDOS attacks, spreading viruses, or attempting to break in to other people's servers. It's an abuse of the network, and ISPs have no legal or moral obligation to lend their resources to people abusing the network, any more than a landlord has the obligation to let somebody run a crack house.
Regardless of definitions of theft, it's going against the wishes of the copyright holder. [...] And that is, quite bluntly, wrong.
No, the technical term for that is "illegal". Copyright is a legal device that we use to encourage the creation and dissemination of creative works. It is limited in both scope and duration. Those limits have varied widely over the years and are under heavy pressure to change again.
There is no universally acknowledged moral right for somebody who comes up with an idea to simultaneously share it with other people and still control it utterly. Merely asserting otherwise only polarizes discussion on an already difficult topic.
If you'd actually like to help move the discussion forward, try saying things like, "I think it's wrong."
If you find your government doing something stupid or corrupt, does Hanlon's Razor mean that you should ignore it?
Of course not. And nothing in my comment suggests that.
Look, you suggested that the only possible explanation for large IT project failures in government was corruption. I'm saying that corruption only one possible explanation, and that absent actual evidence of corruption it's more likely that people were just being idiots, not villains.
I've investigated a few large project failures in both business and industry, and I'm pretty sure that in the ones that I looked at, normal human arrogance and stupidity was the cause.
Really, your unwillingness to even consider other explanations than corruption and your jumping on me for suggesting otherwise makes you look like a net.kook. If that's not the case, try to mellow out a bit; people will take you more seriously.
Most of my development experience tells me that IT development failures almost always are due to a lack of defined requirements. People *think* they know what they want, but they usually don't. And what they do know, they often cannot articulate. Kinda like the Supreme Court's view of pornography "I can't define it, but I know it when I see it."
I agree with the last part: people often don't know what they want until they see it. But I completely disagree on the solution. I think defining requirements only makes the problem worse: you just collect a lot of information on what people think they want, rather than on what they actually need.
My solution: Ship early, ship often. The most successful projects I've worked on were where we released weekly or even daily. The first thing you ship is just a gamble on how well you can read the users' minds. So I say, make those gambles small. It's only once you start getting feedback that you build the right stuff.
Corporations usually do admit their problems. They often have a legal obligation to inform shareholders about why their company lost $$$ dollars.
That's rich. No, really, you're killing me.
Seriously, large corporations are, from what I've seen, no better than governments in this regard. Sure, corporations have to admit giant failures eventually, but small and medium-sized can be easily buried, especially when managers have an interest in pretending that things are just fine.
Seems to me companies have a much greater incentive to make sure projects succeed.
As a whole, they might. But as individuals, managers have a strong interest in the appearance of success, which, in sufficiently large companies, doesn't strongly correlate with actual success. See, for example, a study on effective management vs successful management.
I've done less government work than corporate work, but from what I've seen the checks and balances were better in government organizations than in corporations. Also, corporate managers have the option of jumping to another corporation and leaving the old company holding the bag on a botched project. Government employees tend to be lifers, which makes them more cautious.
So while I agree that leaders should stop projects from failing, the root causes of the failures are far more complex than just "leadership problems".
Agreed!
Were I to pick one factor that makes the difference between successful projects and failing ones, it's frequency of release. The only way you really know whether your ideas are worthwhile is once they're in the hands of the users. Projects that find that out every few weeks can't go far wrong. Projects that wait years between having a theory and testing it in the real world are, from what I've seen almost certain to be doomed.
You could call that a "leadership" problem, I supppose. Instead I'd be more likely to call it a lack of humility.
You're missing the point that Linux is free, and Java is also given away free. Sun had sufficient revenue from their hardware business that they could afford to fund Java and give it away. Linux, in theory, doesn't depend on paid labor (though in reality it does).
Perhaps I wasn't clear. I didn't say that they should have tried to be Java or Linux. I'm saying they missed the opportunity to take advantage of factors that made Java and Linux successful.
Moreover, they could have done worse things than trying to be Java or Linux. Although both of those are free, both created ecosystems in which people are making plenty of money. Linus never cared to capitalize on that and Sun tried only halfheartedly, but I don't think that's sufficient to prove that the strategy can't work.
I'm not sure NeXT ever had the kind of revenue stream for them to survive a low-cost strategy. And it's by no means clear that there ever existed a large enough market to support them on a lower-cost strategy.
I don't think it was an either/or choice. There are plenty of examples of products with both low- and high-end offerings. Some of those low-end offerings are even free (e.g., Eclipse, Fedora). Why? Because low-end offerings are how you get mindshare, and that's where a lot of your eventual customers come from. Tiny acorns, etc. NeXT never got that.
It's easy enough to wave one's hands, ten years later, and say how it should have been done. But only if you willfully ignore unpleasant market realities.
Thanks, but I'm mainly talking about what they did and were told at the time; the mention of Java and Linux was just to counter somebody else's implication that they were pretty much doomed no matter what they did.
I saw them drive away a lot of customers, both potential and actual, by their insistence on a sealed-box, ultra-proprietary approach, their focus on the very high end of the market, and their unwillingness to really listen to their customers. I personally, like many others, wasted many hours pleading for more openness so that I could, gratis, fix their bugs and improve their products. I also, like many others, regularly told them of specific business opportunities they were missing through their choices. They rarely listened, and then only grudgingly.
My impression was that although I dealt with many nice, great people at NeXT, the company as a whole generally acted in an arrogant fashion. I don't blame the lower-level people for this; I think it came from the top. And from the stories I hear and read about Jobs, that seems to fit.
You may have your own analysis of what NeXT did that led them to disaster, but that's mine.
However, I think he's off-base on his suggestion to allow the customer to "own everything".
For me, this is always the stickiest point of contract negotiation with clients. I agree with the article: if you can let the customer own everything, that's much, much easier.
Of course, if much of your work is programming, it can be frustrating to keep rebuilding things that you need on pretty much any project. I've seen two good ways to get around this.
One is to invest some of your own time writing some of that library code. Then when you start with a client who needs it, you can say: I'll let you use my library code for free as long as I get to use any improvements I make to it while I'm here. This way the customer feels like they're getting something of value in exchange for something they probably don't care about. Everybody's happy.
Alternatively, you can release your library code as open source code. Then you add a contract clause saying that any improvements you make on open source projects will be submitted back to the project. Years ago this was a hard sell, but now the clients I deal with generally get that using open-source libraries is a big win for them. As a bonus, the open-source code serves as a free advertisement for you.
Ok, it looks like that my way of explaining and your way of listening don't match so well. I'll take one more pass at conveying my point. After this, you're on your own. Note that I'm just trying to tell you what my view is. You're welcome to agree or not as you please.
But you don't mention replacing parts or entire classes wholesale - which is very important, especially WRT not shipping source.
I'm not denying that there are solutions to some problems. I'm saying that limiting customers to those partial, inferior solutions was a substantial contributor to the eventual rejection of NeXT technologies in places I did work for. And it's not just me; read the post from a developer at SwissBank, one of NeXT's most prominent customers, that says basically the same thing.
So why not run it on Solaris or Windows? Maybe you did, and that certainly got you around NeXT's "closed OS problems". (hah)
"Hah"? Look, if you're going to be a prick about this, I've got better things to do.
As you know, the ports to other platforms came much later in NeXT's lifecycle. That was not an option for years. And for people who had already made substantial investments in NeXT's hardware or, later, OS, saying, "Hey, why don't you just undergo a major, expensive platform change so that we don't have to be bothered showing you the source and accepting free patches that fix our bugs," is exactly the kind of dismissive contempt for customer concerns that drove a lot of early adopters away.
As for x-platform and x-processor support, the existing users and developers being screwwed - yup, they pretty much were. But I'm pretty sure the writing on the wall was "You're Screwed" one way or another.
Oh, please. Looking at my notes from the private Enterprise Alliance Partners session at WWDC 1997, where they told all the serious NeXT software vendors and in-house development shops what to expect post-merger, they said things that were very, very different than the line you're giving now.
In particular, they promised that Rhapsody would continue to ship for Intel hardware at the same time as the PPC shipments and that you'd still be able to ship your apps for Windows NT, too. They promised what would become OS X Server for early 1998 and the consumer OS X for mid 1998. None of this was even close to the truth. Whether they were fools or liars, I'm not sure, but either way people who trusted them paid a heavy price for it.
Potential is a wonderful thing. End users and sales are wonderful, too. You have to balance the two of them. Apple has brought what I like to call "OpenStep 6.0" to more users than NeXT ever could.
Yes, but the point of the originator of this thread, which I agree with, is that their arrogant refusal to listen to customers or play well with other vendors was a big part of what lost them end users and sales. Screwing the remaining NeXT faithful at the end was just an extreme example of what I see as a consistent theme. You apparently don't see it, but as somebody who worked there for years, I wouldn't really expect you to.
The world was ready for both an open, Unix-based OS and object-oriented development, as the rise of Linux and Java prove. NeXT had technology that was years ahead of either one at the time. IMHO, Jobs's notorious arrogance and insistence on complete control led NeXT to miss that wave entirely.
Absolutely. I remember at Swiss Bank we had a problem with NXTable [great, detailed description of killer bug deleted]. Compare that with Java today where you get the source to all the classes.
There was lots of stuff like that going on. Basically Swiss Bank had bought into a lot of marketing hype about development under NeXTStep being "ten times faster" than any other environment. Which may have been true for the sort of noddy demos Steve Jobs used to love, but certainly wasn't for large real world projects. And don't even get me started on the Disney WorldView debacle!
And the thing that just killed me was that they had the potential to be great for large-scale projects, too. So much potential! And so much of it wasted.
I'm glad the Mac devotees finally got a decent OS and, in the bargain, some sweet development tools. But for those of us who can't bet our projects or companies on a single niche vendor with ultra-proprietary instincts and a history of jerking the rug out from under customers, it was a sad outcome.
That's what subclassing is all about. And if you can't (for some reason) fix it with subclassing, you can replace methods wholesale at runtime. This is not C++, where the black box can't really be touched - it is objective-c, where you can replace methods or even classes at runtime.
Gosh, thanks, I've been doing OO programming in four or five different languages for more than a decade; I don't know how I missed this subclassing thing until now.
Seriously, I agree that in some cases it was possible to eventually hack around some bugs or issues. But only some bugs are easily amenable to that, and even those are only overridable once you figure out exactly where the bug is. And that only applies to the parts where you're dealing with Objective C development; if it was an issue in their closed custom apps or their custom OS or, in the beginning, their custom hardware, you were yet more screwed. Which, on regular occasions, I was.
My point is that with a more open attitude from NeXT, hopefully including source access and a willingness to occasionally listen to their customers, it would have been much easier to do development and systems administration with their gear.
I have to grin when read that statement. If you think NeXT is dead, you haven't looked at Apple recently.
It seems you weren't a NeXT developer or NeXT owner. After the merger between Apple and NeXT in early 1997, they promised a release of the new merged OS in early 1998. It was actually the end of Q1 2001 before they got it out the door. In the meantime, NeXT and users developers were pretty much screwed.
I agree that some the technology lives on, but what NeXT was, including a cross-processor OS and a cross-platform development environment with Windows and Unix support, died with the Apple merger. What emerged was the the standard Apple we'll-tell-you-what-you-like routine. That seems to work for some people and I'm glad they like it, but it's a small fraction of the potential that NeXT had.
Forgive me, but I seriously doubt that was a drop in the bucket compared to the other competitive challenges NeXT had in the 90s.
You miss my point. That was an example of their its-my-bat-and-ball arrogance, not a major problem in itself. When they launched, they had a huge number of geeks drooling or preaching, and a lot of the rest at least interested. But by dribs and drabs, they alienated a lot of the people who could have made a difference.
Um, sure. By 1995, I don't think pricing would have helped much, if at all. NeXT was already facing Win95 and Java.
With OpenStep running under NT, Solaris, and on the Alpha boxes, they had the best cross-platform OO development toolkit around. And unlike Java, it was a mature environment that pretty much worked. With WebObjects and EOF they had a fantastic web development toolkit, years ahead of anybody else. But the insisted on ridiculous license costs and entirely blew their lead.
On both of these, pricing would have made a big difference. I'm sure of that because it would have made a different to my clients, and the companies my NeRD friends worked for. NeXT's high prices entirely cut out anybody who wasn't working for a Fortune 500 company or a financial trading company. And a lot of the interesting GUI work and almost all of the interesting web work in those days was outside the bureaucratic confines of the "enterprise" market.
From what I hear from pals, much of the interesting interface work is in ubiquitous computing. The basic notion is that we're reaching the end of the era where the computer is an appliance that you go to like a stove or a refrigerator. Instead, computers get woven more closely into everyday life, including handhelds, wearables, and smart furniture. Although today it's mainly science fiction and art projects, I'm hearing interesting stories from friends about research prototypes.
Unfortunately for your thesis, those "kits" were what NeXT customers really wanted, and what kept the company going so long.
As somebody who used NextStep from 0.9, I'd agree that NeXT had some cool stuff, and that's what kept them afloat. But I'd agree more with the previous poster: their ultra-proprietary, we're-smarter-than-you, sealed-box attitude was part of what killed them.
I remember one cool University of Michigan software project that required a pseudotty for each remote user, but the kernel NeXT shipped was limited to something like 16 or 32. NeXT wouldn't let you build your own kernels and refused to build a custom kernel for the project, suggesting that the developers buy new NextCubes to accommodate the extra users. End result: the project had to be rebuilt in another language and used Sun hardware, and some local NeXT evangelists swore never to touch them again.
Yes, I can certainly see why developers would be upset that NeXT gave them frameworks to build upon, which let them build their highly profitable trading systems very, very quickly. No, what they really wanted was a primitive system which required them to start from scratch.
Well, actually, what the builders of trading systems wanted, at least the ones I worked with, was kits with source code that they could view and change. It was hugely frustrating to be bitten by some annoying bug or limitation, with the only recourse being to call up your sales rep, give him an earful, and hope, generally in vain, for a fix some months later. This was especially fun when the bug or limitation caused problems for traders, some of whom would express their displeasure by five or ten minutes of screaming verbal abuse.
And really, the focus on high-dollar customers like financial traders was also part of what killed them. In the mid-90s I could have written and sold a ton of great solutions built on NeXT technology, but only financial traders could afford to license the NeXT OS or runtime.
I loved the NeXT technology, but NeXT's high-handed, arrogant behavior eventually drove me and a lot of other early adopters away cursing the day that Steve Jobs was born.
The idea of a testing repository is quite interesting, but, in practice, a useless one.
Your imagination is pretty limited. This is of use in any area where developers will use similar data for lots of different things, especially in areas of active research. Some examples include:
mailing addresses - all sorts of apps need to parse international mailing addresses: wouldn't it be better to test with real samples?
email - corpuses of known good email and known spam email are necessary for any spam recognition tool
speech - for both speech recognition and speech synthesis, a large body of audio with a variety of speakers and accents is useful
text - there are several large databases of text on-line, useful for everything from machine translation research to historical linguistic analysis
web pages - right now one of my clients is working on a project to extract structured data from web pages. If somebody had a large corpus of messy HTML pages and matching clean structured data, it would be hugely useful in evaluating algorithms. Instead, we're doing that by hand.
So yes, I agree, don't reinvent the wheel. But also, don't recreate a test dataset.
I've been programming Java for years and I've always used vi. How much time have I wasted? I find IDEs a bigger waste of time.
Up until IntelliJ's IDEA I would have agreed with that. As if I needed a buggy, limited text editor with a bunch of cruft-generating wizards. Blech. Yeah, I'm talking to you, JBuilder.
However, IDEA is an utterly different experience, and Eclipse is a reasonably close competitor. Both of them allow you to navigate the code in a much more dynamic way, and the tight integration with JUnit allows you a much faster development cycle than is possible with something like vi. Also wonderful is the tight CVS integration (with per-line color hints), the java-aware assistance (like the live templates and the intentions), and the in-editor docs (where a quick keystroke can show you the javadocs, the parameters, similarly named methods, and other valuable info).
Plus, there's excellent support for keeping your hands on the keyboard; although I do use the mouse sometimes, I never have to use it.
So download it and give it a fair try. I liked it enough that I bought a license out of my own hard-earned cash. It's that good.
Now you need to recoup that money, but supply and demand dictates you can only raise prices so high.
You keep asserting this, but the classic monopolies, the trusts from which the antitrust laws take their name, managed to effectively control supply through tactics that are now illegal. This is basic economics, and your assertions otherwise are unconvincing.
In either case, your notion that a competitor must have as much money as the monopolist is incorrect. Look at the software business [...]
We were talking about bakeries, which are a pretty traditional product. I agree that software is entirely different. Digital information, once you have the first copy, costs basically nothing to duplicate. Software adds further complications in that network effects can be very important.
So whether Microsoft is "really" a monopoly in the classic sense of the term is an interesting theoretical question. Also interesting is whether it might be net beneficial for their to be a privately owned OS monopoly: there are certain benefits to everybody using the same things.
Personally, I think the answers are "yes" and "no". Reasonable people might differ, but until you show some undertstanding of economics, I doubt you'll be differing in an interesting way.
I can get software with more features, for less money (in real dollars) than I could in 1979 when there were a number of competitors in thw home PC market, none of which were anywhere close to a monopoly
Which means absolutely nothing. The question isn't whether the world is better than it was in 1979; it's whether the world could be better still if we stop Microsoft from using its position of incredible desktop dominance to crush competitors and to take over new market spaces.
Having worked for a number of startups in Silicon Valley, I can assure you that Microsoft's dominance reduces the amount of innovation. Entrepreneurs here know what happens when you go up against Microsoft. Bob Cringely accurately conveys that. I think that's a huge loss to the economy as a whole and computer users in specific.
on places that allow port 25 (which is free from the start, not "with permission") you still have to deal with the RBL's bitchy little sister, the Dynamic IP Blackhole List.
If you can't even get a permanent IP address, just relay mail through your ISP's mail server. I'm not interested in accepting email from somebody who thinks they're such a technical hot-shot that they must relay their own mail but can't be bothered running a proper mail server.
In order to build up cash reserves, monoploists must rais eprices, but if they raise prices, then competitors move in.
If they keep prices low enough so ocmpetitors don't move in, consumers benefit from lower prices.
There's substantial lag here. If I drive all the bakeries in a city out of business, I can make quite a bit of money before somebody has time to open even one bakery. And really, to keep my prices down, they need to compete with all of my bakeries, not just one of them. Otherwise I just subsidize the bakeries near them.
So to successfully get back to non-monopoly conditions, somebody needs to start with all the money I have plus enough money to open all the stores I have plus enough money to get an equal share of the customers coming to the new stores. And even that may not be enough, as the establishd monopoly will have a easier time raising more money than the upstart. It's not impossible, but it's a huge barrier to entry. One small businessman cannot successfully challenge a monopoly.
But then new competitors move in, because they can make a profit at the higher price, which forces the monolpolist to lower prices again, and keep them there, to keep out competition. If they echibit a pattern of lowering and raising prices, competitors will stay in beacuse they believe the low prices ar enot sustainable and eventually prices will rise to livable levels.
This is only the case if the competitor believes they have enough money to outlast the monopolist. But the monopolist can build up large cash reserves, and they need only drop prices where the competitors are actually present, using areas without competition to subsidize the areas where there is an active challenge.
So by and large, you don't get competitors to monopolies because people know it's a losing game to go head to head with a monopoly.
Guilty until proven innocent, eh? I don't think so.
There are many things where you need to prove that you're not completely clueless. A driver's license is a fine example of this. For driving a normal car, the license is relatively easy to get. To drive a big truck, it's harder. Want to fly a plane? Harder still. Innocence and guilt aren't the issue: competence is.
99% of DSL subscribers don't even know what having unblocked port 25 access means, let alone care about having it. For the small fraction of us who need the extra power and know how to use it, just asking for it seems a pretty small extra step.
Slashdot Mirror
Furthermore, I don't want to make ISP's responsible for the content that they are hosting. I think that would set very bad precedent, and the internet as a whole will be much better off if if ISPs are legal regarded as common carriers.
This isn't about content; it's about behavior. If I rant with a bullhorn at 4 am on your street, the cops will happily haul me off for disturbing the peace, even if I'm reading the Bill of Rights.
Sending spam is in the same category as running DDOS attacks, spreading viruses, or attempting to break in to other people's servers. It's an abuse of the network, and ISPs have no legal or moral obligation to lend their resources to people abusing the network, any more than a landlord has the obligation to let somebody run a crack house.
Regardless of definitions of theft, it's going against the wishes of the copyright holder. [...] And that is, quite bluntly, wrong.
No, the technical term for that is "illegal". Copyright is a legal device that we use to encourage the creation and dissemination of creative works. It is limited in both scope and duration. Those limits have varied widely over the years and are under heavy pressure to change again.
There is no universally acknowledged moral right for somebody who comes up with an idea to simultaneously share it with other people and still control it utterly. Merely asserting otherwise only polarizes discussion on an already difficult topic.
If you'd actually like to help move the discussion forward, try saying things like, "I think it's wrong."
If you find your government doing something stupid or corrupt, does Hanlon's Razor mean that you should ignore it?
Of course not. And nothing in my comment suggests that.
Look, you suggested that the only possible explanation for large IT project failures in government was corruption. I'm saying that corruption only one possible explanation, and that absent actual evidence of corruption it's more likely that people were just being idiots, not villains.
I've investigated a few large project failures in both business and industry, and I'm pretty sure that in the ones that I looked at, normal human arrogance and stupidity was the cause.
Really, your unwillingness to even consider other explanations than corruption and your jumping on me for suggesting otherwise makes you look like a net.kook. If that's not the case, try to mellow out a bit; people will take you more seriously.
Anything that has been "common for a long time", with no effective corrective action, is deliberate.
You're forgetting Hanlon's Razor. Stupidity, false pride, arrogance, wilful ignorance, petty jealousy, and folly have been common for a long time too.
Most of my development experience tells me that IT development failures almost always are due to a lack of defined requirements. People *think* they know what they want, but they usually don't. And what they do know, they often cannot articulate. Kinda like the Supreme Court's view of pornography "I can't define it, but I know it when I see it."
I agree with the last part: people often don't know what they want until they see it. But I completely disagree on the solution. I think defining requirements only makes the problem worse: you just collect a lot of information on what people think they want, rather than on what they actually need.
My solution: Ship early, ship often. The most successful projects I've worked on were where we released weekly or even daily. The first thing you ship is just a gamble on how well you can read the users' minds. So I say, make those gambles small. It's only once you start getting feedback that you build the right stuff.
Corporations usually do admit their problems. They often have a legal obligation to inform shareholders about why their company lost $$$ dollars.
That's rich. No, really, you're killing me.
Seriously, large corporations are, from what I've seen, no better than governments in this regard. Sure, corporations have to admit giant failures eventually, but small and medium-sized can be easily buried, especially when managers have an interest in pretending that things are just fine.
Seems to me companies have a much greater incentive to make sure projects succeed.
As a whole, they might. But as individuals, managers have a strong interest in the appearance of success, which, in sufficiently large companies, doesn't strongly correlate with actual success. See, for example, a study on effective management vs successful management.
I've done less government work than corporate work, but from what I've seen the checks and balances were better in government organizations than in corporations. Also, corporate managers have the option of jumping to another corporation and leaving the old company holding the bag on a botched project. Government employees tend to be lifers, which makes them more cautious.
So while I agree that leaders should stop projects from failing, the root causes of the failures are far more complex than just "leadership problems".
Agreed!
Were I to pick one factor that makes the difference between successful projects and failing ones, it's frequency of release. The only way you really know whether your ideas are worthwhile is once they're in the hands of the users. Projects that find that out every few weeks can't go far wrong. Projects that wait years between having a theory and testing it in the real world are, from what I've seen almost certain to be doomed.
You could call that a "leadership" problem, I supppose. Instead I'd be more likely to call it a lack of humility.
You're missing the point that Linux is free, and Java is also given away free. Sun had sufficient revenue from their hardware business that they could afford to fund Java and give it away. Linux, in theory, doesn't depend on paid labor (though in reality it does).
Perhaps I wasn't clear. I didn't say that they should have tried to be Java or Linux. I'm saying they missed the opportunity to take advantage of factors that made Java and Linux successful.
Moreover, they could have done worse things than trying to be Java or Linux. Although both of those are free, both created ecosystems in which people are making plenty of money. Linus never cared to capitalize on that and Sun tried only halfheartedly, but I don't think that's sufficient to prove that the strategy can't work.
I'm not sure NeXT ever had the kind of revenue stream for them to survive a low-cost strategy. And it's by no means clear that there ever existed a large enough market to support them on a lower-cost strategy.
I don't think it was an either/or choice. There are plenty of examples of products with both low- and high-end offerings. Some of those low-end offerings are even free (e.g., Eclipse, Fedora). Why? Because low-end offerings are how you get mindshare, and that's where a lot of your eventual customers come from. Tiny acorns, etc. NeXT never got that.
It's easy enough to wave one's hands, ten years later, and say how it should have been done. But only if you willfully ignore unpleasant market realities.
Thanks, but I'm mainly talking about what they did and were told at the time; the mention of Java and Linux was just to counter somebody else's implication that they were pretty much doomed no matter what they did.
I saw them drive away a lot of customers, both potential and actual, by their insistence on a sealed-box, ultra-proprietary approach, their focus on the very high end of the market, and their unwillingness to really listen to their customers. I personally, like many others, wasted many hours pleading for more openness so that I could, gratis, fix their bugs and improve their products. I also, like many others, regularly told them of specific business opportunities they were missing through their choices. They rarely listened, and then only grudgingly.
My impression was that although I dealt with many nice, great people at NeXT, the company as a whole generally acted in an arrogant fashion. I don't blame the lower-level people for this; I think it came from the top. And from the stories I hear and read about Jobs, that seems to fit.
You may have your own analysis of what NeXT did that led them to disaster, but that's mine.
However, I think he's off-base on his suggestion to allow the customer to "own everything".
For me, this is always the stickiest point of contract negotiation with clients. I agree with the article: if you can let the customer own everything, that's much, much easier.
Of course, if much of your work is programming, it can be frustrating to keep rebuilding things that you need on pretty much any project. I've seen two good ways to get around this.
One is to invest some of your own time writing some of that library code. Then when you start with a client who needs it, you can say: I'll let you use my library code for free as long as I get to use any improvements I make to it while I'm here. This way the customer feels like they're getting something of value in exchange for something they probably don't care about. Everybody's happy.
Alternatively, you can release your library code as open source code. Then you add a contract clause saying that any improvements you make on open source projects will be submitted back to the project. Years ago this was a hard sell, but now the clients I deal with generally get that using open-source libraries is a big win for them. As a bonus, the open-source code serves as a free advertisement for you.
I find some humor in the fact that your post is modded too low for you to even read.
Not any more it isn't. Yours is, though.
Ok, it looks like that my way of explaining and your way of listening don't match so well. I'll take one more pass at conveying my point. After this, you're on your own. Note that I'm just trying to tell you what my view is. You're welcome to agree or not as you please.
But you don't mention replacing parts or entire classes wholesale - which is very important, especially WRT not shipping source.
I'm not denying that there are solutions to some problems. I'm saying that limiting customers to those partial, inferior solutions was a substantial contributor to the eventual rejection of NeXT technologies in places I did work for. And it's not just me; read the post from a developer at SwissBank, one of NeXT's most prominent customers, that says basically the same thing.
So why not run it on Solaris or Windows? Maybe you did, and that certainly got you around NeXT's "closed OS problems". (hah)
"Hah"? Look, if you're going to be a prick about this, I've got better things to do.
As you know, the ports to other platforms came much later in NeXT's lifecycle. That was not an option for years. And for people who had already made substantial investments in NeXT's hardware or, later, OS, saying, "Hey, why don't you just undergo a major, expensive platform change so that we don't have to be bothered showing you the source and accepting free patches that fix our bugs," is exactly the kind of dismissive contempt for customer concerns that drove a lot of early adopters away.
As for x-platform and x-processor support, the existing users and developers being screwwed - yup, they pretty much were. But I'm pretty sure the writing on the wall was "You're Screwed" one way or another.
Oh, please. Looking at my notes from the private Enterprise Alliance Partners session at WWDC 1997, where they told all the serious NeXT software vendors and in-house development shops what to expect post-merger, they said things that were very, very different than the line you're giving now.
In particular, they promised that Rhapsody would continue to ship for Intel hardware at the same time as the PPC shipments and that you'd still be able to ship your apps for Windows NT, too. They promised what would become OS X Server for early 1998 and the consumer OS X for mid 1998. None of this was even close to the truth. Whether they were fools or liars, I'm not sure, but either way people who trusted them paid a heavy price for it.
Potential is a wonderful thing. End users and sales are wonderful, too. You have to balance the two of them. Apple has brought what I like to call "OpenStep 6.0" to more users than NeXT ever could.
Yes, but the point of the originator of this thread, which I agree with, is that their arrogant refusal to listen to customers or play well with other vendors was a big part of what lost them end users and sales. Screwing the remaining NeXT faithful at the end was just an extreme example of what I see as a consistent theme. You apparently don't see it, but as somebody who worked there for years, I wouldn't really expect you to.
The world was ready for both an open, Unix-based OS and object-oriented development, as the rise of Linux and Java prove. NeXT had technology that was years ahead of either one at the time. IMHO, Jobs's notorious arrogance and insistence on complete control led NeXT to miss that wave entirely.
Absolutely. I remember at Swiss Bank we had a problem with NXTable [great, detailed description of killer bug deleted]. Compare that with Java today where you get the source to all the classes.
There was lots of stuff like that going on. Basically Swiss Bank had bought into a lot of marketing hype about development under NeXTStep being "ten times faster" than any other environment. Which may have been true for the sort of noddy demos Steve Jobs used to love, but certainly wasn't for large real world projects. And don't even get me started on the Disney WorldView debacle!
And the thing that just killed me was that they had the potential to be great for large-scale projects, too. So much potential! And so much of it wasted.
I'm glad the Mac devotees finally got a decent OS and, in the bargain, some sweet development tools. But for those of us who can't bet our projects or companies on a single niche vendor with ultra-proprietary instincts and a history of jerking the rug out from under customers, it was a sad outcome.
That's what subclassing is all about. And if you can't (for some reason) fix it with subclassing, you can replace methods wholesale at runtime. This is not C++, where the black box can't really be touched - it is objective-c, where you can replace methods or even classes at runtime.
Gosh, thanks, I've been doing OO programming in four or five different languages for more than a decade; I don't know how I missed this subclassing thing until now.
Seriously, I agree that in some cases it was possible to eventually hack around some bugs or issues. But only some bugs are easily amenable to that, and even those are only overridable once you figure out exactly where the bug is. And that only applies to the parts where you're dealing with Objective C development; if it was an issue in their closed custom apps or their custom OS or, in the beginning, their custom hardware, you were yet more screwed. Which, on regular occasions, I was.
My point is that with a more open attitude from NeXT, hopefully including source access and a willingness to occasionally listen to their customers, it would have been much easier to do development and systems administration with their gear.
I have to grin when read that statement. If you think NeXT is dead, you haven't looked at Apple recently.
It seems you weren't a NeXT developer or NeXT owner. After the merger between Apple and NeXT in early 1997, they promised a release of the new merged OS in early 1998. It was actually the end of Q1 2001 before they got it out the door. In the meantime, NeXT and users developers were pretty much screwed.
I agree that some the technology lives on, but what NeXT was, including a cross-processor OS and a cross-platform development environment with Windows and Unix support, died with the Apple merger. What emerged was the the standard Apple we'll-tell-you-what-you-like routine. That seems to work for some people and I'm glad they like it, but it's a small fraction of the potential that NeXT had.
Forgive me, but I seriously doubt that was a drop in the bucket compared to the other competitive challenges NeXT had in the 90s.
You miss my point. That was an example of their its-my-bat-and-ball arrogance, not a major problem in itself. When they launched, they had a huge number of geeks drooling or preaching, and a lot of the rest at least interested. But by dribs and drabs, they alienated a lot of the people who could have made a difference.
Um, sure. By 1995, I don't think pricing would have helped much, if at all. NeXT was already facing Win95 and Java.
With OpenStep running under NT, Solaris, and on the Alpha boxes, they had the best cross-platform OO development toolkit around. And unlike Java, it was a mature environment that pretty much worked. With WebObjects and EOF they had a fantastic web development toolkit, years ahead of anybody else. But the insisted on ridiculous license costs and entirely blew their lead.
On both of these, pricing would have made a big difference. I'm sure of that because it would have made a different to my clients, and the companies my NeRD friends worked for. NeXT's high prices entirely cut out anybody who wasn't working for a Fortune 500 company or a financial trading company. And a lot of the interesting GUI work and almost all of the interesting web work in those days was outside the bureaucratic confines of the "enterprise" market.
From what I hear from pals, much of the interesting interface work is in ubiquitous computing. The basic notion is that we're reaching the end of the era where the computer is an appliance that you go to like a stove or a refrigerator. Instead, computers get woven more closely into everyday life, including handhelds, wearables, and smart furniture. Although today it's mainly science fiction and art projects, I'm hearing interesting stories from friends about research prototypes.
From the code I see out there, I'm pretty sure the industry still isn't used to OOP. Of the Java code I see in industry, about 80% of it is one of
- Perl written in Java
- C written in Java
- COBOL written in Java
Remember, folks: if the data and the code don't go together, it's not OO!Unfortunately for your thesis, those "kits" were what NeXT customers really wanted, and what kept the company going so long.
As somebody who used NextStep from 0.9, I'd agree that NeXT had some cool stuff, and that's what kept them afloat. But I'd agree more with the previous poster: their ultra-proprietary, we're-smarter-than-you, sealed-box attitude was part of what killed them.
I remember one cool University of Michigan software project that required a pseudotty for each remote user, but the kernel NeXT shipped was limited to something like 16 or 32. NeXT wouldn't let you build your own kernels and refused to build a custom kernel for the project, suggesting that the developers buy new NextCubes to accommodate the extra users. End result: the project had to be rebuilt in another language and used Sun hardware, and some local NeXT evangelists swore never to touch them again.
Yes, I can certainly see why developers would be upset that NeXT gave them frameworks to build upon, which let them build their highly profitable trading systems very, very quickly. No, what they really wanted was a primitive system which required them to start from scratch.
Well, actually, what the builders of trading systems wanted, at least the ones I worked with, was kits with source code that they could view and change. It was hugely frustrating to be bitten by some annoying bug or limitation, with the only recourse being to call up your sales rep, give him an earful, and hope, generally in vain, for a fix some months later. This was especially fun when the bug or limitation caused problems for traders, some of whom would express their displeasure by five or ten minutes of screaming verbal abuse.
And really, the focus on high-dollar customers like financial traders was also part of what killed them. In the mid-90s I could have written and sold a ton of great solutions built on NeXT technology, but only financial traders could afford to license the NeXT OS or runtime.
I loved the NeXT technology, but NeXT's high-handed, arrogant behavior eventually drove me and a lot of other early adopters away cursing the day that Steve Jobs was born.
Your imagination is pretty limited. This is of use in any area where developers will use similar data for lots of different things, especially in areas of active research. Some examples include:
- mailing addresses - all sorts of apps need to parse international mailing addresses: wouldn't it be better to test with real samples?
- email - corpuses of known good email and known spam email are necessary for any spam recognition tool
- speech - for both speech recognition and speech synthesis, a large body of audio with a variety of speakers and accents is useful
- text - there are several large databases of text on-line, useful for everything from machine translation research to historical linguistic analysis
- web pages - right now one of my clients is working on a project to extract structured data from web pages. If somebody had a large corpus of messy HTML pages and matching clean structured data, it would be hugely useful in evaluating algorithms. Instead, we're doing that by hand.
So yes, I agree, don't reinvent the wheel. But also, don't recreate a test dataset.I've been programming Java for years and I've always used vi. How much time have I wasted? I find IDEs a bigger waste of time.
Up until IntelliJ's IDEA I would have agreed with that. As if I needed a buggy, limited text editor with a bunch of cruft-generating wizards. Blech. Yeah, I'm talking to you, JBuilder.
However, IDEA is an utterly different experience, and Eclipse is a reasonably close competitor. Both of them allow you to navigate the code in a much more dynamic way, and the tight integration with JUnit allows you a much faster development cycle than is possible with something like vi. Also wonderful is the tight CVS integration (with per-line color hints), the java-aware assistance (like the live templates and the intentions), and the in-editor docs (where a quick keystroke can show you the javadocs, the parameters, similarly named methods, and other valuable info).
Plus, there's excellent support for keeping your hands on the keyboard; although I do use the mouse sometimes, I never have to use it.
So download it and give it a fair try. I liked it enough that I bought a license out of my own hard-earned cash. It's that good.
Now you need to recoup that money, but supply and demand dictates you can only raise prices so high.
You keep asserting this, but the classic monopolies, the trusts from which the antitrust laws take their name, managed to effectively control supply through tactics that are now illegal. This is basic economics, and your assertions otherwise are unconvincing.
In either case, your notion that a competitor must have as much money as the monopolist is incorrect. Look at the software business [...]
We were talking about bakeries, which are a pretty traditional product. I agree that software is entirely different. Digital information, once you have the first copy, costs basically nothing to duplicate. Software adds further complications in that network effects can be very important.
So whether Microsoft is "really" a monopoly in the classic sense of the term is an interesting theoretical question. Also interesting is whether it might be net beneficial for their to be a privately owned OS monopoly: there are certain benefits to everybody using the same things.
Personally, I think the answers are "yes" and "no". Reasonable people might differ, but until you show some undertstanding of economics, I doubt you'll be differing in an interesting way.
I can get software with more features, for less money (in real dollars) than I could in 1979 when there were a number of competitors in thw home PC market, none of which were anywhere close to a monopoly
Which means absolutely nothing. The question isn't whether the world is better than it was in 1979; it's whether the world could be better still if we stop Microsoft from using its position of incredible desktop dominance to crush competitors and to take over new market spaces.
Having worked for a number of startups in Silicon Valley, I can assure you that Microsoft's dominance reduces the amount of innovation. Entrepreneurs here know what happens when you go up against Microsoft. Bob Cringely accurately conveys that. I think that's a huge loss to the economy as a whole and computer users in specific.
on places that allow port 25 (which is free from the start, not "with permission") you still have to deal with the RBL's bitchy little sister, the Dynamic IP Blackhole List.
If you can't even get a permanent IP address, just relay mail through your ISP's mail server. I'm not interested in accepting email from somebody who thinks they're such a technical hot-shot that they must relay their own mail but can't be bothered running a proper mail server.
In order to build up cash reserves, monoploists must rais eprices, but if they raise prices, then competitors move in.
If they keep prices low enough so ocmpetitors don't move in, consumers benefit from lower prices.
There's substantial lag here. If I drive all the bakeries in a city out of business, I can make quite a bit of money before somebody has time to open even one bakery. And really, to keep my prices down, they need to compete with all of my bakeries, not just one of them. Otherwise I just subsidize the bakeries near them.
So to successfully get back to non-monopoly conditions, somebody needs to start with all the money I have plus enough money to open all the stores I have plus enough money to get an equal share of the customers coming to the new stores. And even that may not be enough, as the establishd monopoly will have a easier time raising more money than the upstart. It's not impossible, but it's a huge barrier to entry. One small businessman cannot successfully challenge a monopoly.
But then new competitors move in, because they can make a profit at the higher price, which forces the monolpolist to lower prices again, and keep them there, to keep out competition. If they echibit a pattern of lowering and raising prices, competitors will stay in beacuse they believe the low prices ar enot sustainable and eventually prices will rise to livable levels.
This is only the case if the competitor believes they have enough money to outlast the monopolist. But the monopolist can build up large cash reserves, and they need only drop prices where the competitors are actually present, using areas without competition to subsidize the areas where there is an active challenge.
So by and large, you don't get competitors to monopolies because people know it's a losing game to go head to head with a monopoly.
Guilty until proven innocent, eh? I don't think so.
There are many things where you need to prove that you're not completely clueless. A driver's license is a fine example of this. For driving a normal car, the license is relatively easy to get. To drive a big truck, it's harder. Want to fly a plane? Harder still. Innocence and guilt aren't the issue: competence is.
99% of DSL subscribers don't even know what having unblocked port 25 access means, let alone care about having it. For the small fraction of us who need the extra power and know how to use it, just asking for it seems a pretty small extra step.
Can somebody please explain to me how "Web Services" are not just overhyped XMLified remote procedure calls?
Sure! But first, explain why HTML isn't just an anemic, overhyped page layout language.