A year in the life of an open source project – FireBreath 1.2 released

September 15, 2010 7 Comments by Richard

Starting a new open source project

Beginning an open source project is probably one of the more cliché things to do in the industry. How many open source projects are out there that have almost no support, haven’t been updated in years, or are just plain useless?

This is the story of how I created FireBreath — and how it has remained a “high activity” project for a full year on Google Code. If you are short on time, I recommend skipping to the end of this article and reading the “Things I have learned” part.

The need for the project

A year ago I had an idea for a project that I felt would be benefited most — both in terms of project development and for anyone who would use it — by making the project open source. I wanted to create a framework for creating browser plugins. The problem? I just didn’t have the time to do it on my own time.

My big break came when a company out of California contacted me about building them a cross platform browser plugin framework. Now, let me explain a bit about my schedule: I was working full time for Move Networks, taking 10 credit hours at Utah Valley University, and my firstborn son was about 6 months old.

After some consideration, I agreed to do the project; my one stipulation was that they had to agree to allow me to release the code as open source. That week, I created the Google Code project for FireBreath (a name I selected randomly from a bunch I brainstormed) and uploaded the initial code — which was still mostly code generated by Visual Studio.

I also posted my Call for Plugin Developers here on colonelpanic and posted links to it on the NPAPI newsgroup.

The growth of the project

Getting started

I created the Google Code project September 16, 2009 — a year ago. Obviously, the project was ambitious; to provide a framework that not only allowed you to write plugins that would work in both Firefox and Internet Explorer, but to make it easy to simultaneously write them for Windows, Mac, and Linux — and to make it easier to write a plugin using FireBreath than straight NPAPI or ActiveX. I don’t care who you are or how brilliant you are, no one person by themselves can make a truly great project.

First Contributors

Several people expressed some interest, but then quickly disappeared (and in some cases simply stopped responding to emails.) Georg Fritzsche contacted me with some ideas about using C++ meta-programming to simplify the JSAPI interface. I’ll be honest — when I first read his explanation of what he wanted to do, my first thought was “This is crazy, and there is no way it can get simpler than it is.” However, it was one of the first direct offers of help that I’d seen, so I told him to share some more details with me on the mailing list and I’d look at what he had.

Nearly two weeks later, I had basically forgotten Georg and his suggestions that he could improve my Javascript interface when suddenly he posted a set of patches to the list. What was more, when I took a close look I realized that his ideas fit perfectly with the approach I was taking, and furthermore that I hadn’t the slightest idea how it worked. Georg’s understanding of meta-programming is still so far beyond mine that I ask him for help frequently whenever I mess with it. His “crazy” contributions now make up the JSAPIAuto class that nearly all Javascript API objects in FireBreath are built on.

From that point onward, Georg quickly made himself invaluable to the project; he wasn’t getting paid for his work (though he deserves it), so he didn’t spend as much time as I did, but it wasn’t too long before I just made him an owner of the project and started checking with him when I made changes. FireBreath would not be what it is without his early contributions, as well as those he has continued to make since then.

First releases

In December 2009 I posted FireBreath is Ready for Testing and posted a link on the NPAPI newsgroup. We now felt that FireBreath was far enough along that you could build a Windows plugin with it — although still no support for Linux or Mac. We started to see some real interest in the project outside the company I was working for: I had a couple people contact me asking for subcontracting help with FireBreath, and several individuals joined the project and asked about getting Linux and Mac support going.

Once there were some developers expressing interest, I gave them what information I could, and then in a fit of insanity took a few hours one night and got the initial support for Linux implemented. A few weeks later I did the same for Mac, after having a company contact both Georg and myself about possibly having us do a Mac plugin for them, although that never panned out.

Another piece, contributed initially by Ben Loveridge and Jarom Loveridge (brothers), is the “fbgen” tool — a tool that creates a skeleton plugin project for use with FireBreath. I believe this contributed significantly to the initial uptake of FireBreath.

Period of lower development

As all contracts inevitably do, the contract I was under for 10 hours a week of development on the browser plugin framework came to an end at the end of January 2010. I could no longer justify spending much time on FireBreath, but I knew it still wasn’t done. FireBreath lacked support for streams (HTTP downloads), good Mac and Linux windowing and system event integration, and threading support, to name just a few deficiencies.

