Freeing the Grid

September 19th, 2007

Recently, Mozilla had the opportunity to help do something quite new and free a piece of JavaScript software, namely the TurboAjax TurboGrid. The code has been freed under the auspices of the Dojo Foundation, becoming a new Dojo Grid component.

From a technological perspective, the grid is quite robust, offering a number of features, including support for large datasets, column manipulation, data independence, and editing of cell data.

What I find to be most interesting about this announcement, however, is the situation upon which it arrived. Mozilla and a number of Dojo users (SitePen, Nexaweb, Redfin and SnapLogic) all pooled their resources together in order to purchase, and subsequently, free the widget to the general public. I find it interesting that the companies chose to take this course of action, as they could've left it as commercial software, paying a licensing fee whenever needed. Instead, they decided that this component was so important to JavaScript and web development, in general, that the source be made open for all to use.

The position of the corporations using Dojo is obvious: They want to see Dojo succeed, and having a unified Grid component will ease their development costs significantly. However, for Mozilla, the goal is slightly more esoteric: We want to see the Open Web succeed (and by which, we mean the advancement of open software, standards, and development practices). Thus, by sponsoring the freeing of a critical piece of JavaScript development infrastructure, Open Web development becomes that much more feasible.

With this event taking place, I feel like a significant corner is being turned in JavaScript development. If you look at what was required to come up to this point:

1. JavaScript libraries congeal to a point to warrant standardization (in this case, in the form of Dojo) and Open Source development.
2. Developers begin using, and adopting, the libraries as their development platform of choice.
3. Commercial widgets are built on top of the platform.
4. A commercial widget is freed, and becomes Open Source.

That means that the JavaScript community has had the opportunity to mature to the point at which it can make a full cycle (having closed source software being built on open source software, becoming open again). A rather exciting time.

Now, obviously, the assumed effect on Open Web development that this particular widget has will vary greatly depending on whose asked. In the opinions of the Dojo Foundation (and the sponsors), it's very important. Asking users of another library, however, and you'll get a significantly different story. That's the one piece of this equation that particularly grates with me, especially coming from a vendor-neutral organization like Mozilla. The support of this widget is actually saying three things: 1) This is a high quality piece of code 2) Having this code open for all to use will better the web and 3) That you should be using the Dojo Toolkit for your development (since it's required in order for the widget to work).

I think an optimal approach would've been one with an extra stipulation: The widget would be freed both ownership-wise and dependency-wise. It's definitely possible, and the recent work that the Ext library has done proves that it can happen.

That's a rather minor point however as this feels like it's really just Mozilla starting to test the waters for funding Open Web JavaScript development. It wouldn't surprise me if we saw more of these "jailbreaks," or even sponsorships, in the future.

Side discussion: Apparently dojo 1.0 has dropped support for Safari 2? Bwahh? How is it even possible to drop support for a browser release that is still its current version? Trust me, once Safari 3 goes gold, I'm dropping Safari 2 support from jQuery like there's no tomorrow, I hate that browser with the fury of a thousand angry web developers, but until that time - too soon?

Update: I was asked to clarify a couple things: I'm not expecting Dojo to go out of their way to port the widget to other platforms (or even to free it from their own), I'd just think that Mozilla should make a strong attempt to generate codebase-neutral code. Granted, that may not be always possible - in the case of the Dojo Grid there's a significant amount of functionality tying it back to Dojo core.

Also, as far as the dropping of Safari 2 support goes, it was clarified to me that the Dojo 1.0 release will be at about the same time as OS X Leopard, thus, Safari 2 will already be by the wayside at that point. Noted - and approved of!

Tags: javascript, dojo, mozilla, opensource

16 Comments on 'Freeing the Grid'

Thoughts on Open Source Community

July 25th, 2007

I recently had the opportunity to read through some of the, brand new, Learning jQuery book and I wanted to take this opportunity to write up some of my thoughts concerning the jQuery project and open source in general.

Learning jQuery was written by Karl Swedberg and Jonathan Chaffer and I feel lucky that they were the first to have been given the opportunity to write about jQuery. Being part of the core jQuery team, I've had the opportunity to come to know Karl quite well in the past months, and especially within the context of his book writing effort. Looking at the end result, it's clear that his skills as both a developer, and a former English teacher, will suit the reader well.

What's most interesting for me, though, is the subject matter and context of the book. jQuery has always meant something completely different to me, than to most people, so to see it described in such a frank and descriptive manner is quite an experience.

For example, whenever I talk about jQuery, I inevitably discuss the design decisions that surrounded picking the feature-set that I did, and why I chose to set the focus of the library on DOM interaction above all else. Whereas, Learning jQuery immediately jumps into "What You Can Do" with the library, followed by many chapters of "How You Can Do It". In the context of the book it works quite well, but it provides a stark contrast, for myself, as to how the library relates to me, personally. For example, the sum total of my work and design decisions that have gone into the library is relegated to a single line of a single paragraph at the start of the book:

Created by John Resig, jQuery is an open-source project with a dedicated core team of top-notch JavaScript developers. It provides a wide range of features, an easy-to-learn syntax, and robust cross platform compatibility in a single file...

Seeing my work divorced from my personal experience is surreal and fantastic, for all that I know about jQuery is my personal experiences in creating, and sculpting, it over the past couple years. Seeing the library progress to a point that transcends anything that I've put into it is both exciting and daunting.

For me, jQuery is much more than a block of code. It's the sum total of experiences that have transpired over the years in order to make the library happen. The considerable ups-and-downs, the struggle of development together with the excitement of seeing it grow and succeed. Growing close with its users and fellow team members, understanding them and trying to grow and adapt.

Seeing this long tome talking about jQuery and discussing it like a proper tool, as opposed to the experience that it's come to encapsulate for me is what makes this such a strange read for me.

I'm not the only one who enjoys jQuery on a plane that is far different from a normal tool-user relationship. I don't know if I can properly encapsulate why this is, but it's something that you can't get from reading a book, nor produce simply through following tutorials.

It's almost cliche, at this point, to say that your open source project is community-oriented, or that you want to focus on helping new users get started. But it's not just an orientation for jQuery, it's the liquid-oxygen fuel for the project.

I'll confess that I've never truly participated in a large open source project before, nor have I really, truly, understood how they worked internally. Taking nuggets of information that I could pan from projects like Drupal and Dojo, I began to better understand how an open source project could be structured and run. Before that point, though, I made a couple (and in retrospect, rather radical) decisions that have helped to truly shape the project and make it what it is today.

The first decision that I made with the library was to sculpt a sort-of custom programming language around the concept of HTML-JavaScript interaction. Instead of enhancing the normal DOM layer (using simplified method names, for example), I instead decided to make selectors the absolute core of the library (making it a sort-of CSS-JavaScript-HTML-DOM domain specific language).

An example of jQuery-as-a-language:

I love being able to see users who truly understand just how different the end result can be, especially in comparison to normal DOM scripting. There's a specific moment where it just clicks for them, where they realize that, this tool that they had been using, was in fact much much more than that all along. And suddenly their understanding of how to write dynamic web applications completely shifts. It's an incredible thing, and absolutely my favorite part of the jQuery project.

The next decision was to form a jQuery Evangelism team, led by Rey Bango, to drive the jQuery community. At first, I only really expected this team to focus on things like handling community participation on the mailing list and blog tracking/response, but it has since progressed rather drastically.

Blog tracking is a particularly interesting area of project evangelism. A couple points had come up to make it necessary: First, that it was important to get a good response to user comments and questions (and it had simply overwhelmed me, personally) and secondly, that it was important to get a good, consistent, response to people, coming from the project itself. (We had had a number of instances where misinformation was spread, and although it was done with best intentions, it was better that we get an accurate message out first, acting as a definitive voice of the project.) Tracking is also quite controversial. We've been able to answer the questions and doubts of dozens of bloggers. The end result being users who aren't just interested in this new project, but almost fanatical.

This brings up the second interesting point about evangelism, and its logical next step: relation management. While we don't, internally, yet have a proper CRM to keep track of all our users (we're in the process of switching to Basecamp to try and make this possible) we do keep very close ties with all of users, even giving special attention to high profile companies and open source projects (at our discretion). This is something that the evangelism team really takes to heart, and something that most users don't see. We keep internal threads to track specific problems that a user might be having, trying to figure out ways that we can best help them (either through bug fixes, pointers to specific resources, or simply affirmation that we're there and we care about their progress with jQuery). We don't really have a specific means of picking which people we pay extra attention to (if we were a business, it would be the customers that paid us the most, I would assume) but it boils down to which people have the biggest opportunity to make the project look good. (So open source projects, companies with public-facing web sites, and vocal/influential users and bloggers; and roughly in the order too.) This is something that we're still working on, and we're starting to get real good at it. What's interesting about this, though, is that this is what helps us to turn a normal user into a devoted user - one whose interest in the project goes beyond that of the normal tool-user relationship.

All of this is related. How we run the project, and how you use the code, is fundamentally very different from most open source projects, and most JavaScript libraries. We're incredibly devoted, and understand this fundamental difference in how our code works, and pass that on to our users. Devoted users breed more devoted users, and the cycle continues. This isn't something that you can get from a book, nor is it something that you can read to understand. It's something that you actually have to experience in order for it to fully sink in, and something I hope that most of the book readers will be able to enjoy.

Incidentally, I get the feeling that the jQuery community will be increasing the book sales, and not the other way around.

Tags: jquery, javascript, opensource, programming, community, project

13 Comments on 'Thoughts on Open Source Community'