Infrequently Noted

Now, right this very minute, you can learn pretty much everything there is to know about Dojo thanks to 3 newly published books. Writing a book on Dojo is hard in the way the writing a book on Python is hard: there's so much to talk about, where do you start? When you could teach anyone anything, what do you focus on? Thankfully each of the books takes a different tack, talks to a different audience, and as a result I think the entire spectrum of web developers is pretty well served. Having reviewed 2 of the 3 books before they went to press (Dylan and Pete reviewed the other one), I've been amazed both by the depth of the books and by how different they are.

Pragmatic's "Mastering Dojo" has my name on the cover, but don't let that fool you...it's actually quite excellent, largely because Craig and Rawld focused do heavily on helping you not only learn what's valuable about the toolkit and how to use it, but by digging deep into the guts and showing you why the pieces are put together the way they are. The real art of building really responsive JavaScript driven UI's is about making good tradeoffs, and this book really helps you understand what Dojo provides you with in ways that let you trade things off for the benefit of the user experience.

The Pragmatic book isn't shipping from Amazon yet (unlike the O'Reilly and Addison-Wesley books), but if you buy it from the Pragmatic Programmers directly, you can get a PDF of the book immediately while the dead-tree copy wends its way through the end of the supply chain.

Update: Andy Hunt emailed me to let me know that the Pragmatic book is indeed shipping, and last night, upon arriving home from a business trip, I found my copies of the book waiting. Andy informs me that Amazon is also shipping them, so if you prefer the "one click" experience, you can order there as well.

"Dojo: The Definitive Guide" really is. As a reference, you can't beat Matthew Russell's tome. Where "Mastering Dojo" teaches you the how's and the why's, "Dojo: The Definitive Guide" is the book you'll keep on your desk and reach back to when you're not entirely certain what the inheritance tree of the Dijit form widgets is (and therefore, which you need to subclass or mix in). "Dojo: TDG" is chock full of insightful commentary and explanatory diagrams, and where the Pragmatic book helps you learn the pieces and pull them together intelligently, TDG gives you more of the pieces and helps you really get a handle on the vast functionality available in many of the nooks and crannies of Dojo. Don't develop serious apps without them both.

James Harmon's "Dojo: Using the Dojo JavaScript Library to Build Ajax Applications" stands out among the crowd as the easiest introduction to the toolkit. While the O'Reilly and Pragmatic books provide serious firepower for application developers, James' book gives a solid introduction which helps web developers who might not be down with the whole "Ajax" thing just yet a chance to catch up and start taking full advantage of the features Dojo has to offer. Large chunks of Dojo have been designed with non-programmers in mind, from the declarative markup syntax to the template system, and James' book helps really showcase how simple it is to start building rich, compelling UI's with Dojo.

There's probably still room in the market for 2 more books: one on using just dojo.query() and dojo.behavior for progressive enhancement, and one on advanced dojo.data (there are a pleathora of stores and use-cases there) and visualizations like the Grid, Charting, and dojox.gfx. I know that there are even more books in the works of, for, and by the Dojo community, and if the quality of those that come after is anything like these 3, it'll be just more proof that when the Dojo community does something, we do it right.

My personal congrats and thanks to all the authors who poured their lives into these books for months on end. The results are nothing short of spectacular.

There has been much discussion in the various Dojo fora of late regarding the need (and hassle) of requiring that all contributors send in signed Contributor License Agreements. These agreements state that:

• Those contributing to Dojo Foundation projects actually own what they contribute and therefore have the right to license it to someone else
• All of the rights needed to preserve the freedom of the code over the long haul have been contributed

Aside from some legal jargon, that's all that's in the agreement. So why have it? Why create the barrier to entry for newcomers who just want to pitch in? I have great sympathy for the impatient potential contributor huffing "why do I need to sign this, anyway?", so this blog post is an effort to boil it down. The reasons start with meritocracy.

Open Source projects often pride themselves on creating a more level playing field; when it works right those whose contributions are good are recognized while those whose contributions are bad are left with bit-rotting patches and hopefully some friendly direction on how to improve. In this way, it's the essential function of OSS projects to separate good contributions from bad. Oddly, the CLA process is a simple quality filtering function for weeding out the unserious, or simply another way to weed out potentially good contributions from bad.

CLAs are an annoyance to be sure, but consider what they attest to. I've heard the argument from time to time that "CLA's violate the spirit of Open Source" by limiting who can contribute, but that is indeed the point! Mature projects like Dojo don't accept patches without documentation, unit tests, and good code style...why should clean IP be any different? Indeed, CLAs allow us to be open yet rigorous at the same time. The CLAs process stands in stark contrast to many "open source"-in-name-only products which are produced by single companies or individuals but which don't provide any way to materially contribute back or become part of the project directly. The CLA process is both a sign that the project is open enough to allow you to "get your itches scratched" if you really want to contribute but also mature enough to manage the risks that come along with allowing everyone to potentially participate.

More to the point, do you really want to be taking code from a group of people who won't put in writing what everyone assumes about their contributions? And how seriously should you take an organization that hasn't thought hard enough about their own product to ensure that they actually have all the rights to the work they distribute? Remember, there's no requirement that anything be Open Source or that OSS products be developed as open projects, but the CLA process is in many ways a seal of quality: projects which require it are built to last (at least on an IP basis) and are also open enough to ensure that their community can grow.

One of the best aspects of the CLA process is that it gets people who are contributing to think about what it means to contribute. The CLA process means that they've printed out, signed, and hopefully read and understood that they are doing something serious and that they are joining a community of people who likewise take their work seriously. I really only want to work with people who are committed enough to making Dojo better that they'll take the time to think about how their work is licensed. Far from being just a task you need to do before you can contribute, the CLA process ensures that the people building Dojo are intellectually tall enough to ride.

Tall enough? Join us!