However, the seeds had been planted: this really was a project that had the potential to save people a lot of time. Slowly at first, but then a little bit more as people found the project, developers started using FireBreath and contributing fixes for things that were missing. Georg and I continued to monitor the mailing list and answer questions, though neither of us had much time. But, little by little, users started to contribute fixes and enhancements for the missing functionality.

The project is picking up

One of the funnest things to do with this project has been to watch the Google Analytics reports for the project. In January of 2010 there were about 900 hits to the FireBreath website; last month there were about 2500. Granted, this isn’t a lot compared to large websites, but for a small open source project it isn’t bad.

One month that was particularly fun was when ajaxian.com put up a (very) short blog post about us. There were 4000 hits that day. That month had 10,000. We are also now up to about 100 members on the mailing list.

The latest and most encouraging development is that a little company in California called Facebook (heard of them?) has hired me as a contractor and is sponsoring some development with FireBreath. I can’t comment yet on what they may do with it, but the upshot is that I’m back to spending some real time on the project, and there are several nice features (like Unicode support) that 1.2 has that were contributed by Facebook.

Today we released FireBreath 1.2. It contains more features than any other browser plugin creation tool that I know of, fully supports Unicode characters both in processing and in method/property names, simplifies many tasks that would otherwise be extraordinarily painful, and allows you to create a basically cross-platform browser plugin in 10 minutes (if you have Python and Cheetah installed — although we are actively looking into removing the Cheetah dependency).

Lessons Learned

There are a lot of lessons to be learned from the experience of starting an open source project. Though its user-base may be small, I consider FireBreath to be a successful small project.

In no particular order, here are some things that I have learned:

  • Once the initial feature set is in, it is more important to help newcomers than it is to code new features
    • Coding new features is more fun, but if you have time for just one — help people use your project
  • Don’t be too obnoxious, but don’t be shy about telling people about your project.
    • Post short, tasteful mentions of your project on forums, preferably while you are helping someone
  • Don’t ever write off someone’s idea without hearing it first
    • I can’t even remember how many times I have heard an idea that I initially thought “Huh, that wouldn’t work well,” but on further inspection turned out to be a great improvement. Almost invariably, these are the types of improvements that make the project glow.
  • There is always something about your project that newcomers don’t appreciate or understand — be patient with them
    • The most criticized part of FireBreath’s design is that the project system relies on CMake. Windows developers in particular hate this. However, there are reasons; my standard response is “If you have a better idea that solves <problems solved by CMake>, please share.” I have never had any takers.
  • Take the time to help others who are working in the same area
    • Competition is great, but if you’re really good at what you do, you don’t need to worry about helping others solve trivial problems. One of the top referrers for FireBreath is stackoverflow, where Georg and I have both answered many questions (often with links to FireBreath)
  • Use a distributed version control system like Mercurial, Git, or Bzr if you can
    • Yes, I know that everyone knows how to use subversion; but when you have people who want to keep their own clone of your code and then be able to easily contribute back, distributed versioning tools are invaluable. (Oh, and that’s exactly what you want people to do.)
  • Create an IRC chatroom
    • I was hesitant, but it has been a great way to interact with the users of the project
  • Use the most permissive license type that makes sense
    • We started out using EPL, but found that many didn’t want to use our codebase because of licensing; we eventually switched to BSD, and people contribute back simply because they know their code will work better if their changes are vetted and tested by more people. In a framework, this makes sense; for an application, it may not.

Special Thanks To

While Georg has made some particularly valuable contributions to the project — contributing more code than anyone besides me — there are many others who have donated code snippets and time. Here is an incomplete list of people that I could find doing some simple searches in no particular order:

  • Anson MacKeracher (amackera) – Built out Georg’s Mac drawing code to a fully usable state; if it’s Mac-specific and Anson didn’t write it, he still knows how it works.
  • nitrogenycs – Streams support, and many other small bugfixes.
  • Kalev Lember – Numerous small fixes, one of the main testers and tweakers for linux.
  • Antti Andreimann (anttix)- Helped to build the initial XEmbed support for linux, and wrote EvaluateJavascript.
  • schmoo – Provided the initial patch to support Visual Studio 2010 as well as other minor fixes.
  • Schnapple – Miscellaneous bugfixes.
  • Ben and Jarom Loveridge – One started and one finished the fbgen tool. Jarom is working to remove the Cheetah dependency.
  • Kevin Menard (nirvdrum) - Testing, ideas, and support.

And, of course, thanks to everyone who uses FireBreath; you make this project successful!


If you would like to keep track of what FireBreath is doing, you can Follow us on Twitter.