Mentors in real life

As usual, Wendy Lea gets right to the point about surrounding yourself with the right mentors, and the right mix of mentors.

With CEOs like Wendy, being a mentor is an easy job. She is motivated not by some outside for (like her board), but by her deep appreciation for a variety of opinions, and she comes to the table with an open mind.

http://blogs.wsj.com/accelerators/2013/05/27/wendy-lea-behind-every-successful-person-theres-a-mentor

How to setup a vhost for a CouchDB couchapp

This is a tutorial for people who already know CouchDB and have their couchapps inside the database.

without vhosts, you reference your apps via this URL scheme:

https://myaccount.cloudant.com/mydatabase/_design/app/index.html

If you want the app to show up like this:

https://www.mysite.com/index.html

here are the instructions (specific to Cloudant.com):

1. create a CNAME on your DNS server:

www.mysite.com.        CNAME  myaccount.cloudant.com.

2. map the CNAME to your app’s design design document’s rewrite rules

visit:
https://cloudant.com/dashboard/#!/dashboard/vhosts

and create an entry that looks like this:

www.mysite.com -> myaccount.cloudant.com /mydatabase/_design/app/_rewrite

3. create rewrite rules that look like this:

[
    {"from": "/","to": "/index.html"},
    {"from": "/*","to": "/*" }
]

Come see me on a panel: Open Hardware | Startup 101 Panel for Entrepreneurs

Open Hardware | Startup 101
Panel for Entrepreneurs

NYC Tech Connect (powered by NYCIF) invites you to the following event:

Open Hardware Breakfast & Panel Discussion

Do you have an idea for an open hardware startup? Have lots of questions about the right strategy, protecting your IP, raising Angel or Venture funding?

Join us for breakfast and get answers to those questions and many more from our two experts – a serial entrepreneur /investor and an IP attorney.

Panelists:
Bob Pasker
http://www.linkedin.com/in/rbpasker

Kelsey Nix
IP Partner at Willkie Farr & Gallagher
http://www.linkedin.com/pub/kelsey-nix/17/918/310

Wednesday, November 2, 2011
8:30 – 10:00 AM

Hosted by:
The New York City Investment Fund
One Battery Park Plaza, 5th Floor
New York, NY 10004
Google Maps

RSVP required at events@nyctechconnect.com.
(For more information contact Jovan Stojanovich.)

Assessing the Value of Software Patents in Early Stage Companies

I see a lot of pitches a year. Hundreds of them.

Probably about 1 in 10 claim “patented” or “patent-pending” technology.

Since one component of venture capital is assessing the current and future worth of a company, how much value should an investor assign to a company’s patents, particularly in software or business processes, as opposed to hardware/networking, biotech/medical, or green?

I would say the value of each patent is about negative $50,000.00.

Before laying out my rational, let me say that I am not addressing the issue of whether patents are right or wrong, good or evil, ethical or unethical. There are plenty of people who have already written about that topic.

And I’m not addressing the issue of whether or not a startup should patent its technology: that’s up to the startup.

Lastly, I am not a lawyer, and this is not legal advice. If you have questions, you should probably call yours.

There are four issues at work here, one of which I have experienced personally, two are public knowledge, and the forth is so rare that I don’t even have a concrete example.

Reason one, I’ll call “the Kenamea patent” problem, which refers to a patent I coauthored as the CTO of Kenamea, and which was filed in 2001. The patent covers much of the stuff we take for granted today – real-time web, pub/sub into browsers, and Comet/AJAX. But we started just at the end of the Dot-com bubble, and even though we had a groundbreaking technology (as opposed to FedExing cat litter to Hawaii), the company did poorly (perhaps deserving of another blog post), and one of the assets that was sold off was the patent. I don’t know who bought the patent, and I can’t tell you how much it sold for, but I can tell you that it didn’t fetch anywhere near the amount of money I think it is worth (although I am biased). The reason is because it would take millions of dollars and many years to prosecute all the internet giants and lilliputians who are violating it. So perhaps a patent troll bought it to prosecute at some point in time, or an internet giant bought it to legitimize its use. The value of the patent at the time Kenamea was funded? Zero.

The second reason is what I call the “let them eat cake” problem, when big companies knowingly or unknowingly ignore patents by the little guys. If the big guys are unsuccessful in the market with the infringing product, there’s little or no legal damages. If they are successful with the infringing product, they can settle or go to court for damages 5 or 10 years down the road, after they have established market leadership and made billions of dollars. Two public examples of this are the wireless email patent and the 802.11 patent. [David Pollack, who read an early draft of this, reminded me that, “if a large company knowingly infringes on patents, there are nasty things that can happen. Most tech companies stay blind to patents so that they don’t knowingly infringe.”]

Issue number three is the “patent bully” problem: any successful startup in an interesting space has a good chance of being bullied by a big company. NewCo sues BigCo for patent infringement, BigCo turns around and sues NewCo for infringing 20 patents, and the result is a costless cross-licensing arrangement. Sun was accused of this by Azul Systems:

