It'll depend in part on how willing your employer is to negotiate those terms, and in part on what the law in your state is. For instance in California you have California Labor Code sections 2870-2872 governing IP agreements. That law trumps anything in the agreement. Since I live and work in CA, I make it a point to mark up any IP agreements with a note about those sections before signing it. You'll want to check the law in your state, depending on what it says you may have more leverage with your employer.
Why wouldn't anyone have expected the bad guys to do this? They've been doing it for decades already. Back when it was dial-up BBS systems, the bad guys had BBS networks of their own with download libraries full of code and discussion boards full of people discussing and refining their techniques and making their viruses better. As programming and development methodologies have evolved, why wouldn/t we expect programmers and developers on the bad side would adopt them just like any other programmers?
True, but then if I sell my copy of a book there's no guarantee I haven't photocopied it and kept the copy either.
Bear in mind that it's not so much an argument over whether MP3s should be treated as material objects or not. It's that the record companies want them treated as material objects for purposes of one section of copyright law (Section 106 covering distribution of copies) but treated as not being material objects for purposes of a different section (Section 109 covering sale of copies). The counterargument is that the record company can't have it both ways, and the judge agreed that if the record companies want it to be considered a copy then defendants are entitled to treat it as a copy even when the record companies would rather they didn't.
The question I'm asking myself right now, is this: Should I turn off my cell phone?
No. Find somewhere where it won't matter whether your cel phone's on or not, it doesn't have service. My definition of a good vacation spot is a beach somewhere down in southern Baja away from the tourists where the sand is warm, the beer is cold and getting a phone call through to me involves convincing the bartender to send his kid down to ask me to come up and talk to the loco gringos.
You want developers to document code? OK, a few simple steps:
Allocate time for documentation. Don't make it an extra step, make it an explicit task in the schedule with time assigned to it just like analysis, coding or testing.
Don't skimp on that allocated time. Don't expect the developer to be doing debugging or anything else during that time. Don't shave time off documentation to make up for delays elsewhere. You wanted documentation, let the developers work on it.
Give the developers help. Half of documentation is writing down the details. The other half is formatting and editing what they've written down into something clear, comprehensible and consistent from one set to the next. Developers know Visual Studio, they aren't experts on Word. They have templates for code, they don't have templates for Word documents. Find a couple of people who are experts on Word and assign them to work with the developers to help turn raw words into nicely-formatted real documents. Make it clear to both sides that, while they're not expected to become an expert in the other's area, they are expected to learn enough about it to help make things work.
Don't skimp on the developers and the formatters/editors learning what they need to learn. If the developer needs to take a couple days to work through that tutorial on Word templates and how to use them, don't gripe at them and keep asking them to work on other stuff instead of the tutorial. Ditto if the Word people need to actually do a basic programming tutorial. You wanted this done, let them learn what they need to learn.
Organize the documentation once it exists. Before you start, plan on creating a Web site or something to hold the documentation. Make it something that developers can actually search with a reasonable expectation of finding what they're looking for. A big folder full of files won't be any use, the only people who'll be able to find what they need are the ones who already know it. It should have a table-of-contents listing organized by module and component (so someone who only knows they want documentation on component X will immediately see the heading for it which'll bring up all the documents with descriptions of what they're about) and a searchable index (so people can enter keywords and get back a list of all documentation that talks about those keywords). Same thing for a nice documentation library that requires software that the developers don't have on their machines, or that presents things in a form they can't copy from or that won't adjust to let them see all the documentation and have Visual Studio running full-sized at the same time. Developers won't feel documentation's useful if they can't use it in their normal environment, and they won't feel motivated to produce it if they don't think it'll be useful.
You don't want to learn to code. You want to learn to program. Analogy: you don't want to learn how to nail 2x4s together, you want to learn how to be a carpenter. To be a programmer you need 4 things:
You need to know how to write code in the language you'll be using. That's the easy part.
You need to understand how to analyze the problem and frame the steps needed to solve it. This has nothing to do with writing code. It's also the hardest part to learn because it involves building up a vocabulary of ways to do things, a library of ways to apply those things to solving problems, and a knack for breaking large intractable problems down into a collection of simpler ones that can be solved and combining those solutions to solve the bigger problem. You need to become good at inductive logic to succeed at this.
You have to have a knack for seeing the right way to solve a problem. There's usually a lot of ways to solve any given problem, but some are more... elegant for lack of a clearer term. You can drive a screw in with a hammer quite successfully, you'll just need a very big hammer and hit the screw very very hard, and you'll do a lot of collateral damage in the process of succeeding. Or you can put down the hammer and rummage around in the toolbox until you come up with a screwdriver.
For large enterprise projects you also need a knack for stepping back from what you need to do right now and looking down the road at the kinds of things you'll need the software to do 5 years from now. Many programmers who manage the first 3 things never make the jump to this one.
The problem is that all but the first are things you won't learn in the simple "programming for dummies" courses.
Thing is, almost everybody's got what it takes to be a coder. But that's just a fraction of what it takes to be a programmer. Just like most people can nail 2x4s together but that's a far cry from being an architect or even a cabinet-maker. The rest can't be taught, it can only be learned. Most people are just unable or unwilling to learn it because learning it's work.
You can get a job as a software developer in the same sense as a lot of people could go through HTML For Dummies and get jobs as Web Developers. That's great when companies are hungry for anyone even minimally qualified, but it's not going to do much for keeping your job when they start having to actually work with and maintain your work product.
I think the argument that trade secrets are revealed because the employee's device is outside the company's control is somewhat invalid. The device may be outside the company's direct control, but technically so is the employee's brain and mouth. The employee, however, is within the company's control, thanks to the agreement the employee signed about how they'd handle the company's secrets. Since the employee's device is within the employee's control, and the employee's agreed to handle secrets in an appropriate way, the company's got sufficient indirect control to keep the secrets secret. If that weren't the case then telling the employee the secret in the first place would expose it, since the employee's mind isn't under the company's direct control and the only control exerted is the same agreement about how the employee will handle those secrets.
Cloud storage is another matter, but solving that will require a massive change in the law: making it so my e-mail is mine, period, and you can't serve a subpoena on the server operator to gain access to my e-mail, you have to serve the subpoena on me.
What kept me on XP so long? Two things. First, it works. It did everything I needed it to do, ran all the software I needed to run. I don't run an OS to use the OS, I use software and have an OS only because that software requires it. If the software I need to use is happy, I see no reason to disrupt things.
Second, I can't upgrade. Microsoft dropped the ability to upgrade an XP install to Win7, retaining all the installed software, settings and the like. That makes an upgrade hellishly complex, since I've got to dig out all the old install media, product keys and such and spend hours reinstalling everything. I've got to save data, write down settings, and remember all the stuff I need to make note of or save. And after the upgrade I have the headaches of finding all the things I didn't remember to save and have to dig up or recreate. It's about a week of work per PC to get everything dealt with and settled and working smoothly again. I do not want to go through that if I don't have to.
Actually XP needs one thing: solid 64-bit hardware support. It doesn't have it, the normal version is strictly 32-bit and the 64-bit version isn't compatible with a lot of 32-bit software and generally causes headaches. The big reason I have for moving to Win7 is solid 64-bit support. Given that, I don't plan on upgrading beyond Win7 for several years. I don't need to, Windows 8 isn't offering any features I need on a desktop and actually removes some I do need. Not going to fly here.
This isn't specific to the cloud. This is one of the risks when you put anything crucial to the existence of your business completely in the hands of a single other entity. It could be as basic as having a sole source for a part that you have to have available to manufacture your product. If that supplier goes out of business or discontinues that part, you're SOL. And since you don't have any control over them, you can't do anything about the situation. Your only recourse is what every businessman has known for centuries: make sure you always have more than one source for any critical supplies and items. That's also why businesses had warehouses, so if there was any interruption in their supply stream it wouldn't shut them down while they sorted out how to get their supplies and raw materials delivered. The cloud's just another case of this. If you base your entire business on a service provided by a single company, you're at the mercy of their business plan (or lack thereof). A smart businessman would insure he could get the same service from at least 2 sources, so if one of them shut down he'd still be in business and have time to figure out what to do next.
If they're truly anonymous, you may be out of luck. But if RR keeps logs, you can subpoena those logs to determine the IP address the post came from (and RR'll have a hard time fighting that subpoena if you're sensibly limiting it to the time of the posting and specifically requesting only the information related to that posting and not trying to fish for everything in their logs). From that you determine who owns that IP address and subpoena their subscriber records to determine which subscriber had that address at that time. The account-holder will either be the person responsible or it'll be someone in their household and they'll know who it is (the trick is to not claim they're the one that posted it, merely that they're responsible for that posting (their ISP's terms of service almost always include a clause holding the account-holder responsible for all material originating from their connection), which leaves them on the hook even if they can prove it wasn't them unless they can tell the court who did do it).
Yes, that's quite a bit of legwork for you to do. But that's the way it goes sometimes: the burden's on you to prove your accusations. If we expect eg. the record labels to do this work and target their copyright infringement suits correctly, we can't complain when we're expected to do exactly the same thing.
If you want to sue the author for defamation, you're going to have to do all the court filings anyway. And going after the author of the defamatory material is the proper way to do it. Going after RR without going after the author is an attempt to shortcut things and get the material removed without proving it's defamatory, which IMO is something the courts should shoot down on the spot.
What I'd do with that site is decline to "work with them". I'd file against the person who posted the false and defamatory information (using the proper legal tools to get their identity if they'd posted pseudonymously), get them into court and get a judgement against them including an order requiring them to remove the posting. If the site declined, I'd go back and ask the judge for a court order against them requiring them to comply with the poster's request. I'm in a much stronger position now, and I've a good argument for contempt of court if the site still refuses to comply with a lawful court order to cooperate.
I think it's basically this: it's not the poster suing RipoffReport. The poster may have a cause of action against RR for keeping the posting up, the company may have a cause of action against the poster if they don't do their best to have the post taken down, but the law bars the company from suing RR over someone else's material.
Actually there will be a do-or-die moment: the moment the first server I need to access only has an IPv6 address because the person who owns it doesn't want to pay the cost of an IPv4 address. At that moment I'll need to have IPv6 working. That point won't be under my control. Cost/benefit from my side won't matter. The only thing that'll be gradual is the number of things I need to have working that won't work at all. So better to be prepared now, so that when other people start deciding it's just too costly to get IPv4 addresses I'm not caught flat-footed.
Yep. Which is going to come back and bite them the day they don't have a choice, they have to have IPv6 turned on to talk to something they need to talk to. I'd rather find and fix the broken stuff over the next 6 months to a year, instead of a year from now when having it on's causing production outages and turning it off isn't possible.
See: flag day. Best avoided. You can't make the change simultaneously on every single computer connected to the Internet, and if you don't you're going to have random breakages from the point where you start until the point where the last computer's been patched. I'd rather not have frequent and unpredictable failures of the global Internet for 3-6 months.
No, I'm not a drama queen. I'm a paranoid bastard who makes Mad-Eye Moody look positively naively trusting. Which is another way of saying I've been through major infrastructure deployments before. I don't believe in Murphy, I'm on a first-name basis with the little toerag.
Making an IPv6 tunnel work, that's easy. The hard part's making it not work in the spots that need to not work without breaking what's supposed to work. If everything goes smoothly it'll be a piece of cake, and if I do it now it'll probably go smoothly. But if I wait until the last minute, 99 times out of a hundred it won't go smoothly. So I'll be paranoid and get it done now and be pleasantly surprised at the lack of problems, then kick back and relax with a bowl of popcorn while Murphy visits all the people who waited and zany hijinks ensue.
You're right about unused IPv4 space we can reclaim from people who aren't using those blocks. But multicast and class E? Trying to use those as unicast addresses would break most of the existing IP protocol stacks.
Me, I figure the gear will need to be replaced soon. There may be a question of whether it'll be next year or the year after, but I can see the writing on the wall now. Better to get everything started now when I don't have to rush.
When you get -40F winters and you know your furnace wasn't working as well as it ought to, you get it fixed during the summer or early fall when if it needs new parts it's no big deal if they take a week to arrive. You don't wait until it's 10 o'clock at night, the first blizzard of the winter's blowing outside and it's already below zero in the house and dropping fast to find out it'll be 5 days minimum to get the new motor in from the warehouse.
I'll be getting my network IPv6-ready now, thanks. I'll need to get a tunnel running to get connectivity, but I'll have a solid 6 months to a year to get all the bugs ironed out before I need to depend on it. That way I won't have to panic and rush if problems come up, and I won't be doing a mad scramble to get everything done as a hard deadline looms.
It's always easier and less disruptive to do something if, when something goes wrong, it can stay broken for a couple of weeks while I sort things out and it's no big deal.
From the point of view of a PR person, this isn't exactly wrong. Setting expectations and such is a key part of doing customer support, and if the customer gets incorrect ideas about what's going to happen, the support person should attempt to bring them around (i.e. control the situation, which is to some degree controlling the customer.)
That's not "controlling the customer", or even "controlling the situation". That's what we used to call "being clear and straight with the customer". And if they'd been that, the whole mess wouldnt've happened. If, when the delays happened, they'd've simply told customers what the problems were and what sort of delay customers could expect, the customer never would've been irate in the first place. The whole reason Mike was irate was because Paul was trying to conceal what was happening, convince Mike that things weren't as they really were, avoid discussing the actual problems and basically doing his best to not explain their side of things. That... never ends well.
I see this with software all the time. The company's behind schedule on a feature, having problems with it, and there's a huge outcry building as customers get angry as they ask when it's going to be available and don't get a straight answer. And finally at a public event someone paints a senior company rep into a corner and forces them to finally come out and say what's happening. And the company reps are always shocked when the expected explosion from the customers fails to happen. The overall reaction is "Well then, why didn't you just say that! We can live with the delay, we just didn't like being jerked around and led to think it'd be happening when it wouldn't.". I've also seen when the company does clearly say "We're having problems, we don't know how long it'll take to clear them up, we don't have a better idea of the release date, and we'll be making an announcement when we do have a solid release date for you.". There's always a few people screaming about it, but the majority reaction is "Knock it off, guys. They've told us what's up, yelling at them isn't going to make it happen any faster.". And yet, despite decades of track record on this, some marketing/PR guys still seem to think that you have to keep the customers in the dark to keep them on the hook.
Slashdot Mirror
It'll depend in part on how willing your employer is to negotiate those terms, and in part on what the law in your state is. For instance in California you have California Labor Code sections 2870-2872 governing IP agreements. That law trumps anything in the agreement. Since I live and work in CA, I make it a point to mark up any IP agreements with a note about those sections before signing it. You'll want to check the law in your state, depending on what it says you may have more leverage with your employer.
Why wouldn't anyone have expected the bad guys to do this? They've been doing it for decades already. Back when it was dial-up BBS systems, the bad guys had BBS networks of their own with download libraries full of code and discussion boards full of people discussing and refining their techniques and making their viruses better. As programming and development methodologies have evolved, why wouldn/t we expect programmers and developers on the bad side would adopt them just like any other programmers?
True, but then if I sell my copy of a book there's no guarantee I haven't photocopied it and kept the copy either.
Bear in mind that it's not so much an argument over whether MP3s should be treated as material objects or not. It's that the record companies want them treated as material objects for purposes of one section of copyright law (Section 106 covering distribution of copies) but treated as not being material objects for purposes of a different section (Section 109 covering sale of copies). The counterargument is that the record company can't have it both ways, and the judge agreed that if the record companies want it to be considered a copy then defendants are entitled to treat it as a copy even when the record companies would rather they didn't.
If they're doing that, why don't I just query the website directly using, oh, I don't know, their RSS feed?
Will it work:
If it can't, then we're going to be able to use it how again?
The question I'm asking myself right now, is this: Should I turn off my cell phone?
No. Find somewhere where it won't matter whether your cel phone's on or not, it doesn't have service. My definition of a good vacation spot is a beach somewhere down in southern Baja away from the tourists where the sand is warm, the beer is cold and getting a phone call through to me involves convincing the bartender to send his kid down to ask me to come up and talk to the loco gringos.
You want developers to document code? OK, a few simple steps:
You don't want to learn to code. You want to learn to program. Analogy: you don't want to learn how to nail 2x4s together, you want to learn how to be a carpenter. To be a programmer you need 4 things:
The problem is that all but the first are things you won't learn in the simple "programming for dummies" courses.
Thing is, almost everybody's got what it takes to be a coder. But that's just a fraction of what it takes to be a programmer. Just like most people can nail 2x4s together but that's a far cry from being an architect or even a cabinet-maker. The rest can't be taught, it can only be learned. Most people are just unable or unwilling to learn it because learning it's work.
You can get a job as a software developer in the same sense as a lot of people could go through HTML For Dummies and get jobs as Web Developers. That's great when companies are hungry for anyone even minimally qualified, but it's not going to do much for keeping your job when they start having to actually work with and maintain your work product.
I think the argument that trade secrets are revealed because the employee's device is outside the company's control is somewhat invalid. The device may be outside the company's direct control, but technically so is the employee's brain and mouth. The employee, however, is within the company's control, thanks to the agreement the employee signed about how they'd handle the company's secrets. Since the employee's device is within the employee's control, and the employee's agreed to handle secrets in an appropriate way, the company's got sufficient indirect control to keep the secrets secret. If that weren't the case then telling the employee the secret in the first place would expose it, since the employee's mind isn't under the company's direct control and the only control exerted is the same agreement about how the employee will handle those secrets.
Cloud storage is another matter, but solving that will require a massive change in the law: making it so my e-mail is mine, period, and you can't serve a subpoena on the server operator to gain access to my e-mail, you have to serve the subpoena on me.
What kept me on XP so long? Two things. First, it works. It did everything I needed it to do, ran all the software I needed to run. I don't run an OS to use the OS, I use software and have an OS only because that software requires it. If the software I need to use is happy, I see no reason to disrupt things.
Second, I can't upgrade. Microsoft dropped the ability to upgrade an XP install to Win7, retaining all the installed software, settings and the like. That makes an upgrade hellishly complex, since I've got to dig out all the old install media, product keys and such and spend hours reinstalling everything. I've got to save data, write down settings, and remember all the stuff I need to make note of or save. And after the upgrade I have the headaches of finding all the things I didn't remember to save and have to dig up or recreate. It's about a week of work per PC to get everything dealt with and settled and working smoothly again. I do not want to go through that if I don't have to.
Actually XP needs one thing: solid 64-bit hardware support. It doesn't have it, the normal version is strictly 32-bit and the 64-bit version isn't compatible with a lot of 32-bit software and generally causes headaches. The big reason I have for moving to Win7 is solid 64-bit support. Given that, I don't plan on upgrading beyond Win7 for several years. I don't need to, Windows 8 isn't offering any features I need on a desktop and actually removes some I do need. Not going to fly here.
This isn't specific to the cloud. This is one of the risks when you put anything crucial to the existence of your business completely in the hands of a single other entity. It could be as basic as having a sole source for a part that you have to have available to manufacture your product. If that supplier goes out of business or discontinues that part, you're SOL. And since you don't have any control over them, you can't do anything about the situation. Your only recourse is what every businessman has known for centuries: make sure you always have more than one source for any critical supplies and items. That's also why businesses had warehouses, so if there was any interruption in their supply stream it wouldn't shut them down while they sorted out how to get their supplies and raw materials delivered. The cloud's just another case of this. If you base your entire business on a service provided by a single company, you're at the mercy of their business plan (or lack thereof). A smart businessman would insure he could get the same service from at least 2 sources, so if one of them shut down he'd still be in business and have time to figure out what to do next.
If they're truly anonymous, you may be out of luck. But if RR keeps logs, you can subpoena those logs to determine the IP address the post came from (and RR'll have a hard time fighting that subpoena if you're sensibly limiting it to the time of the posting and specifically requesting only the information related to that posting and not trying to fish for everything in their logs). From that you determine who owns that IP address and subpoena their subscriber records to determine which subscriber had that address at that time. The account-holder will either be the person responsible or it'll be someone in their household and they'll know who it is (the trick is to not claim they're the one that posted it, merely that they're responsible for that posting (their ISP's terms of service almost always include a clause holding the account-holder responsible for all material originating from their connection), which leaves them on the hook even if they can prove it wasn't them unless they can tell the court who did do it).
Yes, that's quite a bit of legwork for you to do. But that's the way it goes sometimes: the burden's on you to prove your accusations. If we expect eg. the record labels to do this work and target their copyright infringement suits correctly, we can't complain when we're expected to do exactly the same thing.
If you want to sue the author for defamation, you're going to have to do all the court filings anyway. And going after the author of the defamatory material is the proper way to do it. Going after RR without going after the author is an attempt to shortcut things and get the material removed without proving it's defamatory, which IMO is something the courts should shoot down on the spot.
What I'd do with that site is decline to "work with them". I'd file against the person who posted the false and defamatory information (using the proper legal tools to get their identity if they'd posted pseudonymously), get them into court and get a judgement against them including an order requiring them to remove the posting. If the site declined, I'd go back and ask the judge for a court order against them requiring them to comply with the poster's request. I'm in a much stronger position now, and I've a good argument for contempt of court if the site still refuses to comply with a lawful court order to cooperate.
I think it's basically this: it's not the poster suing RipoffReport. The poster may have a cause of action against RR for keeping the posting up, the company may have a cause of action against the poster if they don't do their best to have the post taken down, but the law bars the company from suing RR over someone else's material.
Actually there will be a do-or-die moment: the moment the first server I need to access only has an IPv6 address because the person who owns it doesn't want to pay the cost of an IPv4 address. At that moment I'll need to have IPv6 working. That point won't be under my control. Cost/benefit from my side won't matter. The only thing that'll be gradual is the number of things I need to have working that won't work at all. So better to be prepared now, so that when other people start deciding it's just too costly to get IPv4 addresses I'm not caught flat-footed.
Yep. Which is going to come back and bite them the day they don't have a choice, they have to have IPv6 turned on to talk to something they need to talk to. I'd rather find and fix the broken stuff over the next 6 months to a year, instead of a year from now when having it on's causing production outages and turning it off isn't possible.
See: flag day. Best avoided. You can't make the change simultaneously on every single computer connected to the Internet, and if you don't you're going to have random breakages from the point where you start until the point where the last computer's been patched. I'd rather not have frequent and unpredictable failures of the global Internet for 3-6 months.
No, I'm not a drama queen. I'm a paranoid bastard who makes Mad-Eye Moody look positively naively trusting. Which is another way of saying I've been through major infrastructure deployments before. I don't believe in Murphy, I'm on a first-name basis with the little toerag.
Making an IPv6 tunnel work, that's easy. The hard part's making it not work in the spots that need to not work without breaking what's supposed to work. If everything goes smoothly it'll be a piece of cake, and if I do it now it'll probably go smoothly. But if I wait until the last minute, 99 times out of a hundred it won't go smoothly. So I'll be paranoid and get it done now and be pleasantly surprised at the lack of problems, then kick back and relax with a bowl of popcorn while Murphy visits all the people who waited and zany hijinks ensue.
You're right about unused IPv4 space we can reclaim from people who aren't using those blocks. But multicast and class E? Trying to use those as unicast addresses would break most of the existing IP protocol stacks.
Me, I figure the gear will need to be replaced soon. There may be a question of whether it'll be next year or the year after, but I can see the writing on the wall now. Better to get everything started now when I don't have to rush.
When you get -40F winters and you know your furnace wasn't working as well as it ought to, you get it fixed during the summer or early fall when if it needs new parts it's no big deal if they take a week to arrive. You don't wait until it's 10 o'clock at night, the first blizzard of the winter's blowing outside and it's already below zero in the house and dropping fast to find out it'll be 5 days minimum to get the new motor in from the warehouse.
I'll be getting my network IPv6-ready now, thanks. I'll need to get a tunnel running to get connectivity, but I'll have a solid 6 months to a year to get all the bugs ironed out before I need to depend on it. That way I won't have to panic and rush if problems come up, and I won't be doing a mad scramble to get everything done as a hard deadline looms.
It's always easier and less disruptive to do something if, when something goes wrong, it can stay broken for a couple of weeks while I sort things out and it's no big deal.
From the point of view of a PR person, this isn't exactly wrong. Setting expectations and such is a key part of doing customer support, and if the customer gets incorrect ideas about what's going to happen, the support person should attempt to bring them around (i.e. control the situation, which is to some degree controlling the customer.)
That's not "controlling the customer", or even "controlling the situation". That's what we used to call "being clear and straight with the customer". And if they'd been that, the whole mess wouldnt've happened. If, when the delays happened, they'd've simply told customers what the problems were and what sort of delay customers could expect, the customer never would've been irate in the first place. The whole reason Mike was irate was because Paul was trying to conceal what was happening, convince Mike that things weren't as they really were, avoid discussing the actual problems and basically doing his best to not explain their side of things. That... never ends well.
I see this with software all the time. The company's behind schedule on a feature, having problems with it, and there's a huge outcry building as customers get angry as they ask when it's going to be available and don't get a straight answer. And finally at a public event someone paints a senior company rep into a corner and forces them to finally come out and say what's happening. And the company reps are always shocked when the expected explosion from the customers fails to happen. The overall reaction is "Well then, why didn't you just say that! We can live with the delay, we just didn't like being jerked around and led to think it'd be happening when it wouldn't.". I've also seen when the company does clearly say "We're having problems, we don't know how long it'll take to clear them up, we don't have a better idea of the release date, and we'll be making an announcement when we do have a solid release date for you.". There's always a few people screaming about it, but the majority reaction is "Knock it off, guys. They've told us what's up, yelling at them isn't going to make it happen any faster.". And yet, despite decades of track record on this, some marketing/PR guys still seem to think that you have to keep the customers in the dark to keep them on the hook.