Ottawa’s Green Bin program is, if not exactly in full swing, then at least in semi-swing. There have been a few problems:
Well lo and behold, some smart cookies are capitalizing on this last issue and have formed a Green Bin cleaning company called Bin Aces Inc. They’ll come to your house or business with their magical cleaning truck and clean and disinfect your green bins, recycling bins and even garbage bins for a modest fee and on whatever schedule suits you best.
The coolest part of this company is that they are able to process and recycle the water they use for cleaning so that they can clean 200 bins using the same amount of water a regular joe would use to clean just two bins. They use only environmentally-friendly detergents and none of their waste water will contaminate our rivers, lakes or streams.
All cities with green bin programs have spawned these bin cleaning companies – not all of them are environmentally friendly and not all of their prices are this reasonable.
In the interests of full disclosure I should mention that while I’m not getting any benefits whatsoever from mentioning this company on my blog, the owners of Bin Aces are related to a co-worker of mine, which is how I heard about them.
I wanted to acknowledge them because I like to mention local, small business-owners – especially when they’re first starting out and they’re doing something interesting. Also, I don’t want to see the already beleaguered Green Bin program fizzle out because people will start to turn against their Green Bins when they’re no longer shiny-new and daisy-fresh…..which is likely to happen in the next six months.
So, while I know this is a very boring post for non-Ottawans, I’m hoping you’ll at least be amused over the fact that the capital city of Canada just recently got on board with a composting program – a good decade behind most other cities. Or, that you might be amused over the fact that Ottawa had about a thousand other cities from which to model a green bin program, and yet still managed to get so much of it screwed up.
Or, if you’re still bored, we can just talk about Paris some more.

