All Posts in Business Ethics

|In: Business Ethics|Last Updated:

The U.S. system for issuing software patents is completely broken, and easily fixed.

The fix first: All Congress has to do is add these words to the existing body of patent legislation: Notwithstanding the above, no patents shall be issued for any software inventions and existing software patents shall be summarily revoked.

Disagree? Hold that thought.

Search for commentary on what’s broken about the software patent system and how to fix it and you’ll find no shortage (the best: Joel Spolsky’s “Victory Lap for Ask Patents,” Joel on Software 7/22/2013).

The widespread consensus is that the software patent system is broken.

Some numbers: The U.S. Patent and Trademark Office (PTO) receives about 40,000 new applications a year for software patents, swamping the ability of patent inspectors to separate the few grains of wheat from the abundant chaff. Because seriously, based on your knowledge, experience, and judgment, do you think there are 40,000 non-obvious ideas each year about something new and interesting that software can do? Me neither.

Take a SWAG for the time each patent application requires. Call it maybe 100 hours of total effort on the part of the software engineers responsible for these “inventions,” the attorneys responsible for shepherding them through the process, and the patent examiners who have to process them?

This is a very conservative estimate, and it means the filing process alone drains four million hours of work each year out of the economy on the part of people who have some smarts and talent to offer.

Add the cost of litigation. The courts process more than 4,000 infringement cases each year, which on average cost about $2 million to defend, and about half of which are for software patents. That’s $4 billion a year in direct costs spent defending against software patent infringement cases, not including the large but impossible-to-estimate opportunity cost of time and effort not available for innovation.

Is this crippling? No, if you think it’s mostly spent by the likes of IBM, Oracle, Apple, and Microsoft. Also no in the context of the amounts spent on research and development: $4 billion a year is about 1 percent of U.S. R&D spending.

But in the context of where software innovation comes from, $4 billion is a lot of money, because a lot of software innovation comes from small players that can’t afford to defend themselves against patent trolls, and instead choose the cheaper alternative of buying them off.

But never mind all that. To understand why Congress should abolish all software patents, we all need to recognize a major and widespread misunderstanding about the purpose of the whole patent system.

Blame the legal community. They’ve taught us to use phrases like “Intellectual Property” to describe what patents and copyrights are supposed to protect.

As Orwell pointed out, control vocabulary and you control thought. Patents and copyrights actually have nothing at all to do with property rights. Don’t believe me? Here are the exact words as they appear in Section 8 of the United States Constitution: The Congress shall have power … to promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries …

See the word “property”? Me neither. The purpose of having patents at all is to promote the progress of science (and, presumably, technology), not to protect property rights.

Look, more software innovation comes from the open source community these days than from anywhere else. The cloud relies heavily on open-source technologies. Nearly every new programming language that’s appeared in the last decade is open source. Most blogging is done using open-source toolkits.

And in open-source-land the only intellectual property protection software receives is protection from intellectual property protection.

It’s abundantly clear that the main impact patent protection has on software innovation is to stifle it.

The inference is inescapable. Software patents subvert the clear words of the Constitution — they are, in a word, unconstitutional.

Which in a better world would mean Congress wouldn’t even need to act, because the Supremes could take care of the whole problem in a single, easy-to-explain precedent.

Don’t hold your breath. Not because it’s unlikely, but because I’ve applied for a patent on breath-holding as a method for accelerating results.

You could defend yourself against the infringement suit I’ll otherwise file against you, but really, wouldn’t it be easier to just send me a check to make me go away?

* * *

Yes, I know. Unless you’re a member of Congress there’s nothing in here this week that’s of any practical value to you. Sorry. Next week for sure.

Comments

|In: Business Ethics|Last Updated:

“Competition keeps SaaS profits artificially low.”

Authors don’t write their own headlines, so don’t blame Kevin Kwang. Someone at ZDNet stuck this in front of his perfectly reasonable analysis of why so many SaaS vendors aren’t profitable.

Memo to headline-person: You have it backward. Lack of competition keeps profits artificially high. Markets are supposed to have it; thin margins are supposed to result.

In fact, if Kwang is to be believed, the SaaS marketplace exemplifies all that’s good and right about capitalism: Instead of harvesting profits, SaaS vendors are plowing them back into their services to make them more attractive, so as to gain marketshare, so as to either: (1) survive the inevitable marketplace consolidation; or (2) be acquired by a larger, more diversified player, to become part of their product portfolio, to survive the inevitable marketplace consolidation.

We management consultants understand these things.

We management consultants understand many things. Including, it appears, things we don’t understand at all.

My friend Jeevan Sivasubramaniam, executive managing editor at Berrett-Koehler, sent me a reproachful little book titled I’m Sorry I Broke Your Company: When Management Consultants Are the Problem, Not the Solution (Karen Phelan, 2013). It reinforces the old joke that the 90 percent who are bad ruin it for the rest of us.

Which is too bad. Not that the old joke is wrong. It’s that when management consulting engagements go wrong, it’s usually because of an unspoken conspiracy between the consultants and the person who brought them in — a point the book makes well, but that’s likely to get lost by skimmers who read nothing but the title and a few chapter heads.

So here, in my own disorganized way, are three random thoughts on the subject. Ms. Phelan and I mostly agree on them; they are, in any event, my own:

Don’t bring in a consultant to read a script. I’ve had this sort of engagement, not that I knew it when the client asked us in. If you know the right answer, but need an outside voice to explain it to your boss, the board of directors, the IT steering committee or what-have-you, you have a bigger problem than the need for an outside voice to explain it.

You have a credibility problem, and no outside consultant will fix that. My advice: Hire an actor to read the script for you. Actors come a lot cheaper than management consultants and reading scripts convincingly is their job.

Then hire a leadership coach to help you figure out how to fix your credibility problem.

Don’t bring in a consultant who promises measurable improvements. A subtlety here: Measurable improvements are fine. That isn’t the problem.

The problem happens when the management consultant tells you which measure or measures will improve. “We’ll cut waste,” is terrific, so long as you brought in a consultant to cut waste. If what you need is to improve your ability to deliver customized results, though, it isn’t so terrific, especially as many of the “improvements” consultants make to cut waste eliminate the ability to deliver customized results.

Even that isn’t the worst that can happen. I’ve seen process consultants “improve” a process by “discovering the pain points,” making changes and then discovering which measures improved. Whichever ones they were, they’ve delivered on their promise, never mind that other measures their client cared about more got worse.

Measurable improvements? They’re just fine. But deciding what “improve” means is your job. So is insisting you be informed of the trade-offs … of which measures will get worse as part of the process … in advance.

Bringing in a consultant isn’t a sign of weakness: As a manager at any level, you aren’t supposed to be an expert in everything. Sometimes, what the organization needs isn’t where you have your expertise.

For example: Many managers are excellent at operations … at getting the work out the door every day, making quotas, maintaining quality, keeping employees motivated and so on. Many of these managers aren’t all that good at making change happen, because (1) that isn’t their day-to-day job, and (2) making change happen in an organization is complicated.

When what the organization needs isn’t something you’re all that good at, asking for help is a sign of strength.

And oh, by the way: Sometimes, the hardest part is recognizing a need that’s very important but is also outside your repertoire. That just might be the best reason to bring in a consultant — to help you when the problem is that you don’t know what you don’t know.

Comments