sorted by: recent | see : popular

Content Tagged with Industry + p2p

Although AllPeers didn’t produce the kind of outcome that we had hoped for and expected, it’s been a tremendous learning experience. Hopefully others will be able to benefit from what I consider to be the main lessons.

Luck and ambition

Naturally the success of any startup is dependent to some degree on luck, and the luck factor rises in proportion to your ambitions. If your plan is to sell T-shirts online then execution is probably the main consideration. If you make really cool designs, have an easy-to-use website and do good marketing then you’ll probably make money, though you’re unlikely to be buying a private island in the South Pacific any time soon. If, on the other hand, you plan to dethrone Facebook by adding state-of-the-art social features to the fabric of the web, transforming the internet experience of billions of people, you’re going to have to execute to perfection and still get really really lucky if your company is to succeed. Of course, if you make it you’ll be assured a very comfortable early retirement.

Neither of these approaches is inherently wrong but you should be aware of what you’re getting yourself into. If you can’t stand the thought of failure, make sure you’re not tackling a problem that is too big and ambitious. In the case of AllPeers, we knew that there was going to be a lot of luck involved (as there is with any product that relies on network effects and viral adoption), and we were pretty well prepared for the challenges we would face. It is comforting to see failure in this way because we certainly wouldn’t have sacrificed our lofty ambitions to increase our chance of moderate success.

Raise as much as you can

I’m not the first one to say this, but let me express my wholehearted agreement: raise as much as you can, as soon as you can, and not a penny less. In early 2006, before we had released even a private alpha of AllPeers, we suddenly became a minor web star thanks to a couple of white-hot buzzwords (”Firefox” and “BitTorrent”) and a very positive writeup on TechCrunch. (And in fact we owe a great deal to Mike Arrington, who grasped our vision immediately and did a great job of articulating why it was exciting. It’s easy and intellectually lazy to be pessimistic before the fact and snarky afterwards, while it takes courage to go out on a limb and predict success.) We believed our own hype a bit too much, unfortunately, and didn’t take advantage of the opportunity to raise a lot of cash at a high valuation. Instead we brought in a very modest amount under the assumption that we’d be in a great position in a few short months to close a much bigger round.

As a result, we were under constant pressure to get user numbers up so we could raise more money. This isn’t the way to run a company, particularly one with an ambitious technological vision. We ended up making a string of tactical moves rather than taking a step back and looking at the big picture. As a consequence, we ran out of money before we could get the product to where it needed to be. Don’t make this mistake.

This shouldn’t be construed as a criticism of Mangrove Capital Partners, who led our series A investment round. They are a fantastic group of individuals whom I wouldn’t hesitate to recommend to any entrepreneur seeking funding, and a classic example of a VC who really does offer much more than money to a budding startup (something they all claim to do). But only a company’s founder has a single-minded focus on the company’s success, and this includes acquiring a war chest to deal with unforeseen contingencies.

Be pessimistic about the technical challenges

A direct corollary of the previous point is that you need to make a very thorough and sober assessment of the technical challenges you are facing. Make sure that you are being realistic about deployment timeframes. Then double them. In retrospect, it seems obvious and absolutely normal that it would take us the better part of two years to build a new peer-to-peer stack from the ground up and deploy it in a scalable way, especially considering that no one has built anything nearly as complex on top of Firefox before or since. But in the heady days of early 2006 we expected the product to be ready for prime time much sooner. This led to unrealistic expectations on the part of our investors (entirely our fault) and impatience on the part of our fans. It is far easier to make this type of judgment in hindsight, of course, so it’s best to be as pessimistic as possible when communicating milestones.

The viability of consumer peer-to-peer

To a large extent, AllPeers was a bet on the strategic advantage that could be gained by using a peer-to-peer network rather than a centralized server. I still feel that this was a great bet, and I don’t regret making it. As any poker player knows, sometimes even good bets don’t pay off.