A popular blog truncated its RSS feeds to boost site pageviews. It’s like last week, when The Atlantic changed to partial-content RSS feeds. And that was like every other week, when some publisher did something that some readers didn’t like to make a few more cents.
I dislike the intrusive advertising on Salon, so I don’t read Salon. I dislike Michael Arrington, so I never read anything on TechCrunch (even when they write about me or my products) and have taken technical measures to ensure that I never even land there accidentally and give them whatever tiny profit that one pageview is worth. I don’t like the timebombed, Unicode-breaking Clickability print-friendly view for New York Magazine, since I like reading NYMag-length pieces in Instapaper and Clickability doesn’t work well in it, so I just don’t read NYMag’s articles. I don’t like Ars Technica’s paginated articles, but since I don’t want to pay for a subscription, I just read every page separately, give them all of their separate-page ad views, and save each page to Instapaper if I want to read them that way.
One reaction I’ve never had is to think that I deserve anything from these publishers.
I see a staggering amount of entitlement every day in the form of arguments and blog posts like the latter.
We don’t deserve anything. Publishers can do whatever they want. If you don’t like it, don’t send them nasty emails or browse their sites with ad-blockers: just don’t support them. Don’t read their content, don’t link to them, and don’t talk about them. Since money’s not usually involved, vote with your attention and read elsewhere.
I want to start this article by saying that I’m bound by NDAs all over the place. The company that I work for, being partners with a variety of companies, has NDAs in place for each vendor that results in me being under an NDA as well. Thus, I’m not going to:
I’m bound by those NDAs in what I write on this blog – I attend partner briefing con-calls/presentations etc., periodically, and get told about upcoming features or more generally roadmaps going up to 2 years out. I’m involved in beta testing – version and feature – and I so I get to see things before a lot of other people. I also get to talk directly to product management at vendors too. So to any vendor reading this, I hope they’ll understand that I’ll still follow all your NDA processes.
Just because I’m bound by NDAs doesn’t mean I can’t talk about where I think they’re wrong.
There’s a growing chorus of “NDAs suck” at the moment, and I’m not laying claim to the idea of blogging about the suck-value of NDAs on my own. I’ve reached the point of wanting to blog about it based on the previous efforts of Grumpy Storage in “Show me the Money (Information)“, and more recently in Matthew Yeager’s “First, execute with urgency. The rest is commentary“. (Incidentally, that’s two people you really should be following on Twitter – ianhf and mpyeager respectively.)
Over at Grumpy Storage, Ian, as an end-customer, wrote:
I need electronic copies of any & all materials discussed or presented – no exceptions, without this I can’t use it as reference material in my internal strategy planning. If you hide behind “it’s beyond NDA”, or “NDA prohibits” then I’ll interpret that as “you don’t trust me personally or respect me professionally” and the relationship will be difficult from then on.
This is a pretty damning comment on Ian’s part, and realistically represents how a lot of customers feel about NDAs – and this may be the surprising part – how a lot of suppliers and system integrators feel about them too. (I think he’s wrong about where the trust issue lays, and I’ll get to that soon.)
Matthew drew up an excellent summary of how NDAs protect intent over execution, and some possible solutions to this, and I’d suggest you consider reading both Ian’s and Matthew’s articles in full before continuing with what I’m going to say.
My argument is that NDAs themselves don’t suck. However, I do feel that in the vast majority of instances in which NDAs are applied do, indeed suck.
Trusted partners/suppliers are often “piggy in the middle” when it comes to NDAs. Where we frequently add value is by being closely aligned to our customers (who we prefer to also call partners), working at understanding their business requirements and delivering solutions and information that are tailored to suit those requirements. We recognise that time is precious, attention is a currency, and that the work of IT managers and staff isn’t to be sold to by a business, but to deliver to the business. By having the time to work directly with businesses, we offer a value-add that bungee-vendor sales rarely if ever can. That’s why a lot of companies choose to work with integrators and suppliers rather than vendors directly. As such, perhaps more than end-customers, as an integrator I can look at the various information I know that are locked away under NDA and really, really regret that I can’t readily tell my customers to help them with their forward planning.
So in that sense, NDAs are a constant case of “Here’s some really good information! But. You. Can’t. Tell. Anyone.”
Now, my beef with NDAs is not that they exist – I’m a fierce proponent of intellectual property protection. My beef is in where NDAs are applied. Or perhaps to be more succinct – in the frequency with which NDAs are applied. It’s too often. It’s across the board on a range of things where it logically makes no sense, and it’s often for the wrong reasons.
Ian at Grumpy Storage sees NDAs as a trust issue. I agree, but I think he’s (understandably) missing where the trust-issue really exists. You see, in big companies – and most vendors fall into this category, few people have “authority”. In this case, by authority, I’m talking about authority to discuss information on unreleased products or features with non-employees. This goes to the heart of corporate secrecy, and if companies should understand anything by now it’s that social networking is eroding this. So it’s trust alright, but the trust issue is in companies mistrusting their staff to make sensible judgment calls, or mistrusting the market to such a degree that the wrong disclosure decisions are made.
Recently, a senior vendor employee told me the following in relation to consulting:
“giving away info” is exactly what consultants need to do — controversial, but effective
Here’s the rub: the same applies to most situations where NDAs are pulled out. That is, in places where information is currently bartered (“I’ll tell you, but only if you sign this document that says I can sue you if you tell anyone else”), it should be flowing freely. (Call it the next step in the Cluetrain Manifesto if you will.) This is something that’s imperative to turn around. It’s already important with this generation, but just think of how important it’s going to be in a business environment saturated with Gen-Y’ers, all whom thrive on interchange and connectivity. (I’ve not said it so succinctly before, but I think Gen-Y is going to cause one of the biggest upheavals ever experienced in business communications, practices and procedures.)
I’d wager that the following two reasons sum up most of the times that NDAs are waved around:
These, of course, are on top of the actual valid reasons why we have NDAs – to protect key components of intellectual property. However, those valid reasons are definitely in the minority. If a picture helps, I’d suggest the following breakdown is fairly indicative of why vendors ask people to sign NDAs:
The net result is that within the IT industry overall we’re awash with NDAs. It reminds me of the Great Loyalty Oath Crusade, from my favourite book, Catch-22:
Almost overnight the Glorious Loyalty Oath Crusade was in full flower, and Captain Black was enraptured to discover himself spearheading it. He had really hit on something. All the enlisted men and officers on combat duty had to sign a loyalty oath to get their map cases from the intelligence tent, a second loyalty oath to receive their flak suits and parachutes from the parachute tent, a third loyalty oath for Lieutenant Balkington, the motor vehicle officer, to be allowed to ride from the squadron to the airfield in one of the trucks. Every time they turned around there was another loyalty oath to be signed. They signed a loyalty oath to get their pay from the finance officer, to obtain their PX supplies, to have their hair cut by the Italian barbers. To Captain Black, every officer who supported his Glorious Loyalty Oath Crusade was a competitor, and he planned and plotted twenty-four hours a day to keep one step ahead. He would stand second to none in his devotion to country. When other officers had followed his urging and introduced loyalty oaths of their own, he went them one better by making every son of a bitch who came to his intelligence tent sign two loyalty oaths, then three, then four; then he introduced the pledge of allegiance, and after that “The Star-Spangled Banner,” one chorus, two choruses, three choruses, four choruses. Each time Captain Black forged ahead of his competitors, he swung upon them scornfully for their failure to follow his example. Each time they followed his example, he retreated with concern and racked his brain for some new stratagem that would enable him to turn upon them scornfully again.
Sometimes it seems we’re stuck in the middle of a Great NDA Crusade, and just like in Catch-22, we need a Major –– de Coverley, who can say:
“Gimme eat.”
Instead of eat, Corporal Snark gave Major –– de Coverley a loyalty oath to sign. Major –– de Coverley swept it away with mighty displeasure the moment he recognized what it was, his good eye flaring up blindingly with fiery disdain and his enormous old corrugated face darkening in mountainous wrath.
“Gimme eat, I said,” he ordered loudly in harsh tones that rumbled ominously through the silent tent like claps of distant thunder.
Corporal Snark turned pale and began to tremble. He glanced toward Milo pleadingly for guidance. For several terrible seconds there was not a sound. Then Milo nodded.
“Give him eat,” he said.
Corporal Snark began giving Major –– de Coverley eat. Major –– de Coverley turned from the counter with his tray full and came to a stop. His eyes fell on the groups of other officers gazing at him in mute appeal, and, with righteous belligerence, he roared:
“Give everybody eat!”
“Give everybody eat!” Milo echoed with joyful relief, and the Glorious Loyalty Oath Crusade came to an end.
(Catch-22, ISBN 978-0-999-47046-5, Joseph Heller, First Published in Great Britain in 1962. Thanks also to The Sheila Variations website, that saved me from retyping those sections by having already quoted them.)
I want a vendor who will be the Major –– de Coverley of the industry. A vendor who will stand up and say “enough is enough” to frivolous NDAs that do nothing more than stifle discussion.
I’m not calling for an end to NDAs. There are some NDAs that should be preserved. For instance, I’d never argue for the cessation of NDAs when it comes to alpha/beta testing. I’d also suggest that long term forecasts should fall under the realm of NDAs too. (That’s two examples of where the “20%” or so that I estimate of NDAs that are valid come from.)
But what’s long term? That’s a year out, at least. Within that time frame? You should be confident enough in your development programme that you can talk about it to everyone, not just people under NDA. Hell, even if you want to bring this back to only six months, there should be a “forward looking” period that vendors are comfortable talking about without NDA shields. After all, let’s face it: everything published under an NDA still starts with various comments such as:
The items discussed in this document contain forward-looking statements that reflect … blah blah blah … it is our aim to get there … blah blah blah … but don’t hold us to anything if we don’t get there.
So it’s not as if the information discussed in NDAs is so rock solid that you can take bets on it anyway! So then … make those same caveats then pull out the useful information about upcoming features!
For information about features and products that are going to come out within 6-12 months, there’s no point for that to be under NDA. In fact, it does more harm than good, especially when you’re talking to a company that wants to buy something, but needs to know where it’s heading. It leads to situations where products are say, disqualified for consideration because they don’t have a feature yet, but because it’s so tightly bound up in an NDA, even though it will be available by the time the purchase decision is made, the message doesn’t get heard.
I know there’s the argument that new features, or perhaps more importantly, upcoming features, need to be protected from competitors. Does anyone seriously think NDAs shield anyone from this? Employees routinely shift from vendor to vendor, and while they’re usually under non-compete clauses, and clauses that restrain them from discussing products and features they were working on, those clauses only last so long – in most cases seemingly limited to 12 weeks or so. In short – if vendor A wants to know what vendor B is up to, they poach staff, or watch who they’re purchasing and make educated guesses.
Not only that, every vendor that has a clue has fairly heavily populated product development strategies ranging from 6 months to 2 years out, and just hearing that someone is going to implement some technology doesn’t mean that a competitor can instantly slot in development resources immediately on it in order to ape that functionality too. (Assuming they don’t already have the technology – it can be a case of “catch up” sometimes.)
So, would much change under reduced disclosure via NDAs? It seems bloody unlikely.
“Ah“, some would say, “It’s not just the competitors. It’s also the risk of being sued by a company if they purchase X on the basis of us implementing some feature A that we’ve talked about, but for some reason we don’t get around to it in the specified timeframe.”
“Um, so what?” would be my response to this. There’s two very important rejoinders to the above arguments:
“Ah“, some would say, “Then there’s stymieing by proxy – even if competitors don’t intend to implement the same thing we’re doing, they’ll just talk about doing it to convince people to stick with them, or buy them instead.”
To this I would say: Companies that repeatedly talk about products or features they then don’t go on to release in time (or at all) quickly get a reputation for vaporware. So don’t get too hung up about that – the market usually deals with vaporware vendors very efficiently.
“Ah“, some would say, “But what about the Osbourne Effect?” To this I’d say that particularly with mature product ranges, there shouldn’t regularly be an upcoming update that’s so earth shattering that it would cause someone to hold off buying until that is released. If someone needs a backup product now, or an array now, or a tape library now, they won’t keep on indefinitely putting it off just because there’s bigger and better things around the corner. Guess what? We’re all in IT here –– we all know that products have a fairly defined ride between superiority, regularity and obsolescence. Or as the old saying goes: if you keep waiting for the best computer to be released before you buy, you’ll never buy a computer.
In situations where there’s potential upheaval, have a clear upgrade strategy that clearly states and amortizes the cost appropriately – most companies will thank you. On the other hand, what they won’t thank you for is a situation where they buy a product from you that gets end of lifed or shelved shortly thereafter without any advance warning or clear roadmap of a way forward. I’ve seen multiple instances where vendors have permanently soured relationships with managers at customer sites. This makes the technical person at the site that recommended the purchase look bad, or worry about looking bad. And it also makes the manager who authorised the purchase worry that they “look bad”. Such issues don’t remain at that customer site – unresolved failures in customer satisfaction roll forward into every site that a person moves on to. Trust me – I’ve seen it, I know managers who refuse to buy products from vendor X for exactly that reason, and they’ve carried it through as policy on sites they’ve moved on to.
Being upfront on the other hand encourages customers to believe you have their best interest at heart. For instance, companies are still happily buying LTO-4 tape libraries, particularly from vendors offering free LTO-5 drive swap-ins, or even in situations where they know there’ll be a (relatively) small fee.
What we need is for the vendors to start to frankly evaluate where they’re slapping NDAs about. Sometimes it’s like navigating through a sea of pamphlet wielders at a train station – or a voting booth.
Come on vendors – reappraise where and how frequently you’re throwing NDAs around and prove to us that you actually live in the same information-rich world that you want to supply products to. Tone the NDAs down and use them appropriately, and use them sparingly. If you want another analogy – it’s becoming a bit too “boy who cried wolf”, quite frankly.
I had been taught in school that scurvy had been conquered in 1747, when the Scottish physician James Lind proved in one of the first controlled medical experiments that citrus fruits were an effective cure for the disease. From that point on, we were told, the Royal Navy had required a daily dose of lime juice to be mixed in with sailors' grog, and scurvy ceased to be a problem on long ocean voyages.But here was a Royal Navy surgeon in 1911 apparently ignorant of what caused the disease, or how to cure it. Somehow a highly-trained group of scientists at the start of the 20th century knew less about scurvy than the average sea captain in Napoleonic times. Scott left a base abundantly stocked with fresh meat, fruits, apples, and lime juice, and headed out on the ice for five months with no protection against scurvy, all the while confident he was not at risk. What happened? [...]
In the second half of the nineteenth century, the cure for scurvy was lost. The story of how this happened is a striking demonstration of the problem of induction, and how progress in one field of study can lead to unintended steps backward in another.
An unfortunate series of accidents conspired with advances in technology to discredit the cure for scurvy. What had been a simple dietary deficiency became a subtle and unpredictable disease that could strike without warning. Over the course of fifty years, scurvy would return to torment not just Polar explorers, but thousands of infants born into wealthy European and American homes. And it would only be through blind luck that the actual cause of scurvy would be rediscovered, and vitamin C finally isolated, in 1932.
...or something. I didn't watch -- I was sick.
StayClassy discusses how the NHL could learn from the Olympics. I'm going to cherry-pick his list:Blogger Mark Underwood lays out the ways you can use SNMP agents to monitor network devices, and even set it up to send software alerts as well.
—————————————————————————————
Out there, working for you, are agents. Feed them a little port UDP/161,162 and they’ll deliver a dossier on many network devices, in the form of a Management Information Base (MIB).
Just got hired after the last network administrator got promoted to CIO? Grab a free network management tool that has an SNMP (Simple Network Management Protocol) agent listener (SpiceWorks, Net-SNMP, NetXMS, Nagios, Zenoss and many more), then head over to the local Wi-Fi-enabled coffee establishment. Chances are good you’ll have charts and diagrams to visualize what you’ve gotten yourself into.
Here’s a list of pros and cons for using SNMP agents, which I’ll discuss in more detail below.
Pros
Cons
The basic notion of SNMP is that of an agent-based notification system. Each device, even many low level switches and printers, is equipped with an agent ready to do your bidding. The notification, or “trap,” can be generated by an agent developed by the device manufacturer, or listener software can monitor systems for specific events, such as particular items of interest in an event log, and send traps to an SNMP trap handler or other network management tool.
SNMP can be thought of as one framework within a number of overlapping frameworks that include Microsoft Windows Management Instrumentation (WMI), the Web Based Enterprise Management (WEBM) and the Common Information Model (CIM). CIM has evolved into an entire object model that DMTF describes using graphical language taken from the Unified Modeling Language (UML).
Microsoft has fully embraced the CIM model in WMI. For example, open a command window on many Vista, Windows 7, or Server 2008 machines and type:
winrm enumerate wmicimv2/Win32_ComputerSystem
The tool will list a machine’s basic hardware information such as the motherboard manufacturer, but also Domain membership, status of the administrative password, server roles, current user name, machine name, boot options, and more. Using WMI, you can deck out the walls of your cubicle with ample justification for upgrading the server farm. Figure A shows such SNMP-enabled charts. Similar monitoring capabilities are available for Linux. For instance, the free WebNMS product implements an SNMP agent but also offers management through HTTP.
The hurried and harried network administrator would be right to question how much effort to put into studying SNMP and related topics. The Distributed Management Task Force (DMTF), primary custodian of knowledge about SNMP and related topics, insists that its tutorial documents are suitable for “management application developers, instrumentation developers, information technology managers and system administrators.” That may be over-reaching. Scott Neumann of the CIM Road Map Task Force describes CIM as “the most developed and widely accepted model for describing an electrical network.” That said, the subject is as deep and as complex as big or heterogeneous networks can get.
Here’s where the fun begins. SNMP agents are not only for physical gadgetry. For instance, Oracle Enterprise Manager (OEM) can be tweaked to respond to alerts from Oracle VM, Oracle Database, or Fusion Middleware. The use case Oracle offers is its Contact Center Anywhere (CCA) application. Oracle walks prospective SNMP users through useful telephony-related traps, but also straightforward problems such as software license failures, “Malicious Call Trace,” Automated Call Distribution Voice Mail, etc. These examples show how an application could be engineered to help managers understand its performance, to automatically escalate certain conditions, or to implement enterprise-specific workflow. These could result in exciting improvements in the way software is designed.
Be advised that there is risk in this Spy-vs-Spy world. SNMP’s original designers were a trusting lot, and security seemed to have taken a back seat to disclosure. SNMP “community strings” function as passwords between the manager and the agent. The community string appears in every packet sent between them. Don’t risk having your SNMP agents become double agents. Don’t accept the default values of “public” or “private” for community strings. “Private” is especially problematic as it may permit an attacker to modify a device’s configuration. When it makes sense to do so, and when the device allows it, limit which IP’s are permitted to access SNMP agents. While not all network devices support it, SNMP Version 3 features improved agent encryption, which reduces the risk of man-in the-middle network attacks that could not only discover how to get out of your DMZ but could potentially reconfigure devices.
A comprehensive buying guide is beyond the scope of this brief post, but here are a few important tips to get you started:
Recommended readings