Archive for the ‘Startup’ Category
More Patent Foolishness
I seem to have software patents on the brain lately. After I wrote about our decision not to move forward with Infovark’s provisional patent, several recent articles and blog posts have caught my attention.
What started the latest round of software industry soul-searching was an article in the Harvard Business Review written by Nathan Myrhvold regarding his company, Intellectual Ventures. It’s called The Big Idea: Funding Eureka. His company aims to make money from enforcing patent rights created by both in-house and independent inventors. You can read a recent profile of Intellectual Ventures and its strategy in the New York Times.
I didn’t know about Intellectual Ventures at the time I wrote our blog post, but it’s exactly the sort of company I was thinking about when I described the collect ‘em, trade ‘em patent game. Intellectual Property lawyers call it a Non-Practicing Entity or NPE, but most folks in software and technology would call it a patent troll.
Big tech companies have a lot of time, money and effort invested in their patent portfolios, and they are very worried about the impact companies like Intellectual Ventures will have on innovation.
The venture capital community is also concerned. Brad Burnham of Union Square Ventures thinks that software patents are the problem, not the answer. Other prominent VC bloggers, like Fred Wilson and Brad Feld, agree.
Changes in the wind?
It looks like the idea of software patent reform is gathering momentum. Business method patents, like Amazon’s famous “one-click” shopping cart patent, have always seemed wrong to me. I also dislike the idea of software patents in general. A computer is fundamentally a machine for doing math. If mathematical formulas are not patentable, why should software be?
But it’ll be a long, hard road to get the law changed. And there’s only so much change that a reinterpretation of existing law, like the In re Bilski case, can bring about.
For one thing, investors must be persuaded to stop putting a premium on businesses and start-ups with patents pending. Companies that have patents must stop using them as competitive weapons — ways to tangle and trip up their competitors in red tape. Accountants must stop treating patents as a corporate asset or as capital.
Ultimately, companies will still pursue patents so long as they have a financial incentive to do so. And the companies that own patents have a vested interest in keeping the status quo. Even some of the VCs that back patent reform admit that they advise their portfolio companies to protect what they can.
There are enormous incentives to play by the rules, even when the rules themselves are broken.
Patent Foolishness
Our provisional patent expires today. We chose not to pursue an official, non-provisional one. It was a tough decision.
I won’t rehash the history of software patents here. And better writers than me have already written at length about the software patent debate. Paul Graham’s essay on software patents comes to mind.
This is about the decision process Gordon and I went through when we decided to pursue a provisional patent, and the reasons why we chose not to pursue the official one. The short version is: It’s the economy, stupid.
Mixed feelings
I’ve always had mixed feelings about software patents. As a programmer, I think they’re silly. It’s hard enough to write software as it is. Must I worry about all the thorny intellectual property issues, too? Code is more like sculpture than chemical engineering. Copyright should be enough to protect my work.
As a business owner, I understand why patents are necessary protection against other firms with large patent libraries. To put forth all the R&D and market development effort only to watch it drained away by litigation is a tech entrepreneur’s worst nightmare.
From an investor’s point of view, software patents are protection against downside risk. Unlike copyrights, patents are tradeable. There’s a market for patents, so even if the software business fails, you’ve still got an asset to sell to someone. You can get some of your principal back.
As long as we were in a bootstrapping phase, Gordon and I were content to leave the patent issue alone. Building working software and establishing a business were more important priorities. As a founder in a startup, you’re focused on delivering the upside, not managing the downside.
When we began seeking outside investment, that equation changed. The balance shifted toward getting a patent because it reassures potential investors. Gordon and I aren’t ideologues. We had no problem applying for trademark protection. So we swallowed our distaste and called a lawyer.
Patents: The Gathering
If the world of intellectual property seemed like one of those collectible card games from the outside — Hey, I’ll trade you two business method patents for three user interface licenses — it seemed even more so once we started the process.
First, we had the problem of defining our unique IP. You want to stake your claim as soon as possible, but since the software is currently under development, you make the broadest claims you can. We weren’t exactly sure what final form our “affinity engine” was going to take. We just knew that we needed to capture user behavior as a way of ranking the relevance of related items of content.
Then you hire a lawyer or law firm to search the patent office’s database of previous filings to determine whether somebody else has patented something similar. Since somebody else was making equally broad claims, it’s likely that you’ll need to refine your patent application a bit. This gets expensive quickly.
Once you file your official application, it can take quite a while before you find out whether it’s been approved or not. If it’s granted, you now have the ability to sue anyone that infringes on your rights. This is very expensive.
Intellectual property: How does your deck stack up?
The real point of having the patent is so that you can negotiate with other other patent-holders in case someone alleges infringement. It’s a strategy of mutual assured destruction. Rather than sue, counter-sue, and fight it out in the courts, you simply trade software licenses among yourselves.
The larger your deck of patent rights, the better the chance you hold the cards for something the other player wants.
For a start-up, this can mean that you can get acquired by a big firm solely because you hold an important patent. And if your business flops, you can sell your IP to a patent troll to use as ammunition against other companies. Investors like to see patents because it improves the valuation of a company and hedges against risk.
So it’s a costly and time-consuming distraction for a small business, but often a necessary one. We spent quite a bit of money on our provisional application in the hope that it would help attract additional investment.
Sunk costs
But then the economy soured, and investment began to dry up. It no longer made financial sense for us to pay for legal work if we weren’t going to raise additional funding as a result of it.
Another complication is that the future of software patents is in doubt. According to the recent In re Bilski case, software patents are only valid in cases where the software is tied to a physical device or is used to make changes in physical objects. Do either apply to software whose main purpose is to organize digital information?
It seemed dumb to come this far along on a patent only to abandon it, but we had to be pragmatic. It’s water under the bridge. We need to preserve what little cash we have left in the bank until our business gets going and the economy improves.
Conclusion
Building a software company is a long journey. Sometimes you make a wrong turn or stumble into a blind alley. We had no way of knowing when we began this process that venture capital would suffer a major contraction in 2009. It was a reasonable choice to make at the time.
I think that deciding not to go forward with our patent application is a reasonable choice now, given the economy and our need to bootstrap the business longer than we planned.
But that doesn’t make the decision any less hard to make.
One to Throw Away
Eric Raymond wrote about the release early, release often mantra heard often in the Linux open source community in his famous software essay The Cathedral and the Bazaar. Since then, it’s become the rallying cry of the extreme programming and agile software communities, and driving principle behind Web 2.0 companies everywhere.
Paul Graham listed “release early” as the #1 Hardest Lesson for Startups to Learn. So we were determined not to make that mistake when we started Infovark.
Oops
It’s taken us two years to release version 1.0 of Infovark. Sure, we had some Alpha and Beta tests along the way. We also had several prototype and demo versions. These don’t count as a release, though.
If you summed up our development experience over the past two years, it didn’t follow the trendy “release early, release often” paradigm as the much older “build one to throw away” model. Build one to throw away is a famous line from Fred Brooks’ seminal work, The Mythical Man-Month.
Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.
Tim Bray describes exactly that experience when working on a module to implement the Atom Publishing Protocol. And you could argue that Microsoft’s recent experience with Windows Vista and Windows 7 follows that model as well.
It certainly describes what we did with the Infovark Alpha. We restructured and rebuilt almost the entire application based on what we’d learned. The idea remained the same, the look and feel stayed roughly the same, but everything under the hood got a total rewrite.
It easily added nine months to our release schedule.
The right choice
It was a really hard decision to make, but it was the right one. We have a much faster, much more stable system to work with now. The number of bugs we’ve had reported to us in the two weeks since release is lower than any other 1.0 version of software I’ve worked on.
I’ll talk about the gory technical details of what we did and why on our Underground blog, for those that are interested.
You can download a trial copy of Infovark here. And for those of you that have it already, you might want to check out our very first update announcement.
Because from here on we plan to release early and often.
Ideas are Easy
A little over two years ago, Dean and I were two overworked ECM Consultants. We were flying all over North America every week in suits and ties, helping customers with their information management and technology problems, staying up late writing large and complex reports, drinking in random airport bars, and generally getting more and more frustrated.
The reasons for our frustration were that we felt that the customers we spoke to weren’t getting a very good deal. That the products that were being offered to them were expensive, complex, time-consuming, and in many cases, didn’t meet their actual needs. The very first post I ever wrote on this blog explains it all pretty clearly. Social systems are emergent in nature, and the systems that we have at work aren’t social enough.
One Labor day, we had an idea. We drew what came to be called “The Spiderweb Diagram” — a 7-page scrawled mindmap that detailed what we thought Enterprise Software should be delivering to its customers.
I’ve always said that the idea of a lifetime comes along once every two weeks. Ideas are easy. Implementation is hard.
Man, ain’t that the truth.
Today, two years later, the first fragment of that spiderweb diagram made the enormous leap from idea to reality.
Infovark Personal Edition 1.0 is complete, and ready for the world. You can try a copy for free, and if you like it, you can buy one.
It’s taken a lot of hard work — long hours, more than 150 blog posts — and has been the single most frightening, exciting and perilous thing I have ever done.
But at the end of this release, as the build machine finally turned off its super-loud CPU fan for the last time compiling pre-release code, I felt proud of us.
Anyone can complain about things, and most people, when pressed, can think of a way to fix a problem.
We actually did it though. We built and shipped something.
Acknowledgements
I want to thank everyone who helped us get this far.
Warren Thrasher, Infovark’s primary investor. Warren has helped us keep the lights on, and keep everyone fed, as well as providing sage counsel and advice to both of us.
Amy Hoy, who helped us turn our horrible looking Windows application into a much more user friendly and fresh solution worthy of the illustrious ”2.0″ moniker.
Nate and Jay and our friends at Kapish, for taking early versions of Infovark for a spin.
Alison and Paula, who not only put up with having their spouses absent for so long, but also managed to offer support and advice.
You, for taking the time from your day to read our blog! Our blog readers and Twitter friends and the awesome people we’ve met in the Enterprise 2.0 community have been instrumental in helping us get this far. We couldn’t have possibly done it without you.
Thanks!