Nonetheless, with all the real-world experience of building a P2P network behind me, my opinion as a technologist is that the huge challenges of deploying a consumer P2P app outweigh the advantages. The notable exception is for products that aim primarily to avoid a central point of attack (for security reasons, to exchange copyrighted works without authorization, etc.). No one would put up with the relatively crappy user experience of BitTorrent versus, say, iTunes if it weren’t for considerations of this type.

The biggest problem with consumer P2P is that other users must be online in order for files to be available. With AllPeers, we frequently heard the complaint that “someone shared something with me but when I went to download it, I got a message saying ‘no sources’.” This is intensely frustrating, especially when it is the first experience you have with a new product. Meanwhile, the cost of bandwidth and storage has been plummeting, making centralized solutions increasingly attractive.

This isn’t to say that P2P doesn’t have compelling uses. A hybrid model that uses P2P where possible and a central server otherwise looks more promising since it solves the “no sources” problem mentioned above while retaining much of the efficiency advantage of a decentralized architecture. We had already started to experiment with this at AllPeers, and this would have become a big part of our technological strategy had we had time to finish implementing it. For mass distribution of media, I believe that P2P is most effective when it is implemented at a very low-level in the network stack. Application level code shouldn’t have to worry about it, but wherever possible data should be cached at the edges of the network and delivered from the most efficient location. This is essentially how the web handles distribution of web pages, with caching at the ISP and in the user’s browser. It also underlies the technical strategy of successful companies like Akamai.

Open source/Mozilla

On a more positive note, a decision I will never regret was our choice to implement AllPeers as an open source product on top of Mozilla. I didn’t have any experience beforehand working with open source, having worked mainly with Win32 development on Windows. Nonetheless, it is no exaggeration to say that I was welcomed with open arms (pun intended) by the Mozilla community before anyone had any idea who we were or what we were working on. Recruiting new members to the cause is the lifeblood of any open source project, so newcomers are given the benefit of the doubt even if (like me) they arrive unannounced and bombard people with stupid questions for days on end before they start to get a clue.

The nature of open source software itself makes it a dream platform for any programmer. It is much easier to track down problems and understand programming interfaces when you can drill down into the source code of the platform itself. In many instances, you can gain inspiration from existing code, take it and adapt it, remix it and otherwise benefit from those who have come before you.

I am sometimes critical of what I perceive as the excessively ideological bent of many open source advocates. One of the great things about the open source movement, in my view, is that is provides a strong counterweight to proprietary software. Efficient markets have healthy competition, and the strongest innovation can currently be seen in areas where traditional software competes with open source alternatives. This is true not only of the browser market, but also of operating systems (Windows and OS X vs. Linux), databases (Oracle and Microsoft vs. MySQL) and productivity software (MS Office vs. Open Office), to name just a few. I know a lot of people who want the whole world to go open source, but I think consumers benefit most from the tension between open, closed and all the various gradations that crop up in between.

The best thing about open source is the people. I never made any friends at Microsoft grinding away at my desk with Visual Studio and Microsoft Foundation Classes, but I’ve made scores of new friends in the Mozilla community: smart, passionate, hard-working people spread across the four corners of the globe. Working with open source is a rare opportunity to gain a competitive edge in the technology business and have fun doing it. I’d recommend it unhesitatingly to any software entrepreneur.

Bookmark to:

3 weeks ago, we met Robert Scoble for a little chat about AllPeers and what’s coming next. So if you want to see Matt, me, Scoble’s hand and a couple of Nokia N95 click play below.

Bookmark to:

Thank you PCWorld for making AllPeers the winner of the File-Sharing category of its “101 Fantastic Freebies” in front of Pando and uTorrent.

PC World editors tested and evaluated hundreds of downloads and services before narrowing it down to the top 101, with a designated “winner” in each of 23 categories from desktop search tools to video sites. Each service or program had to meet certain criteria in terms of design, usefulness, functionality, and of course, they all had to be free.

Bookmark to: