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.

Related posts:

1. Patent Foolishness

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.

Related posts:

1. More Patent Foolishness

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.

No related posts.

We’ve spent most of that time working with our installer. We want Infovark to work smoothly on Windows XP, Windows Vista and the upcoming Windows 7. We want Infovark to be compatible with recent versions of the Microsoft office suite. We also want to follow the Microsoft’s User Access Control (UAC) guidelines and other best practices.

Creating an installation package that meets these requirements will easily take 1/6 of our total development time for Infovark.

If you can eliminate the effort required to make an installation package, why wouldn't you?

Sadly, almost none of this work will matter to our customers. After all, who cares what the installation package does, as long as it does the job? From a customer perspective, any time we spend on installation issues is a waste. It doesn’t improve the product itself.

That, in a nutshell, explains why virtually every software program that can be delivered as a web application will be.

The inescapable logic of Web 2.0

Most users love web applications because they can begin using the product right away. They don’t have to worry about system requirements. There’s nothing to install and usually very little to configure. The product is always up to date.

IT professionals love web applications because they run within a web browser’s “sandbox” environment. Since there’s nothing to install, and the interactions with the rest of the user’s computer are strictly limited, there’s little chance that a web application will cause support problems.

Programmers love web applications, too. As soon as they implement a new feature, they can give it to customers and start getting feedback. They can deploy bug fixes immediately. Their applications will run on virtually every platform with only minor tweaks.

Software companies love web applications because they save time and money. The faster they get their products into customer hands, the faster they can recoup their investment. Applications developed for the web have a broader reach, so they have more potential customers.

Taken together, web applications and Web 2.0 has compelling advantages over software built and delivered the traditional way. Read why I’m done making desktop applications to hear what an independent software vendor (ISV) has to say about the subject.

Not everything can be a web app

Knowing all of this has made our work on the Infovark installer even more painful. We’re putting a lot of effort into troubleshooting our install routine that we’d really rather spend on Infovark itself.

There’s only one thing that justifies this extra work and extra care: It’s the only way to solve the problem.

Our goal is to liberate the desktop. Infovark allows people to share valuable information that they’ve created with their other tools. To do this seamlessly and transparently, with as little manual effort as possible, we have to integrate with those business applications. We have to go where the information lives.

That doesn’t stop us from wishing we were building a web app, though.

No related posts.

It’s especially tricky for companies in the product business, because so many of their costs are front-loaded — they incur the charges long before they can recoup the money from customers.

Infovark is lucky, because as startup companies go, software companies are cheap to run. Computer software and hardware are relatively inexpensive these days, and you can work anywhere that there’s a decent Internet connection and few interruptions.

Assuming you don’t count the cost of labor, of course.

That’s the reason so many software start-ups are located near universities with good computer science programs. The biggest asset a software company can have is an endless supply of folks that will write code for pizza and beer.

Gordon and I can’t work for free, though. We’ve got mortgages and families and responsibilities and stuff. Which contributes to a problem I call startup schizophrenia.

Supporting our coding habit

We started Infovark with money raised from friends and family, but no matter how frugal we are that money won’t last forever. So, starting six months ago, Gordon and I started doing occasional side projects.

On one hand, it’s been a great thing for us, because it’s helped us preserve our cash during the downturn. It’s also kept us connected to the Enterprise Software community, the Enterprise Content Management space, and the larger arena I’ll call “corporate computing”.

We know that space well, and we know that organizations need the help of experienced consultants to keep their disparate software systems working together.

But that space, familiar as it it to us, is not really Infovark’s market. And while we firmly believe that something like Infovark would be useful to a lot of people in the business world, it’s not something that CIOs or IT directors would find very interesting. The folks that manage back-office corporate infrastructure have different concerns from those that work directly with customers or are out in the field.

So Gordon and I find ourselves switching mental models a lot.

Wearing our consulting hats, we’ll talk with companies about security, scalability, interoperability and then we’ll hold an Infovark conference call where we’ll talk about sharing, openness, and ease-of-use. It’s a different set of priorities, driven by different motivations.

It’s a strange disconnect. The cognitive dissonance gets to us sometimes.

Shifting gears

While we were preparing for the beta release, we spent a lot of time dwelling on the subject of enterprise software. It’s what we know best. It pays the bills. And we’ll be more than happy to help folks with their ECM deployments or change management initiatives.

But over the coming months, I think we’ll talk less and less about corporate computing and more and more about personal productivity.

Our focus is changing now that the beta has been released. We can now get feedback from actual users that have tried Infovark. We’re hearing a lot about what features work and what things confuse people.

The folks at 37signals call it Getting Real. We had a theory about a personal information sharing application that was easy to install and use. Now we have to put it into practice. We’ll learn a lot about which of our crazy ideas work and which are just plain silly.

And as we do that, this blog will be less and less about the places we’ve been and more about the places we’re going.

In the meantime, enjoy our mental disorder.

No related posts.