Extension Development and Social Contracts

In most software installations, the user (you) agrees to a EULA where limitations and restrictions are spelled out. By reading the EULA, you can make a decision as to whether or not you want to install the software. The EULA in a sense gives you the developer’s side of a contract, and by agreeing to the EULA, you are deciding to accept that contract. A EULA could have a statement like “this software will slow down your machine” or “this software will cause all other applications to break,” but you have the opportunity to read these statements in the EULA (usually) and decide whether or not to install the software.

Extension development, however, involves an implied social contract, because in most scenarios, a user is not presented with a license agreement before installing the extension. Here are a few examples the developer’s responsibilities in that contract:

  • Not slowing down the browser
  • Not breaking existing extensions
  • Not breaking browser functionality
  • Not losing any of the user’s data
  • Not stealing/misusing the user’s personal information
  • Not formatting the user’s hard drive 🙂

With previous versions of Operator, I was not proactive enough in making sure I didn’t break the contract. (Part of this was related to the fact that I committed to a specific release date, so I rushed things a little bit.) So the goal of this post is to outline for you (and for me) a basic social contract to make sure that what happened with Operator in the past does not happen in the future.

The Operator Social Contract

  1. I will run all of my JavaScript code through JSLint or something similar to ensure I am not making mistakes in my JavaScript that can break browser functionality or other extensions before every release.
  2. I will test ALL handlers for ALL microformats before making any build of Operator available.
  3. I will test migration from one release back as well as Operator 0.5 for every release.
  4. I will modify the method I use to debug Operator to ensure that I do not accidentally leave debug messages in the extension when I ship.
  5. I will continue to educate myself on JavaScript and extension development so that I can find ways to improve the performance of Operator.
  6. I will not commit to any specific day to release an update to Operator.
  7. I will not make any Operator build available on Firefox Add-ons before it has been made available on my personal website for testing by the community.
  8. I will take all bug reports seriously and attempt to solve them.

So there you have it. The beginnings of a developer’s social contract. So where am I in meeting this contract?

  1. I have fixed the specific bugs relating to migration and Operator interfering with tabbed browsing.
  2. I have run all of the Operator code through JSLint and found a number of issues which I have fixed.
  3. I have created an API I use for debugging that is automatically disabled in release builds.
  4. I have found some new ways to do some JavsScript that increase the performance of Operator substantially.

Per my contract, I am not committing to a specific day for the next release, but I am hoping to have something available this week (the week of Jan 7, 2007).

Thanks for your support!

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

4 thoughts on “Extension Development and Social Contracts

  1. 🙂

    Offhand, do you know if Operator runs after Greasemonkey is done? I’m going to be grease-scraping hCards out of a somewhat popular social networking site that seems to have a problem allowing data export.

  2. Mike

    This is really interesting. I get complaints about Firefox which turn out to be problems with an extension, so I know these are real problems. I’m very interested in what you find as you try to live within this social contract. I hope you’ll post updates.