Then now's the time to set legal precedence... because if you let one corporation get away with it, you've opened the doorway for others to do the same.
Just because M$ discontinues a product, doesn't necessarily mean that I or my customers want to. I've watched DOS, Windows 3.1, QuickBASIC, and a dozen other things just vanish from the shelves and from tech support. Some people have their businesses dependent on these technologies. If the business changes, and the technology is no longer there... then what? It's expensive to change. Now we watch as NT 3.5, NT 4.0, and Windows 2000 are vanishing to XP. There are far more shops depending on these technologies. Frankly the attitude I'm seeing is "if I have to switch, I'm switching to Linux so this won't happen to me again."
There's the old argument of "if I need support or someone to sue, at least I have Microsoft" -- ask yourself this, when was the last time you got decent support from them? When you needed a new feature or reported a real defect, was it your business model or theirs which was given priority? And if you went to sue Microsoft, and were 100% in the right, given the deep pockets there... could you survive battle the court costs? With the source you can fix it or hire someone to fix it.
The fact of the matter is, business doesn't like to ride technology waves. They want something that gets the job done, works right, and is reliable and as maintanence free as possible. As long as Microsoft misses this point, they're going to alienate customers.
It still amazes me that even IE's about box reports that it stands on the shoulders of NCSA Mosaic.... When I talked with a represanative in Microsoft's security group, they were using Linux internally.... The begs the question about where would Microsoft be without OpenSource? (Guess you could steal it, but hey... wasn't that how GW-BASIC got started?)
I remember my first introduction to Linux years and years ago. There was a definate feeling of overwhelmingness present.
My concern wasn't the fact that I had too much in a distribution, it was that I didn't know what I had or where anything was.
It would be really nice if along with a commercial distribution came a piece of paper which would list standard application categories such a Word Processors/Editors, MultiMedia, Spreadsheets, Online Help, Browsers, Chat Programs, Development, System Administration, etc.
Then under each category list each software applications's name and purpose, how to invoke the program, where the documentation quick start is (info/man/howto), and if applicable where to get a printed resource like a book from O'Reilly.
It would be important to notate whether the user would have to use X to run the application.
This list ought to come in printed format because new users may not know HTML, won't know how to invoke a browser, may not know how to type a file to the screen, and most certainly won't know how to print the information.
From this standpoint Linux distros do require you to have a base set of knowledge before you can gain more knowledge. I read this article as a cry to lower the barrier of entry for the uninitiated.
Remember, once people get a simple distro installed, it doesn't take long at all before the light comes on and they start craving everything. Perhaps that is how entry to the Linux desktop market should happen.
Clearly, mortal users do tolerate large multi-megabyte applications, however whether obtained separately or not isn't the point.
There was a game on "The Source" called PITS
which used a simplistic VERB DIRECTOBJ INDIRECTOBJ sentence structure, but was filled with enormous text descriptions.
The start of the game involved getting a slew
of cash, and then buying a bridge, which was
constructed by hundreds of thousands of little
dwarves in what could only be described as helicopters. You then crossed the bridge, climbed a mountain, went into an old house, and
accessed other worlds by finding secret passages.
The scoring system was as detailed and granular as the plot line. I found it far more fun and challenging than Zork.
Unfortunately, I think it was written for a
Data General, and when The Source got purchased
by Compuserve, the game vanished. The only proof
I have is a few old dusty captures of the start
of the game, combined with a piece of marketing
literature that briefly mentions it.
I've searched all over the net for it, with the
hopes of getting it ported to Linux, but have
come up short. Anyone who might know where a
copy hides, please feel free to contact me.
I've tried all the text game archive sites
I could get links to.
Commercially speaking, I've worked with a number of companies which produced applications for general consumption.
The problem in cases of severe failure has been when quality wasn't enforced top-down from upper management. In other words, when the measure of quality was "did we ship on the planned date" the product suffered.
There seems to be an assumption that once the product is out, a company can cover their mistakes with patches and more releases.
To some extent this is true. The first person to market usually wins. But the catch, as shown by Open Source projects, is that the product has to work first. It doesn't need every flashy feature, it just needs to work. This is how you get an initial install base.
When I'm wearing a development hat, it's frustrating to see a date pushed down from marketing along with a list of requirements. Sadly, I haven't seen development shops asked for their input. After all, they know how long it usually takes to build something.
Tell us when you want it, we'll tell you how long it will take to put in each feature so things that would impede the date can be deferred to the next release. Tell us what you want, and we'll tell you when it should be ready.
Another major error is that organizations don't understand the roll of QA. Management views QA as fixing what's broken from development. QA is a house inspector, not a doctor. Developers look at QA as someone trying to break the product and make them look bad. QA's job is simply to assess the stability, functionality, and usability of the product so that management can evaluate the risk of shipping. Sometimes the right business decision is to let something ship with a flaw in it; other times it isn't.
In cases where management has lacked focus and not enforced a degree of quality, I've seen grass-roots movements establish themselves. Interestingly enough, this never works. Not once. Management holds the reins on schedule and budget, so killing unsanctioned quality-based movements is inevitable. The best scenario is perhaps educating upwards, however getting buy-in at all levels is nearly impossible. This means as an employe, you might want to add management's existing viewpoints into the factor of who you want to work for.
The choice between new-features and more-stability almost always falls on new-features, since that's where sales primarily come from. Those who don't understand the principles of software engineering almost always understand the value of a quick buck.
A small number of places I've been at have allowed for quality improvements. The result is always a happier customer base (who now wants upgrades), happier sales and training people -- since they can demo and have things work, and the big payoff is that due to refactoring and better stability it is possible to add new features in less time.
If there's any lesson to walk away with from all this, it's that you must plan for quality and the drive must come from the top down. It is much easier to design quality in than to sift defects out.
I wonder if the real difference between this example of a gentlemen's agreement versus other uglier disputes is just when a corporation actually has lawyers on staff.
Actually the certificate authorities say "WE BELIEVE YOU ARE THE PERSON YOU SAY YOU ARE." If you trust the CA, then you may implictly trust.
However, that isn't the point. And while many of the activities can be done without SS cards, money, etc. It could be a little tougher on the net to maintain its more unregulated state. I didn't say impossible, just tougher.
Frankly, I used to hold the exact same position articulated above... But Lawrence Lessig makes an excellent case in Code and Other Laws of Cyberspace [IBSN 046503912X ] about the implications government controled CAs have. I still thought there was no big deal until several chapters in, when I realized it wasn't the technical issues, but the legal issues. It gives the government a tool to put its cold grasp around things it can't get at right now.
Don't be so quick to dismiss the long term effects.
It's not the digital signatures, but who controls the certificate authorities that scare me.
After that, it's just a matter of legislating that to provide certain services or present certain content you need a government certificate or you can't do business.
Is age discrimination the problem or just a symptom? I remember when programming was taught as more of an art, and the implementation language was fairly irrelevant. Good programmers could conserve space and increase speed by making smart data structures, wisely choosing algorithms, and optimizing implementations. Design and documentation were part of the development process, just as debugging and profiling were required skills. Tools were just that, tools. They helped the developer do his craft more efficiently and more accurately. However, our tools have become so easy almost anyone can use them and get something to happen. When interviewing, I see 'senior' people with 2 years of experience, usually all academic. Few candidates have impressive problem solving skills these days and instead depend on brute force and trial-and-error to produce solutions (most which need to be revisited). It frustrates me when a "C++ expert" doesn't know the language and can only program when there is a wizard writing the code and a drag'n'drop environment for prewritten components. Change the IDE and the programmer becomes helpless. While I'm not knocking reuse here, the barrier to learning a new language and using it effectively seems to be mentally digesting the colossal sized libraries. This is evident with Perl, Python, C++, Java, etc. They're not hard, it's just big. Given that there are so many languages cropping up, with so many libraries, not to mention the terminology changing, it can be difficult to keep up without an excessive effort. When faced with the economic decision between hiring a recent graduate who knows the libraries, but is weak in 'real' programming versus an experienced developer who's looking at retirement benefit packages and needs a month to ramp up... many companies are taking the cheaper route. Flash sells, and while the experienced programmer can write a device driver in half a week, the one that can get an IDE to crank out a quick GUI in 2 minutes wins. This makes as much sense as when companies in the early 80's laid off expensive development staff to replace them with kids based on their PacMan scores. Unfortunately, since speed and space conservation aren't taught as a way of life software consumers are left with bloated applications that run slowly and crash intermittently. Educational facilities aren't doing anyone a favor by producing a breed of programmers that require crutches to get by. Meanwhile, if the aging developer has the skill to write a coherent English sentence, they usually end up in the elephant graveyard of technical writing.
Wouldn't the advertising agency own anything produced by Company X under standard work-for-hire practices? You'd then be modifying, with permission, code that was intellectual property of the advertising company.
I guess the real question is did the advertising company pay Company X for the [partial] work it did. Either way, this sounds like it's their problem, not yours, as you were acting as an agent for the advertising agency.
Slashdot Mirror
Then now's the time to set legal precedence... because if you let one corporation get away with it, you've opened the doorway for others to do the same.
Just because M$ discontinues a product, doesn't necessarily mean that I or my customers want to. I've watched DOS, Windows 3.1, QuickBASIC, and a dozen other things just vanish from the shelves and from tech support. Some people have their businesses dependent on these technologies. If the business changes, and the technology is no longer there... then what? It's expensive to change. Now we watch as NT 3.5, NT 4.0, and Windows 2000 are vanishing to XP. There are far more shops depending on these technologies. Frankly the attitude I'm seeing is "if I have to switch, I'm switching to Linux so this won't happen to me again."
... When I talked with a represanative in Microsoft's security group, they were using Linux internally. ... The begs the question about where would Microsoft be without OpenSource? (Guess you could steal it, but hey... wasn't that how GW-BASIC got started?)
There's the old argument of "if I need support or someone to sue, at least I have Microsoft" -- ask yourself this, when was the last time you got decent support from them? When you needed a new feature or reported a real defect, was it your business model or theirs which was given priority? And if you went to sue Microsoft, and were 100% in the right, given the deep pockets there... could you survive battle the court costs? With the source you can fix it or hire someone to fix it.
The fact of the matter is, business doesn't like to ride technology waves. They want something that gets the job done, works right, and is reliable and as maintanence free as possible. As long as Microsoft misses this point, they're going to alienate customers.
It still amazes me that even IE's about box reports that it stands on the shoulders of NCSA Mosaic.
I just left a company that did a "Peace, Love, and Integration" theme.
The "60's" theme sent the wrong message, especially internally.
Ever get the impression someone giving a marketing seminar just got around to watching Austin Powers?
My concern wasn't the fact that I had too much in a distribution, it was that I didn't know what I had or where anything was.
It would be really nice if along with a commercial distribution came a piece of paper which would list standard application categories such a Word Processors/Editors, MultiMedia, Spreadsheets, Online Help, Browsers, Chat Programs, Development, System Administration, etc. Then under each category list each software applications's name and purpose, how to invoke the program, where the documentation quick start is (info/man/howto), and if applicable where to get a printed resource like a book from O'Reilly. It would be important to notate whether the user would have to use X to run the application.
This list ought to come in printed format because new users may not know HTML, won't know how to invoke a browser, may not know how to type a file to the screen, and most certainly won't know how to print the information.
From this standpoint Linux distros do require you to have a base set of knowledge before you can gain more knowledge. I read this article as a cry to lower the barrier of entry for the uninitiated.
Remember, once people get a simple distro installed, it doesn't take long at all before the light comes on and they start craving everything. Perhaps that is how entry to the Linux desktop market should happen.
Clearly, mortal users do tolerate large multi-megabyte applications, however whether obtained separately or not isn't the point.
The start of the game involved getting a slew of cash, and then buying a bridge, which was constructed by hundreds of thousands of little dwarves in what could only be described as helicopters. You then crossed the bridge, climbed a mountain, went into an old house, and accessed other worlds by finding secret passages. The scoring system was as detailed and granular as the plot line. I found it far more fun and challenging than Zork.
Unfortunately, I think it was written for a Data General, and when The Source got purchased by Compuserve, the game vanished. The only proof I have is a few old dusty captures of the start of the game, combined with a piece of marketing literature that briefly mentions it.
I've searched all over the net for it, with the hopes of getting it ported to Linux, but have come up short. Anyone who might know where a copy hides, please feel free to contact me. I've tried all the text game archive sites I could get links to.
- Discussion
You may not discuss the contents of this book including, but not limited to classrooms, book clubs, and especially SlashDot.
- Location
You may not read this book on any form of public transportation, nor in any restroom.
The problem in cases of severe failure has been when quality wasn't enforced top-down from upper management. In other words, when the measure of quality was "did we ship on the planned date" the product suffered.
There seems to be an assumption that once the product is out, a company can cover their mistakes with patches and more releases.
To some extent this is true. The first person to market usually wins. But the catch, as shown by Open Source projects, is that the product has to work first. It doesn't need every flashy feature, it just needs to work. This is how you get an initial install base.
When I'm wearing a development hat, it's frustrating to see a date pushed down from marketing along with a list of requirements. Sadly, I haven't seen development shops asked for their input. After all, they know how long it usually takes to build something.
Tell us when you want it, we'll tell you how long it will take to put in each feature so things that would impede the date can be deferred to the next release. Tell us what you want, and we'll tell you when it should be ready.
Another major error is that organizations don't understand the roll of QA. Management views QA as fixing what's broken from development. QA is a house inspector, not a doctor. Developers look at QA as someone trying to break the product and make them look bad. QA's job is simply to assess the stability, functionality, and usability of the product so that management can evaluate the risk of shipping. Sometimes the right business decision is to let something ship with a flaw in it; other times it isn't.
In cases where management has lacked focus and not enforced a degree of quality, I've seen grass-roots movements establish themselves. Interestingly enough, this never works. Not once. Management holds the reins on schedule and budget, so killing unsanctioned quality-based movements is inevitable. The best scenario is perhaps educating upwards, however getting buy-in at all levels is nearly impossible. This means as an employe, you might want to add management's existing viewpoints into the factor of who you want to work for.
The choice between new-features and more-stability almost always falls on new-features, since that's where sales primarily come from. Those who don't understand the principles of software engineering almost always understand the value of a quick buck.
A small number of places I've been at have allowed for quality improvements. The result is always a happier customer base (who now wants upgrades), happier sales and training people -- since they can demo and have things work, and the big payoff is that due to refactoring and better stability it is possible to add new features in less time.
If there's any lesson to walk away with from all this, it's that you must plan for quality and the drive must come from the top down. It is much easier to design quality in than to sift defects out.
I wonder if the real difference between this example of a gentlemen's agreement versus other uglier disputes is just when a corporation actually has lawyers on staff.
For $279 you can buy an awful lot of cheap mice in the event one gets broken.
However, that isn't the point. And while many of the activities can be done without SS cards, money, etc. It could be a little tougher on the net to maintain its more unregulated state. I didn't say impossible, just tougher.
Frankly, I used to hold the exact same position articulated above... But Lawrence Lessig makes an excellent case in Code and Other Laws of Cyberspace [IBSN 046503912X ] about the implications government controled CAs have. I still thought there was no big deal until several chapters in, when I realized it wasn't the technical issues, but the legal issues. It gives the government a tool to put its cold grasp around things it can't get at right now.
Don't be so quick to dismiss the long term effects.
After that, it's just a matter of legislating that to provide certain services or present certain content you need a government certificate or you can't do business.
Is age discrimination the problem or just a symptom? I remember when programming was taught as more of an art, and the implementation language was fairly irrelevant. Good programmers could conserve space and increase speed by making smart data structures, wisely choosing algorithms, and optimizing implementations. Design and documentation were part of the development process, just as debugging and profiling were required skills. Tools were just that, tools. They helped the developer do his craft more efficiently and more accurately. However, our tools have become so easy almost anyone can use them and get something to happen. When interviewing, I see 'senior' people with 2 years of experience, usually all academic. Few candidates have impressive problem solving skills these days and instead depend on brute force and trial-and-error to produce solutions (most which need to be revisited). It frustrates me when a "C++ expert" doesn't know the language and can only program when there is a wizard writing the code and a drag'n'drop environment for prewritten components. Change the IDE and the programmer becomes helpless. While I'm not knocking reuse here, the barrier to learning a new language and using it effectively seems to be mentally digesting the colossal sized libraries. This is evident with Perl, Python, C++, Java, etc. They're not hard, it's just big. Given that there are so many languages cropping up, with so many libraries, not to mention the terminology changing, it can be difficult to keep up without an excessive effort. When faced with the economic decision between hiring a recent graduate who knows the libraries, but is weak in 'real' programming versus an experienced developer who's looking at retirement benefit packages and needs a month to ramp up... many companies are taking the cheaper route. Flash sells, and while the experienced programmer can write a device driver in half a week, the one that can get an IDE to crank out a quick GUI in 2 minutes wins. This makes as much sense as when companies in the early 80's laid off expensive development staff to replace them with kids based on their PacMan scores. Unfortunately, since speed and space conservation aren't taught as a way of life software consumers are left with bloated applications that run slowly and crash intermittently. Educational facilities aren't doing anyone a favor by producing a breed of programmers that require crutches to get by. Meanwhile, if the aging developer has the skill to write a coherent English sentence, they usually end up in the elephant graveyard of technical writing.
I guess the real question is did the advertising company pay Company X for the [partial] work it did. Either way, this sounds like it's their problem, not yours, as you were acting as an agent for the advertising agency.
Once precedence has been established, we could then request Microsoft to remove all Linux bashing comments from their sites.