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!
There are a lot of things about Open Source that are easy to get wrong, either intentionally or by accident. Given the number of folks who get it wrong, it's pretty clear that it takes real leadership for a project that's funded largely by a single company to commit to having external committers, manage IP rights in a responsible way, and really work to engage with a community outside of the folks who show up in the office every day. Speaking from experience, I can tell you that it takes real work to ensure that your project isn't just a code dump or even a read-only subversion repository that just happens to be released under an open license. Real, credible, honest-to-goodness, 100 point open source requires a effortful selflessness that rarely comes naturally to individuals and even less often to companies. I'm blessed to work for just such a company, but the web development landscape is littered with badge-ware, source-available-but-not-open projects, and other abuses of the spirit of the Open Source development model.
It's no small relief, then, to hear that Google is doing something incredibly mature: they're taking their name off of Gears. This comes in addition to their previous commitments to keep development truly open and to collaborate with anyone who will help them. From a purely corporate stand-point, it's the kind of move that takes cojones.
Google's de-branding of Gears stands in sharp contrast to Yahoo's half-assed Browser Plus effort which not only isn't Open Source, you can't even use it from non-Yahoo domains yet. It's impressive work technically, and Gears could learn some things from YBP's plugin architecture, but it's entirely unclear how such a closed product will help address the fundamental risk facing the web today: we need a trustable, open way to rev the web faster. One that can't be stopped in its tracks when a Microsoft or Netscape lose the interest or ability to push the web further on their own.
With Google's move, they're saying more clearly than ever to the Yahoo's of the world: "dude, seriously, put down the proprietary and help us make the web better". It's my sincerest hope that the Yahoo's, Ebay's and Amazon's, and IBM's of the world will all heed the call and work with Google to push a truly open Gears further, faster. The web needs the open process, mature leadership, and important feature set that Gears is delivering. No less.
I went to Google I/O last week and thanks to DeWitt Clinton I gave a talk on where browsers are headed and if they can really get us where we want to go. I'm afraid that even more so than is usual for the talks I do with slides, this set is somewhat indecipherable without the actual talk along side it.
Slides are below in PDF format (6mb):
Sadly, I didn't make it to many of the sessions, but I was able to catch Brad's excellent talk on building a client-side searching utility with Gears. His demo app used a custom build of Dojo, which was exciting to see because not only was it stripping out stuff that he didn't need from the base dojo.js using the customBase build option, but he was also able to use the build system to alias dojo. to pt. so that it didn't conflict with other versions of Dojo on the page and also packed up all the modules into a single file. We've had each of these features in Dojo for a while, but seeing them used together was incredibly powerful. Dojo can act as "Dojo" or the basis for your own library without much more work. The demo itself (a client-side search engine) was also powerful. Brad used Gears' worker threads to parallelize the work of pulling fetching, tokenizing, and handling a site's content. The speedup in being able to move this kind of work into the background (potentially onto separate processors and cores) opens up a new world of potential applications. I've been thinking about the implications of a ubiquitous Gears ever since.
An aside: Google throws a hell of a party. The only thing I've seen comparable to it was the awesome time that Microsoft hosted at this year's MIX. Landing the Flight of The Conchords was quite the geek coup for I/O, particularly since most of us had no idea who would be playing. Considering that I also got to see David Capurro at yesterday's Laughing Squid party, I'm pretty blissed out on geek meme entertainment.
Update: video of my talk is up at the Google I/O site. The video should make the arguments somewhat more clear than the slides alone could (although on the downside you'll to suffer through my myriad "um"'s and "uhhh"'s). Also, Neil McAllister has a piece up today which summarizes some of the talk's points. I'm afraid the talk left him with the impression that I support natural monopolies when in fact I only raise questions about their formation in order to find ways to effectively break them (or hollow them out).
In the past several months, more and more integrations of Dojo with server frameworks have been shipping, and we couldn't be happier about the Zend + Dojo integration that was announced yesterday.
Fundamentally the Dojo and Zend teams really "get" each other. Both are deep packages that give you an opinion about how best to do something but also all of the tools you'll need to make it work at scale. The "use at will" term that the Zend folks use made immediate sense to us. Like Dojo, Zend doesn't saddle you with more than you're really going to need up-front, but at the same time, when you need something awesome which is well tested and integrated, it's right there. No digging around on google to find a "plug in" that will get you where you want to go...both Zend and Dojo give you a full stack of great components to work with out of the box.
There have been some questions on IRC today about why Dojo and not something else, and we know that the Zend folks are committed to continuing to allow Zend to work with other frameworks as well and we fully support them in that. There seem to be lots of choices of Ajax frameworks which Zend could have integrated, but when you look at the requirements of serious products which need to ship tested solutions to really hard problems, the field whittles down very fast. In response to the needs of our users, both Zend and Dojo take seriously our responsibilities to provide integrated, high-quality, unambiguously licensed products that will let user scale both up and down. Key to this is understanding the full spectrum of use-cases, informed by past experience, and striking a balance between enterprise-ready features and close-to-the-metal primitives. The Zend Framework has a larger view of the server-side than Dojo can, and as a result there are new opportunities to optimize and improve the user experience for all classes of users through this integration. This isn't just about including some scripts on a page, this integration is about improving user and developer experiences, and both Dojo and Zend bring a lot to the table which can compliment the other. Dojo's strengths in progressive enhancement, packaging, localization, and accessibility all have obvious allegories in the ZF world where a complete integration can more value based on what developers are already doing. All of those features of Dojo will work better when the server-side knows how to "hint" things for the client and work with, not against, the client to deliver better experiences.
I'm perhaps most excited about the data-driven opportunities in the Zend/Dojo integration. Dojo's data infrastructure is second-to-none, and the design of the dojo.data and dojo.rpc layers provide Zend Framework integration the ability to take advantage of systems like the incredible Dojo Grid and the client-side charting package. There's more to look forward to, and figuring it out together with the folks at Zend is a great opportunity for the Dojo community.
Pete Higgins and I will be participating in next Tuesday's discussion with a broader chunk of the Zend Framework world, but until then (and long after) we'll be hanging out in the #dojo and #zftalk channels on irc.freenode.net. We're looking forward to working more with the ZF community to build great experiences, and are hugely excited about the direction things are already taking!
100 points to Freedom.
Dojo, DWR, CometD, OpenRecord, and the newly accepted Psych Desktop project are all 100 for 100 on Dion's scale because we've done the hard work of building a Foundation, ensuring the IP provenance of every checkin, built a community structure that gives everyone who's significantly invested a real voice, and have made the sacrifices that ensure that Dojo Foundation projects aren't just "open", but that they're trustworthy.
Dion's right:
The license is a great starting point, but it isn’t enough.
The Dojo Foundation has open door for any web projects that want to join and will do what it takes to get their score all the way up to 100. If the projects you're using aren't 100 for 100 — particularly given that we make it so easy — isn't it worth asking "why?"
Older Posts
Newer Posts