Update: Note also that most errors will be reported by default, so the pref only turns on a few additional cases. Read the MDC article for full details.

I’ve been doing a lot of JavaScript development as part of my work on Prism, and I noticed a few weeks ago that a lot of errors I was used to seeing in the console weren’t showing up anymore. Unsure of the cause, I first took the expedient route of sprinkling my code with dump() statements whenever I had to track down a problem. This is tedious and time-consuming, however, and after a while I got fed up and (with Shaver’s prodding) spent some time trawling through the JS error reporting code trying to figure out what had broken.

Luckily for me, Sergey Yanovich noticed my incessant whinging on IRC and pointed me at bug 393627. It seems that some changes had been made to a JavaScript component that threw an exception that was expected, caught and managed in C++ code. Nonetheless, an error was being displayed in the console by XPConnect, so a patch was committed to suppress reporting of exceptions in these circumstances. Unfortunately this had the side effect of turning off useful and desirable reporting for a huge swath of errors.

A few weeks and 21871 bugs later found us embroiled in a heated discussion in the comments of bug 415498. The problem, it transpires, is a tricky one, as Ben Turner explained:

Ok, so here’s our basic problem: Some folks think that throwing exceptions is a perfectly valid way to communicate with C++, others try to avoid any unhandled exceptions and want to know if any make it back to C++. There is no way to consolidate those opinions, and we’ve argued back and forth about it many times already. A functional Components.resultCode might make this situation better, but that’s been broken for far too long to hope we’ll see it fixed in the next week.

Ben’s solution was to implement a preference, dom.report_all_js_exceptions, that turns on the verbose error reporting so vital to JavaScript developers. So even if you just skimmed the last few paragraphs, please pay attention because if you code in JavaScript in Firefox 3 you want to know this. Grab yourself a recent trunk (Ben says the fix landed last Wednesday or so). Set that preference. Watch your error reporting woes vanish before your eyes. There should be real documentation on this soon, but in the meantime hopefully this information will be of use to some.

Bookmark to:

I haven’t seen any sign yet of the “gaggles of groupies” that Mike promises in the post’s comments, but I’m sneaking out the back door to pick up a sombrero and some wraparound sunglasses, just in case.

Bookmark to:

When we initially launched AllPeers, the client was not open-source but we always said our goal was to do it. At the time, the source code was not clean enough to open but we knew this was the only way for us to prove we were genuine and not planning on spying on our users.

When we finally opened the code, some people saw it as a desperate move on our part. It was not. It was a way for us to be transparent and to say “if you don’t trust us, just look at our code”.

There are a lot of advantages about developing open-source software but trust and security are certainly high on the list.

Now forget about open-source software and think about all these websites who ask you for your login credentials in order to “import your contacts”. Can you really trust them and if so how? How paranoiac are you about this? I usually tend to trust the sites but is a nice design and a groovy name enough to earn my trust when it comes to my email credentials?

Bookmark to:

I’ve seen both approaches in action in my day. More than one startup founder has told me that they keep the hours reasonable because they “don’t want to burn out their staff.” Sorry, but what I heard was “I’m too lazy to work long hours so I can’t expect my staff to.” Of course, it depends to some degree on your ambitions. If your goal is to earn a good living with a bunch of smart, like-minded folks tackling some not-too-intractable problem, with plenty of free time to bungee jump from helicopters or make erotic origami, that is doable. But if you want to create a world-beating company, Mike Arrington has it nailed: your odds of succeeding are long enough without four-day weeks and ambling trips to the local juice bar five times a day.

Besides which, software geeks don’t have the same view of life/work balance as most people. In their response to Jason’s post, 37signals explain that:

Working with interesting people is more interesting than just working. If all you got going for your life is work, work, work, the good team-gelling lunches are going to be some pretty boring straight shop talk. Yawn. I’d much rather hear more about your whittling project, your last trek, how your garden is doing, or when you’ll get your flight certificate.

Probably the guy who wrote this is a graphic designer or something, since for all the real programmers I know, the most interesting subject imaginable is the software project they are currently working on. That’s why our social skills suck so bad. When we run into someone who isn’t a geek, we have no idea what to talk about. Naturally this gets old eventually, and even the pocket protector set ends up settling down, getting a dog and starting a family. Ever wonder why most startups are populated mainly with 20-somethings?

Which brings me to my real point: in light of this state of affairs, does Europe have a chance in the software biz? I’ve been working in European software startups for 15 years (and running them for 10). Having grown up in America, I’ve always been frustrated by the lack of obsessiveness when it comes to driving the company’s success. Programmers on this side of the pond work a lot harder than, say, post office clerks, but traditionally it’s still been a far cry from the mattress-under-your-desk workathon of the American startup nerd. When Arrington mocked the idea of “three weeks vacation” I had to smile. Over here, the big question is whether we can beat our staff down from five to only four weeks.

