Category: Technology
When I saw this a few minutes ago as I trolled through my daily folder, I thought of an email I got yesterday titled “turtles all the way down” that referred to an article yesterday on TechDirt titled What If The Very Theory That Underlies Why We Need Patents Is Wrong? The article discusses a new paper out by my MIT advisor Eric von Hippel and his Harvard Business School colleague Carliss Y. Baldwin titled Modeling a Paradigm Shift: From Producer Innovation to User and Open Collaborative Innovation.
I expect this to be a key paper cited in the ongoing debate about software patents (and patents in general). Anyone in the software industry will quickly understand this paper and the massive shift we’ve seen from a “producer innovation model” to a “open single user and open collaborative initiative model” of innovation.
In the mean time, here are the butterflies.
What do you think this is? I’ll give you a hint – the little white line in the left corner is a scale that represents 5,000 km.
To start off the Learning to Program series with Nate Abbott and Natty Zola from Everlater, I asked them the simple question “What Was Day 1 Like?” Nate responded first:
Day one was totally overwhelming. Overwhelming because we didn’t know what we didn’t know. It’s one thing when you don’t know how to do something (e.g., validate email addresses or change a button’s hover state). But we didn’t know what we needed to learn, and that made it difficult to even start down a path. The first week was spent just googling "web site design", "web site architecture" and "web server" to try to get a handle on all of the acronyms we were coming across (such as CSS, HTML PHP MYSQL, ROR, JS, AJAX). Our goal was to piece together the list of skills that we were going to collectively learn in order to create a web service like Everlater.
Day one was also thrilling and exciting. It’s the same feeling I get when I’m starting a long bike ride in the mountains, the same feeling I got when I first got to college, or when I got my first offer letter for ibanking in New York. To me, there’s nothing more exciting than beginning a large task, and nothing I had done was quite like the task at hand.
Natty responded shortly there after with a few things to add:
We also researched sites we liked and benchmarked what they were doing/using to get a feel for what the popular/hot sites were using. Most notably I remember looking at Facebook and seeing .php at the end of the url string. This gave us ideas of where we should start our research.
I was excited like Nate, but also somewhat afraid. We quickly realized we were going to be learning another language, but much harder than a foreign language because we couldn’t rely on familiarities like verbs, nouns, and sentence structure. Worse, we would have to learn the basics of speech in becoming functional at the command line, databases, and editing programs.
The other interesting thing was that before we put any code down or started day 1 of our idea, we had spent a month brainstorming what we wanted to build. While this was pre-day 1 it enabled us to focus on making code/tech decisions and learning the code rather than also having to think about what we were doing with it. I think this sped our research because we had a framework within which to think about the decisions we were making.
Lastly, it really helped to research with Nate because we could bounce ideas around, problem solve, and challenge each other. Plus, it made it significantly more fun knowing we were diving into the unknown together.
To summarize. They were simultaneously overwhelmed and excited. But fearless – they just jumped into the swimming pool off of the high dive and hoped there was water in the pool.
Yesterday I published one of Sawyer’s posts titled Why the Decks are Stacked Against Software Startups in Patent Litigation. In it, I realized that Sawyer hadn’t defined the different types of plaintiffs in a patent case. Below are good definitions (from Sawyer) of each type and clear explanations about what you are up against in each one.
If you’re sued in a software patent case, the first thing you should do is figure out what kind of plaintiff you’re up against, because that will have a major impact on your negotiation posture, and you will almost surely want to settle out sooner rather than later.
One important prefatory note has to do with contingent fee arrangements. Most software patent plaintiffs hire their lawyers on contingent fee. Depending on the state, the contingency can be anywhere from 30-40% of the final dollar amount exchanged between the parties, and it’s usually taken off the top. This arrangement gives the lawyers powerful incentives to (1) push the case toward its maximal outcome and (2) not do any work on the case if they don’t have to. So, if you think you have a contingent fee suit on your hands, know that you’re not just negotiating with the other side, but also with the lawyers who, both in front and behind the scenes, may be trying to undermine a resolution that they don’t feel is significant enough financially.
Now, here’s my non-exhaustive classification of types of software patent plaintiffs:
The active competitor: These are the IBMs and Apples of the world, the active, money-making companies that get patents and sue their competitors for market advantage. Competitor cases are usually not on contingent fee because the plaintiff doesn’t want money, it wants a more intangible advantage in the marketplace. Between big players, these cases are often settled in cross-license arrangements, but one can imagine cases like Apple v. HTC being taken straight to trial because the plaintiff wants nothing more than to wipe out or diminish the defendant.
The defunct competitor or pseudo-competitor: Many startups in the dot-com era filed for and got patents on things that we now would consider silly or obvious. As those companies went under, or go under now, the entity that ends up with the companies’ assets seeks to monetize whatever is left, which usually ends up being the patents. These companies morph from going concerns creating stuff to pure licensing entities that proceed to sue every player in a particular market sector. These case are often on contingency because the plaintiffs can’t pay hourly. Settlement strategies vary widely in these kinds of cases, but usually the plaintiff will be incentivized to push every suit to its rational limit unless someone comes along to vigorously defend against the patents. These, in my experience, are the cases startups get caught up in the most, because the plaintiff doesn’t want to sue big players who can defend themselves (the patents are usually pretty bad), and so decides to extract as much value out of small companies in a particular sector as it can.
The “small fry” troll: Here’s the strategy – I have a patent, and I want to collect money to fund some serious suits against big players. What I do is find dozens of small companies (and by small I mean even made up of two people) and I sue them all in one suit, or several suits. I have my lawyer play “nice guy” and offer to settle each plaintiff out for anywhere from $30k-100k, depending on company size. At the end of the day, I’ve collected several million dollars and I can roll that money into suits against the big companies. The reason the defendants settle is that they can’t afford to litigate the case out for a few months, let alone to trial, so they’re stuck and have to pay something. I won’t call it extortion, but I guess I just did. These cases are also sometimes on contingency, but the plaintiff usually hires very inexpensive counsel, with no intention of litigating the case, and those lawyers are fine with the relatively small payouts they get from small settlements.
The fund troll: Many patent suits these days are backed, if you can figure out who the backers are, by specialized funds. These are “venture funds” that collect money from LPs like traditional investment banks and use that money to identify and buy promising patents and set up/manage litigation against significant players to “make” the fund. These cases are sometimes on contingency, and usually on partial contingency with capped fees (half of fees paid, with a 15-17% contingency). The guys running these suits from the funds are usually very sophisticated, and have very specific ways of evaluating cases and deciding settlement amounts. They usually won’t sue anyone too small to defend themselves, because it doesn’t make financial sense. They also don’t let their lawyers influence settlement discussions. In my experience, they are the most reasonable people to deal with in settlement, but at the end of the day you’re still paying the toll.
The “big fish” troll: Sometimes there are software patents out there that have no good invalidity defenses, and where infringement by major players is very likely. These are the holy grail for plaintiffs: big, valuable, winnable cases. The number of firms who handle these types of cases is very small, and one in particular has been racking up huge wins down in Texas for a few years now, especially the past year or two. The plaintiff could be a specialized fund, or just an individual inventor; regardless, the plaintiff and the lawyers are perfectly aligned in wanting to litigate the case through trial. If you see one of these firms, it’s a signal that they did their homework and think they have a very good shot at winning several hundred million dollars against some major player in the case. The chances of settling these types of cases for anything less than eight figures is basically nil. If you’re ever on the other side of a case like this, be afraid.
There are other “types” of software patent plaintiffs, but I think they draw characteristics from the types above. The key takeaways, I think, are (1) that as a defendant, you’re negotiating both with the plaintiff and with the lawyers and (2) the suits aren’t usually filed by “real” businesses, so it’s generally hard to reach fair business-driven settlements. Favorable settlements tend to happen only when a defendant is prepared to litigate a case to the end, and in discovery produces some very solid prior art and information on good non-infringement defenses. This ends up being a function of the ability of the defendant to pay its own legal fees, so at the end of the day, settlements are based much more on the ability of the defendant to pay than the merits of the case.
Why the Decks are Stacked Against Software Startups in Patent Litigation
The conventional wisdom has long been that software startups benefit from patents. I’ve been investing in software / Internet companies for over 16 years and I’ve never once had a patent influence my investment decision. More importantly, since it takes a number of years to get a patent, most startups haven’t even contemplated applying for a patent when they raise their first angel or venture round. Our friend Sawyer has seen this first hand and has some specific thoughts on what they decks are stacked against software startups in patent litigation.
Software startups are particularly vulnerable to patent suits, and often are in jeopardy of losing their businesses entirely after being sued. I think it’s important for everyone to understand the dynamics involved, because knowing why and how startups can be sued into oblivion will give you a new appreciation for the problems in the patent system.
A typical one patent case costs approximately $5 million to litigate through the end of trial, according to data that isn’t available online for some reason (the lack of pricing transparency in attorneys’ fees is a topic for another time). Costs vary wildly depending on where the case is, how complicated the technology is, who the firm involved is, etc, but $5 million is a decent estimate all-in-all.
I’m sure you can already see the problem. What software startup has $5 million to burn on defending a case with no value-add? Even $500k? I’d say it takes $1-2 million or thereabouts just to get through claim construction, which will give the parties a better sense of the overall merits of the case. One patent suit with a slightly determined plaintiff could very easily end a software startup just in legal fees, let alone the impact of the suit on gathering customers in the future.
So, software startups have to settle patent cases very early, and at high settlement amounts, because they have absolutely no leverage. Invalidity takes years to litigate, so you can’t threaten to invalidate the patent; same with inequitable conduct. Non-infringement arguments are great in theory, but the plaintiff won’t have a judgment day until the middle of the case at the earliest, after claim construction, when summary judgment motions are allowed (on most schedules), and that’s several years of litigation and several million dollars away. The defendant could file for a re-exam, but once it’s filed, the defendant has no control over it, and it takes a few years to get through the PTO.
Software startups sometimes have other leverage points, like the value of publicly shaming the plaintiffs, but when software patent NPEs are backed by investment funds through seven layers of corporate shell companies, or are dead companies with nothing to lose, who can you shame? And does anyone particularly care? The average person thinks patents are property (not entirely true) and a “great thing” for the economy; heck, our elected representatives say the same thing all the time.
The bottom line is that, in a world where a few million dollars and several months of work can build a promising software business, albeit one without serious cashflow, a patent suit can stop progress and kill those companies very quickly.
Luckily, perhaps, plaintiffs want money, and so in most cases it’s not worth it for them to sue a company with no revenue. But sometimes it happens, and it seems to be happening now with more frequency.
Startups can and do usually settle these cases, it’s just that the amounts paid aren’t particularly fair or a reflection of the value of the patents (generally nil); rather, it’s a reflection of a patent litigation system that only allows the huge players to defend themselves. Everyone else? Well, they’re kind of screwed.
In the last few days there have been a large number of posts about two platform companies – Apple and Twitter. These posts covered a wide range of perspectives (a few of the better ones are linked to below) but fundamentally came down to the tension between a platform (e.g. the iPhone OS or Twitter) vs. third party developers that build applications on top of the platforms.
Several of the Twitter related posts include The Twitter Platform’s Inflection Point, Twitter and third-party Twitter developers, and Developers In Denial: The Seesmic Case Study. Several of the Apple related posts ones include and Adobe Vs. Apple War Generates Rage, Facebook Group, Why Apple Changed Section 3.3.1, Steve Jobs response on section 3.3.1. If you missed the leads to the story, Apple made a major change in their TOS and Twitter launched an official Blackberry client and acquired the Tweetie iPhone client, rattling their developer community. And Twitter Officially Responds To Developers and Tries To Calm Fears.
While there has been an amazing outburst of reaction – including much surprise and criticism – to both of these situations, they should come as no surprise to anyone that has been in the computer business for a long time. What we are experiencing is the natural evolutionary struggle that exists between a platform and its developers. In the past few years, both Twitter and Apple have created amazing platforms and build incredible network effects on top of their platforms. One way they have done this is to embrace developers, who have flocked to these platforms in droves, building a huge variety of awesome, great, good, mediocre, and crummy products on top of the platforms. Some of these products have created meaningful revenue for the developers, others have generated fame, and many have generated a giant time sink of work that hasn’t resulted in much. This is the nature of being a developer on top of a platform.
True platforms are special things that are rare. Fortunately, developers have a lot of choices and that is a powerful dynamic that keeps both the platforms and developers evolving. I think the next few months are going to be pretty exciting ones as the current phase we are in sorts itself out.
I had lunch today with Nate Abbott and Natty Zola, the co-founders of Everlater, a TechStars 2009 company. Nate and Natty are two of my favorites – not only because they regularly kick my partner Seth Levine’s ass on bike rides but also because they starred in last year’s TechStars The Founders video series.
Today, while enjoying a veggie burger at Mustard’s Last Stand, we talked about how Nate and Natty learned to program. When they came up with the idea for Everlater, they were both young finance geeks on wall street. Nate was a math major; Natty was a econ major, but neither had a clue how to build a web app. They decided that rather than find a “developer” to team up with, they would learn how to program.
I regularly get asked questions (via email, face to face, and this blog) by non-technical entrepreneurs how they should get started if they don’t have a technical co-founder. There are a variety of answers – one is “learn to program.” In Nate and Natty’s case it’s worked out great and their story is an instructive one. So we’ve decided to work on a series of blog posts together about their story of how they learned to program, the resources they used, decisions they made, struggles they had, and beer they drank (well – maybe not the beer).
Now, both Nate and Natty are smart, which is obviously a pre-requisite. But neither were computer science majors, nor were they “hackers” (although apparently Nate is pretty good at a wide range of video games.)
Look for some posts over the next few weeks on this topic. Of course, like any of the series I’ve written, your feedback matters a lot to how much I keep it going. If you decide that the story is great and/or helpful, tell us and we’ll keep it going. If not, we won’t.
I hate spam. Over the years I’ve been an investor in a number of companies that address the spam problem, including Postini and Return Path. I’ve also been involved in lots of other companies in the email ecosystem and spam has always been something I’ve paid close attention to.
I’ve thought hard about Blam (Blog Spam), Spim (IM Spam), Skam (Skype Spam), and SMam (SMS Spam). A few times in the past I’ve thought about Twam (Twitter Spam) but Twitter has done a good job so far of dealing with most of the nasty stuff, the most visible being the porn-follower twam that they somehow managed to beat back (or that I’ve successful ignored).
Today, I got caught in a twam trap. I got a note from someone to try out a service. It’s someone I’d heard from before so I went to the new site and played around with it. I wasn’t terribly impressed and didn’t really get it. A few minutes later I got a DM from a friend that said “@bfeld none of the links on that page are active, fyi. tried Chromium + Safari”
I didn’t know why my friend was tweeting me that, but then it occurred to me that playing around with the software must have sent out a tweet. I took a look and lo and behold it did. I didn’t want that, nor did I set it up. But it did. Yuck.
Automatic tweeting from within applications is becoming commonplace. This is good in many cases, but unless the sender authorizes the actual tweet, it’s twam. There’s no opt-in dynamic around twam, so before a service sends out a tweet for the first time, it seems like good form is to make sure the user wants to tweet. Most, but not all, do.
When you develop a twitter integration, think this through. Don’t be a twammer.
On March 8, 2010 Amazon fired me as an Amazon Affiliate because of Colorado HB 10-1193. I proceeded to have a dozen different conversations (email and live) with several of my state representatives, including one of the co-sponsors of the bill, and each conversation made me more incensed at the abject stupidity and lack of understanding of the dynamics surrounding the situation. Ultimately, the argument came down to one of protectionism – e.g. “we have to protect our local merchants so Amazon shouldn’t get an unfair advantage by not having to charge state tax.” I could rant about this for a while, but I’ve got better things to spend my time on at this point.
I’ve been an early Viglink user for a while. Niel Robertson, the CEO of Trada, introduced me to Viglink’s founder Oliver Roup and I agreed to be an alpha tester. While we aren’t an investor, I’m intrigued with what Viglink is doing and I’m already a big fan.
Last week I realized that all of my going forward Amazon links (and other links to merchants with an affiliate program) were getting rewritten by Viglink. As a result, on a going forward basis, I was getting Amazon affiliate revenue (via Viglink) for anyone that clicked through one of my links and bought something on Amazon.
That was cool, but I have a gillion of old links using my Amazon affiliate code that no longer works. I asked Oliver if he could rewrite all of the old links also. Here’s his response:
“We have coded this and deployed it. As a result, all your dead Amazon affiliate links will be overwritten with our affiliate code and the revenue will be credited to you. What’s more, we just created an affiliate program against ourselves – any links you have to us on your blog will automatically be affiliated and you will receive 10% of the revenue from any customers we get as a result of those links.”
Awesome! If you are a fired Amazon Affiliate in Colorado, take a look at Viglink.
I talk about human computer interaction (HCI) a lot on this blog. We’ve invested in a number of companies in our HCI theme, including Oblong, Organic Motion, and EmSense and have a few more that we are working on that hopefully will be announced shortly. When I think about the areas I’ve been paying the most attention to and am the most intrigued with as an investor, HCI rises to the top of the list.
This morning I read an article on SeattlePI titled UW researchers look to reinvent the graphical user interface. While the headline is a bit sensational, the project (Prefab) is very cool. At first glance I thought it was simply rewriting HTML pages (clever, but not that big a deal) but then I realized it was doing something more profound. The five minute video is worth a look if you are into these types of things.
The bubble cursor and sticky icon examples are great ones. Starting at 1:45 you see the bubble cursor and sticky icons in action on Firefox in Vista. At 2:05 you see it on OSX. At 2:45 you see it in action on a Youtube player. The magic seems to be around pixel level mapping, which anyone working in adtech knows that’s where the real action is. It’s pretty cool to see it being used to map UI functionality.