Why I hate the AGPL

I’ve been, shall we say, debating the AGPL with the Neo4j guys for a few weeks now. I’d originally reviewed Neo4j for some uses at SimpleGeo, but ended up excluding it as a possibility for three reasons.

  1. It didn’t support replication.
  2. There wasn’t any inherent support for partitioning. This means we’d have to use Memcached’esque hashing to partition our data, which might work for many, but won’t work for our use cases.
  3. It was licensed under the AGPL.

The first two precluded me from using it merely on technical reasons, which aren’t huge hurdles because I was looking for a foundation to build on and would have gladly built that into Neo4j and released it back. The AGPL, however, was a deal breaker.

For those who don’t know, the AGPL is an incredibly viral license that says that not only do you have to redistribute your code changes, as the GPL states, but you must also publicly release any code that connects to an AGPL piece of software over a network. I fear the day that an HTTP server is built using AGPL. Think about it.

I’m extremely opposed to viral software. Since when is the term “viral” a good thing? Ultimately, though, my biggest complaint is the blatant hypocrisy of companies using AGPL. They’re basically stating that they’re “open” and “free”, when in reality they’re outsourcing free labor while retaining the right to charge for a proprietary license. The hypocrisy comes from companies trumpeting this so-called freedom when, in reality, they’re forcing certain behavior on their users. Reminds me of pious people saying, “You can live your life however you want! As long as you live it according to our rules.”

You want real freedom in software? Then release your code into the public domain, use CC0, or a BSD/Apache/MIT license. That’s true freedom. Anyone who tells you otherwise is either lying or delusional.

So do I have an issue with proprietary software? No, because Microsoft isn’t trying to play me for a fool. They’re up front saying, “Hey, it’s $199 to install Windows.” I can respect that. They’ve spent a lot of time building a product. They think it’s worth something. Consumers think it’s worth something. Simple economics come into effect after that.

What about services like SimpleGeo and AWS? No, because it’s not that you’re buying software. You’re buying a service. The crucial differentiator here is if your data is free. You’re not paying for AWS software or SimpleGeo software, you’re paying for service, support, and knowledge. What you pay SimpleGeo for is our knowledge in scaling, managing large server clusters, our data agreements with our various partners, and ease-of-use. It’s the same reason you go to the restaurant for a dish you could make at home.

What about Twitter or Digg? No, because those are communities. The notion that the software that runs Digg or Twitter is what makes them so special is ludicrous. The reason people keep going back to those sites is to participate with like-minded people in an environment they find fun and interesting. It’s like going to the bar.

So, in conclusion, if you’re going to release software then grow a pair and truly set your code free. If not, that’s fine too. Just don’t release your code using some zealot’s license and pretend your code is truly free when it’s not.

Fail fast and often

I’m saddened to hear the news that EventVue has closed up shop. It’s never fun watching other entrepreneurs have an exit like this knowing full well how much of themselves they put into it. The good news is the EventVue guys clearly have learned huge lessons and will be in a much better position to win in round two.

The one point they brought up as a lessoned learned was that they didn’t focus on learning and failing fast until it was too late, which reminded me of a quote from Joi Ito I recently heard at a conference.

“Want to increase innovation? Lower the cost of failure.” — Joi Ito

This is absolutely crucial. As a startup you need to fail and fail often. Not a lot of people know that SimpleGeo was, in fact, born of failure. Matt and I originally started the company as a location-based gaming company. Due to market realities (investors rarely invest in gaming companies in the seed stage), personnel realities (neither Matt nor I had built games), and other factors we had to have what I call our “come to Jesus” moment. Since then we’ve focused on small, quick iterations and quickly scrapping or moving on from our failures (or in many cases simply adjusting our assumptions).

Easy to say, but how are we doing it?

  1. We use a loose approach to Agile development with two week sprints. This means that, worst case scenario, we’ve wasted two weeks of effort in order to find out if a tweak, product, etc. is going to fail. I can’t emphasize how important this is. If you push your team 6 months and release a giant product only to find out users hate it or don’t use it, you’re screwed. 6 months is a lot of opportunity cost for a startup.
  2. We actively engage our user feedback. If users don’t like something we abandon it. If users are demanding something we move it up the priority list. For instance, we thought for sure that people wanted location-based search first and foremost after storage. Turns out, users actually wanted better tools for accessing and managing the data they’re sending us. So we’ve focused on churning out more SDKs and tools for managing data.
  3. We use Amazon EC2. Specifically, for testing and prototyping, we use spot instances. It’s an extremely cost efficient way to destroy servers during testing.
  4. We start small. Our current product offering is probably only 10% of what users expect from us long-term as far as pure number of features go. That being said, we picked the initial use-case and, I think, nailed it. The reality is 60% or more of the use cases for our users is simply storing millions of points and running radius queries on those points quickly. It’s also the foundation that all of our other products will be built on. So we’ve spent time focusing on building and iterating on that use-case. As a result, we’re multi-homed in three datacenters (actively serving data from all three), redundant across all three (meaning your data is stored in every datacenter), searches are extremely fast (under 50ms in some cases if you’re on EC2), and all points are backed up to S3 in YOUR account (it’s your data after all).

We’re not perfect by any means, but I think Matt and I realized early on that we need to be most efficient at recognizing and owning our failures and deficiencies. If you focus on minimally viable products, small iterations, and prioritizing user feedback you, too, can fail fast and often.

“Failure is useful.” — Larry Page