“Sun has repeatedly threatened the company with litigation unless Azul granted Sun part ownership of the company, and agreed to pay exorbitant up-front fees and continuing royalties on the sale of Azul products,” Azul said in a statement.

A settlement was eventually reached, but the terms were never disclosed.

Reason four is the “you can’t get blood from a stone problem”: there is very little benefit for one startup to sue another startup over a patent. Even if the patent holder could get the Board to agree to spend the time & money to litigate, the most likely outcome would be that the infringer would have to stop infringing or it would have to pay a royalty on probably non-existant revenue. This is just the the wrong way to launch a successful startup, and most people know this, which is why I can’t cite a concrete example. Better to beat the other company in the market than to sue, because you’ll have to build a strong enough product and company to beat all the other competitors out there anyway. This is not to say that a startup should not defend its intellectual property rights, but rather that there are better ways to go about winning than with knee jerk lawsuits.

Now lets look at where the negative $50,000 comes from: its an estimate of the actual legal cost to prepare the patent added to the opportunity cost of the inventor’s time, who would otherwise be writing software.

The overall lesson learned is that unless a company has the funds and resources to enforce a patent, an investor should probably value an early-stage startup’s patents at a negative $50,000 each.

Go ahead, patent away, or not. You can decide if its right or wrong, or useful or not.

I’m just saying that as an investor, they don’t add any monetary value for me, and can often drain time and money away from the company which should be out building a business.

–bob

What is One-and-a-half Phase Commit (1.5PC)? Or, how do I use JMS and JDBC without JTA?

Somebody tweeted Distributed transactions in Spring, with and without XA today, and I read it with interest because of my fascination with distributed transactions.

One of the patterns the author left out is how to provide the 2PC-like atomicity for a database and a messaging resource, but without using XA.

This is called “1.5PC” or “one-and-a-half phase commit.”

In a simple application that takes messages from a queue and updates a database, there are four combinations of behavior when things go wrong, two of which are acceptable and two of which are not:

• The message is still on the queue but the database has not been updated, which means the crash happened before the database was updated and the message was removed from the queue. These operations can be safely be reissued. This is considered acceptable.
• The message is no longer on the queue, and the database is updated, which means that both operations completed properly before the crash. This is considered acceptable.
• The message is still on the queue, and the database is updated, a bad scenario that happens when the crash happens after the database is updated but before the message is removed.
• The message is no longer on the queue, and the database hasn’t been updated, a bad scenario which happens when the message is removed from the queue before the database is updated.
  Scenarios 3 and 4 are really the same problem – one resource gets updated, but not the other – and can really be considered one problem, with the order of the resource operations reversed.

  1.5PC requires that the messaging system and the database share a unique identifier. It could be an SequenceID or a TransactionID, but it has to be unique for all time, and the unique identifier does not have to be monotonically increasing (but it helps).

  After a crash, the receiver recovers by looking at the head of the message queue, and using the unique identifier to determine if the message was already applied to the database. If the database updated has been applied, the message can be safely removed from the queue. If it has not been applied, the database is updated with the contents of the message, and the message removed from the queue.

  If you’re using Mule, you can get the same effect declaratively using its Multi-TX feature (although shame on Mule for the registration wall).

  But this is only one half of the equation: it prevents duplicate application of the same message to the database, but it doesn’t prevent the message sender from putting two copies of the same messages on the queue (“dupes”) or failing to put a message on the queue (“gaps”). This can be fixed in the sender with similar coordination between the source database and the message queuing system, which is left as an exercise for the reader.

  (Thanks to @RossMason of MuleSoft for providing feedback on an earlier version of this post.)

Consumer Seed Funding is the new Black

Most of us who work in the technology business don’t have to read GigaOM to know that seed and angel funding is very much in vogue.

But what is less obvious, but borne out by a report from CB Insights, is that most of the seed funding is in Internet startups, like social media, content, ecommerce, and applications (both consumer and enterprise).

This shouldn’t be much of a surprise because most angel investors concentrate on consumer internet startups.

But where does an entrepreneur look for angel funding for storage and data management, security, networking, high-performance computing, cloud computing, grid computing, parallel processing, transaction processing and application servers, messaging and event processing, mobile infrastructure, security, etc?

How is your angel investor going add value if he doesn’t completely understand the product or the market?

Or if he doesn’t have the right relationships at Citrix, Oracle, SAP, Intel, IBM, BMC, Cisco, RedHat, VMWare, etc.?

That’s why you need someone like me, who has the technical chops, the operational experience, the rolodex, and the alpha-geek mentality to help you get your core technology or infrastructure startup to the next step.

Write: seed –at– “my last name” –dot– net

The Real Price Fixing Scandal in Angel Investing is Deal Syndication

Deal syndication in angel and seed investing is a double-edge sword for the entrepreneur.

On positive side, you get a bunch of smart and well connected people and firms investing, who will all work individually and in concert to help you out.