The good news is that the situation is changing. I’m seeing more and more startups built up around the American model. Globalization, more awareness of “cool” company cultures like Google’s and a few European home runs (such as Skype) are helping to reshape attitudes on this side of the pond. Lack of precedents for success, paucity of venture capital, stifling regulation and excessive risk aversion have conspired with our generally sedate work habits to lock Europeans into second-class citizen status in the software world. As we overcome these obstacles, I expect we’ll mount a much more credible challenge to America’s technological dominance.

Bookmark to:

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:

Before making the announcement, Matt and I were wondering yesterday if anyone would really pay attention. After all we had not been in the news for some time and we would not be the first company to “join the deadpool”. To our surprise, our announcement has generated a lot of press coverage including Wired, CNET, InternetNews, Ars Technica and of course blogs (from the most famous ones to the smallest ones). The feedback is a general feeling of sadness and incomprehension.

This has been beyond our expectations (this is a recurring thing here at AllPeers) and we are turning all this love into positives vibes for our personal and professional lives.

As Obi-Wan Kenobi said: “If you strike me down, I shall become more powerful than you could possibly imagine.“.

This is pretty much how we feel right now 24h after going public with the news. Thanks to all for caring, this is why we create businesses.

Bookmark to:

The past few years have been an incredible adventure for us. We would like to thank all of the amazing people who have helped us along the way. This includes countless users who provided us with valuable feedback about how to improve our product; the Mozilla community, who has proven to us that “community” is more than just a word when it comes to open source software; the many volunteers who spent hours translating each AllPeers version into fifteen different languages to make it available to non-English speakers across the world; and the friends and family who have supported us as we pursued what undoubtedly seemed like a crazy dream.

Being an entrepreneur is the most rewarding and exhilarating job we can imagine. Being able to build on a vision you have one morning and watch as it grows into reality is quite an experience. Seeing people get excited by what you are building is incredibly gratifying. The praise, devotion and even harsh criticism of the user community is what keeps you going despite long working hours, frequent stress and periods of uncertainty.

When we started working on AllPeers, we knew that it was an ambitious project with no guarantee of success. Such is the nature of any software startup. Sometimes it works, sometimes it doesn’t. Although we are deeply disappointed with the way this adventure has ended, we hope that fear of failure will never prevent us from daring to act on our inspiration.

We have met many many new friends thanks to AllPeers (you know who you are). This is a fantastic silver lining that gives us great comfort. We hope you will stay in touch as we move on to new pastures.

The success of this blog has also been one of the best experiences to come out of AllPeers. We will continue to operate it under the “Peer Pressure” name, posting our random thoughts about the web, the software industry, the evolution of media and whatever else strikes our fancy. We hope you’ll keep on reading. Matt will also continue writing his Just Browsing blog with a focus on web browsers and browser technology.

You haven’t heard the last from us. See you in our next life!

Bookmark to:

// ==UserScript==
// @name           Add MXR blame links
// @namespace      http://justdiscourse.com
// @description    Add links to CVS Blame to MXR search results
// @include        http://mxr.mozilla.org/*search?string*
// ==/UserScript==

var results = document.getElementsByTagName("ul");
for (var i = 0; i < results.length; i++) {
  var ul = results[i];
  var anchor = ul.previousSibling.previousSibling;
  var span = document.createElement("span");
  var blame = document.createElement("a");
  blame.href = "http://bonsai.mozilla.org/cvsblame.cgi?&file=/mozilla"
    + anchor.href.substring(anchor.href.indexOf("/source")+7);
  blame.appendChild(document.createTextNode("blame annotations"));
  span.appendChild(document.createTextNode(" (View "));
  span.appendChild(blame);
  span.appendChild(document.createTextNode(")"));
  ul.parentNode.insertBefore(span, ul);
}

Click here to install (Greasemonkey required).

It’s incredibly empowering to have this kind of client-side control over your browsing experience. One of these days someone is going to do this right and it’ll take over the world.

Bookmark to:

I asked around, and apparently fixing the problem is hard for some reason. Just now it dawned on me that I could take matters into my own hands. I used to be a Greasemonkey maniac, and I wrote a few pretty complex scripts back in the day. (None of these work anymore, I’m sure, due to changes in the associated websites, Firefox and Greasemonkey itself, but perusing the source code will bring you hours of enjoyment.) Wikiproxy and Bloglines Sidebar Squeezer even made it into Mark Pilgrim’s Greasemonkey Hacks.

Anyway, here’s the script I wrote to fix the Bugzilla nit:

// ==UserScript==
// @name           Bugzilla Platform Defaults
// @namespace      http://justdiscourse.com
// @description    Changes the default platform and OS to ALL
//                 when filing a new bug
// @include        https://bugzilla.mozilla.org/enter_bug.cgi*
// ==/UserScript==

resetDropDownList("//select[@name='rep_platform']");
resetDropDownList("//select[@name='op_sys']");

function resetDropDownList(xpath) {
  var dropdown = document.evaluate(xpath, document, null, 9, null).
    singleNodeValue;
  dropdown.selectedIndex = 0;
}

Click here to give it a spin. (You must have Greasemonkey installed.)

Bookmark to: