At the beginning of 2009, MooTools was a single thing – one library maintained by maybe 5 or 6 people who actively pushed code into it. It’s hard to reconcile this with where it is now. Let’s see, first, MooTools was split into two in February – MooTools Core and MooTools More. The principal developer, Valerio Proietti (the creator of MooTools) focused most of his energy on MooTools Core with the help of several other developers, and I’ve focused most of my efforts on MooTools More, the official plugins for the library. While Valerio and others continue to refine the core, the -more team has brought the number of plugins for MooTools from around a dozen to nearly sixty.

Part of what changed was our active recruitment for people to be involved in our development community. Our developer mailing list went from about a dozen people on the mailing list with 4-6 people actively pushing code into MooTools to around 50 developers on our mailing list with somewhere around 15-20 people actively pushing code. These numbers tell part of the story; of tremendous growth – as much as 400-500%.

At the same time, there have been a lot of new things happening that may be slightly off your radar. For instance, a MooTools user named Piotr Zalewa showed up one day out of nowhere with a paste-bin app for MooTools that lets you create stand alone working code examples with HTML, CSS, and JavaScript which he launched at http://mooshell.net. Immediately upon joining the developer list he started adding features and working with others on the list to make it better and better and the result has been phenomenal. The usefulness of our user mailing list has gone up dramatically as users show up asking questions with working examples (or, more often, broken ones that they need help with). Other users can edit the shell and save a new version, responding with a link that shows exactly how to solve the problem. Daily we see how MooShell has affected our ability to help our users and we’re happy that MooShell is now an official MooTools project. Expect to see these working demos in our documentation early this year (to a demo of this in action just scroll down to the “Demo” section here).

There are a number of other new additions to the library that are still somewhere between pre-alpha up to beta states. There’s the Depender application that lets you build libraries on the fly. MooTools ART, a canvas adapter for MooTools, continues to come along. Slick, MooTools’ new selector engine is in testing phase and we hope to see it released early in 2010. We just released the MooTools 1.1 to 1.2 Upgrade Helper which should help those still using 1.1 to adopt the current release. MooTools 2.0 is still under heavy development, but we’ll be releasing MooTools 1.3 early this year with some new features. Even stuff that we don’t release, like a new search engine for mootools.net.

And then there’s the MooTools Forge, our new user-created plugin catalog. The Forge alone would be enough for me to call 2009 a big year for MooTools. It is absolutely what MooTools was really missing. Developer Guillermo Rauch cranked out a slick bit of technology that closely integrates with Github and makes it easy for developers to update and maintain their plugins. In only a month or so there already 100 plugins in there with more added daily.

All of these things, this proliferation of output and creativity, stem from one small change that happened early in the year. Something that in many ways no one outside our developer community would know about or even have noticed: MooTools went from being the work and property of one person to being a project owned by its community. For the roughly two years previous to 2009 that MooTools was around, it was developed almost entirely by Valerio. It’s true that other people, such as myself, contributed to the work with Valerio as the gatekeeper. The MooTools code has always been elegant and easy on the eyes to actually look at, and this grooming was a product of that single guardian who cared deeply that the code always be as clean and elegant as possible. It was uncommon for anyone to make a commit to the project without Valerio coming through and tidying it up, always making it just a little better and in the process teaching us how to be better developers.

In February of 2009, the first little step happened with the split of MooTools Core and MooTools More. The code in -more is still methodically groomed and maintained, but not by Valerio. The -more team does this service for each other, each checking over the others’ work and making it a little better, a little leaner. As we actively recruited people into the developer list, we had more and more people working on different things. Selector engines, paste-bin applications, plugin libraries, canvas adapters, a search engine for mootools.net, test frameworks, and more; it all became far too much for one individual, even two or three, to be the gatekeepers.

At my job at Cloudera, I have the privilege of working with Doug Cutting, who brought Lucene, Nutch, and Hadoop out through the Apache Foundation. Doug spent a bit of time with us talking about how Apache develops open source software and after a few weeks of work we produced a founding document for how MooTools projects will be developed and governed. This document, our “charter” is influenced heavily on Apache’s processes, though not as rigid as we don’t have their scale issues (yet!), but it’s had a remarkable influence on our development team. All the things I’ve listed in this lengthy post have sprung up as a result of this change. What started as a split (-core, to –more and -core) has now grown into a federation of projects that we govern as a group. And that federation of projects, that freedom to just make things happen, is now filtering out into our community with the Forge.

So when I look back on 2009 and ask myself what MooTools accomplished, I look at all the things we released, all the code we wrote, and all the new people contributing and think of those things as side effects. The thing that really happened in 2009, and it took all year to do it, was MooTools became a project owned by all of us. Valerio is still guiding it, but we’re no longer rate limited by his ability to pay attention to all we can create. And so projects move forward with their own teams, and plugins get released by enterprising individuals on the Forge, and users send us bug reports using MooShell to demonstrate the problem. All these things are spectacular. But what really happened was that (tiny at first) shift to belonging to everyone who contributes.

When I consider 2010, my mind is awash. In one year our team grew by several hundred percent and the number of projects being actively worked on did the same. Our community has better tools to share their work. 2010 is going to be less about MooTools itself and far more about what we, as a community, make with it. If 2009 was all about the MooTools developer community coming together and taking things to the next level, 2010 is going to be about our community of users, and the possibilities there are endless as far as I can tell.

So consider this a challenge, an open invitation. Surprise me.

At Cloudera (where I work now) we’ve been hard at work for the last month on the product we’re launching today. (Side note: I’m not going to link you to it because you’ll just go there and play with it and screw up all our numbers when we see all these JavaScript people show up and click the forward, back, forward, submit, add, delete, etc. buttons just to see what they do and we’ll be wondering what we’ve done wrong to make the interface so confusing…)

Anyway, today’s launch is basically a 6 step form. It’s built on Django’s form wizard which, in many respects, does all the work for you. Making the experience interactive, helpful, and even kind of fun to use is my task, and it’s made me consider the cost of adding such (arguably non-critical) features.

Let’s face it. As much as we like to talk about how JavaScript has finally kind of arrived (what with all the “Web 2.0″ commentary) and, well, it really has kind of arrived when you think about what you can do with the technology, but as much as we tout that, it’s still expensive.

Developing a simple 6 step form takes probably, oh, a day to do with a framework with Django. Less even. A few hours. If you were practiced at it and knew exactly what you wanted, maybe not even an hour. But then we start thinking about Ajax, client side form validation, tool tips, interactive components that help you construct more complex data sets that otherwise might be a pain to do by hand (like, say, typing in a date), etc. etc. And the next thing you know, there’s 90K of JavaScript on the page. Oh, and it doesn’t work quite right in Chrome or Safari 4 because those browsers aren’t in your testing suite, and then there’s IE6, which you’d rather just not support.

It seems that, just as we’ve gotten to the point where we can just bang out something as simple as a 5 step form, we’ve managed to complicate it ten times over so it still costs a ton of time and money to make it work. Is it worth it?

I’d like to think so. I like having rich interfaces that look nice. I want a web app that I build to feel like it’s going the extra mile to make the user’s life a little easier and the task in front of them a little fun. Playful even.

I’ll give you another example. I made a login box for this app. It’s a username/password box floating dead center in the page. It fetches the server response to the user’s login attempt via ajax and if the user types in the wrong credentials, it shakes at them and puts a little red “!” next to the password field. It’s not that fancy, but it makes everyone who sees it want to type in a bad password. But doing this meant a bunch of photoshop and css to make it look slick, a new extension to MooTools’ Fx that took a bit of effort, plus a bit of hacking in the Django authentication code which isn’t quite designed for this style authentication.

It’s made me think more about my programming to patterns concepts. It’s more important than ever to focus on inheritance and derived functionality. Building a base layer of functionality and abstraction makes it possible to create a system of rich interfaces. The cost up front is somewhat daunting, because you basically have to approach everything in a generic way. Sure, you’re working on the login box, but to just make the thing jiggle you have to revisit the authentication model of your app and author a new Fx plugin which involves figuring out the math for a sinusoidal transition… Ack!

But it’s worth it when you get further into it. It’s what makes Apple products so rewarding. All you have to do is look at all the phones that came before the iPhone and know that there’s value in going that extra mile. Functionality paves the roads and makes the engines work, but the details in the design make the difference between a Ferrari and a Hyundai.

The task that we have before us, I think, is to figure out how to make the system that we use to add those fine details as cost effective as Django, Ruby on Rails, and other such frameworks have made the MVC pattern. For MooTools I can see that pathway (and to be fair, we’re behind other frameworks on this score – but MooTools More is the first step on that path), but ultimately it requires a lot of people contributing who are solving very different problems to create such a system. It’s always cheaper to do something for one time use if you are never going to reuse it.

So the task I have before me, personally, is to abstract as much of my own work away from my current goals so that others can use it. And your task is to do the same. And our task as a group is to contribute our use cases, knowledge and effort into finding the commonalities between these things and make life a little better for each other. If we spent the next 2 months, 6 months, and year doing that, we’d be in such good shape. In a way that’s what we’ve been doing with MooTools this whole time (and the same can be said of all the frameworks, which borrow from each other constantly). So when I write about why you should release your code this is one of the bigger reasons. Yeah, there are a lot of shorter, tactile reasons for doing it despite the effort it takes. But the big reason is that we’re all busy reinventing the wheel. We should be doing that, but after we’ve all invented the wheel, we should compare notes, and collaborate. Then the next time we need a wheel there’s nothing to think about, and the only thing left to do is to see what cool things we’ve all done with them. Ferraris indeed.