On the other hand, with this arrangement you may miss the opportunity to get the best price for you deal because the “lead” angel sets the price, and other investors get to ride along.

The question is whether syndicate investors might have paid more if you had talked to them first, and your lead would have been a follower at a higher price.

In deals where the entrepreneur is having trouble filling the round, there’s not much choice, and the “rolling capital raise” works in the entrepreneur’s favor. He takes what he can get as it comes along, and moves on.

But in deals that are over-subscribed, a more entrepreneur-friendly solution would be to allow more capital in, and increase the pre-money valuation proportionately. This way, increased interest in the round will increase the price of the round.

Why Wesabe Lost to Mint – A Second Opinion

Recently, Marc Hedlund, the founder of Wesabe, ruminated on Why Wesabe Lost to Mint.

I feel somewhat qualified to comment on this topic because I did the technical diligence on Mint for First Round Capital, which led me to become an investor in the company. Furthermore, I have been a business acquaintance of Marc’s for over 10 years.

Marc’s answer to this question revolves around two criteria for success: (1) “making users happy quickly” and (2) “actually helping people” with their finances, and that “Mint totally won at the first…and we both totally failed at the second.”

Both of these points are correct, but I’d like to make some additional comments.

First, I think that by focusing on Yodlee’s impact on Mint’s out-of-the-box experience, Marc underestimates the other benefits of Mint’s decision to use Yodlee. There are almost as many banking APIs as there are banks, and Yodlee’s product supports over 10,000 data sources, and over 100,000 different account types. That’s almost a “boil the ocean” problem. When I spoke with Aaron Patzer back in 2007, I had the same doubts about Yodlee that Marc expressed, and Aaron’s answer was something along the lines of, “Well, if it works, it eliminates a tremendous amount of work for us. If it doesn’t work or if they screw us, we’ll rip it out and do something else.” They key principal for “build versus buy” decisions is “buy for parity, build for advantage,” and (as Marc freely admits) Mint made the right choice. Wesabe should have spent the money and engineering resources on building its unique value.

The second key point from my perspective is based on the impression that Aaron made on me during our first discussion. In the past 10 years I have seen over a thousand pitches and have meet thousands of entrepreneurs. Aaron Patzer is in the top 5 entrepreneurs I have ever met, and certainly the youngest. Mint also holds the distinction of being the only company where I didn’t know the founders, yet pulled out my virtual checkbook immediately after the first meeting. [In all fairness to Marc, he has never pitched me. I tried very hard to hire him once (and would again), and it was a fairly big loss that he turned us down. And given the opportunity, I would likely pull out my checkbook for him, too.]

My last comment is about the question Marc asks in his title: “Why Wesabe Lost to Mint.” The personal finance market, unlike, say, social networking, has no network effect, nor is the market a zero-sum game. We should have seen multiple exits in “web 2.0 personal finance,” like we did in the Java Application Server space. I think the real question Marc should be asking himself is “Why did Wesabe Shut Down instead of having an exit?”

How I make investment decisions: Know the Space, Know the People

Mocana and Symantec Partner to Protect the Internet of Things

Why do malware authors target PCs? Because of the sheer volume of them.

But as we learned today, mobile devices are growing at 5 times the rate of PCs.

And with WiFi or Ethernet chips now appearing in “things” like TVs and disk drives, and arriving soon in every electronic device in the home, the potential for malware instability (AKA SkyNet) is increasing exponentially.

That’s why Symantec announced a strategic partnership and an investment with Mocana. Mocana makes a “device security framework” that secures communications and data on any connected device.

Mocana’s CTO is James Blaisdell, the best emebedded software developer I have ever met (and those of you who know me know that I have met quite a few of them in my time). I have had the pleasure of working in various capacaties with James at four different companies over the last 16 years.

He first worked for me in 1994 as a QA engineer at Tribe Computer Works, and after I left he took over my work on a 56Kb serial driver I had been working on, redesigning it using a unique technique that I had never before seen and making it much faster than my original .

A couple of years later he started RapidLogic along with a few other people from Tribe who also worked for me, and sold that company in 2000 or so for $56MM to Wind River (now part of Intel). I served on RapidLogic’s Board of Directors.

When James decided to leave Wind River, which had acquired RapidLogic, I hired him on the spot at Kenamea, knowing full well that it was a waypoint for him while he decided what his next venture would be. James built the embedded versions our product for Palm, BlackBerry, and Windows mobile simultaneously, from scratch, in just a few months, which is quite a feat since he had never before programmed on any of those unique platforms.

James left a year later to start Mocana (which happens to have been the code name of one of our releases), and not long after that I wrote a check as one of the first investors in this venture. What makes his effort at Mocana so extraordinary is that James knew very little about security before starting Mocana, and over the last 5 or so years he has become one of the world’s foremost experts in a field notorious for being among the most dense and difficult areas of computing.

So, congratulations, James and the rest of the Mocana team. You have come a long way, and I am very proud of you.