May the deities we’ve invented forgive us for the tripe we’re about to sell each other as “news”.

What’s bound to be missing in most of this coverage is what’s plainly said, if not in so many words, in the official blog post: going faster matters.

Not (just) code execution, but cycle times: how long does it take you to build a thing you can try out, poke at, improve, or demolish? We mere humans do better when we have directness of action. This is what Bret Victor points us towards — the inevitable constraints of our ape-derived brains. Directness of action matters, and when you’re swimming through build files for dozens of platforms you don’t work on, that’s a step away from directness. When you’re working to fix or prevent regressions you can’t test against, that’s a step away. When compiles and checkouts take too long, that’s a step away. When landing a patch in both WebKit and Chromium stretches into a multi-day dance of flags, stub implementations, and dep-rolls, that’s many steps away. And each step hurts by a more-than-constant factor.

This hit home for me when I got my first workstation refresh. I’d been working on Chrome on Windows for nearly a year in preparation for the Chrome Frame release, and all the while I’d been hesitant to ask for one of the shiny new boxes that the systems people were peddling like good-for-you-crack — who the hell was I to ask for new hardware? They just gave me this shiny many-core thing a year ago, after all. And I had a linux box besides. And a 30″ monitor. What sort of unthankful bastard asks for more? Besides, as the junior member of the team, surely somebody else should get the allocation first.

Months later they gave me one anyway. Not ungrateful, I viewed the new system with trepidation: it’d take a while to set up and I was in the middle of a marathon weekend debugging session over a crazy-tastic re-entracy bug in a GCF interaction with urlmon.dll that was blocking the GCF launch. If there was a wrong time to change horses, surely this was it. At some point it dawned that 5-10 minute link times provided enough time to start staging/configuring at the shiny i7 box.

A couple of hours later the old box was still force-heating the eerily dark, silent, 80-degree floor of the SF office — it wasn’t until a couple of weeks later that I mastered the after-hours A/C — when my new, even hotter workstation had an OS, a checkout, compiler, and WinDBG + cargo-culted symserver config. One build on the new box and I was hooked.

5-10 minute links went to 1-2…and less in many cases because I could now enable incremental linking! And HT really worked on the i7′s, cutting build times further. Hot damn! In what felt like no-time at all, my drudgery turned to sleuthing/debugging bliss (if there is such a thing). I could make code changes, compile them, and be working with the results in less time than it took to make coffee. Being able to make changes and then feel them near-instantly turned the tide, keeping me in the loop longer, letting me explore faster, and making me less afraid to change things for fear of the time it would take to roll back to a previous state. It wasn’t the webdev nirvana of ctrl-r, but it was so liberating that it nearly felt that way. What had been a week-long investigation was wrapped up in a day. The launch was un-blocked (at least by that bug) and the world seemed new.

The difference was directness.

The same story repeats itself over and over again throughout the history of Chrome: shared-library builds, ever-faster workstations, trybots and then faster trybots, gyp (instead of Scons), many different forms of distributed builds, make builds for gyp (courtesy of Evan Martin), clang, and of course ninja (also Evan…dude’s a frickin hero). Did I mention faster workstations? They’ve made all the same sort of liberating difference. Truly and honestly, in ways I cannot describe to someone who has not felt the difference between ctrl-r development and the traditional Visual Studio build of a massive project, these are the things that change your life for the better when you’re lashed to the mast of a massive C++ behemoth.

If there is wisdom in the Chrome team, it is that these projects are not only recognized as important, but the very best engineers volunteer to take them on. They seem thankless, but Chrome is an environment that rewards this sort of group-adaptive behavior: the highest good you can do as an engineer is to make your fellow engineers more productive.

And that’s what you’re missing from everything else you’re reading about this announcement today. To make a better platform faster, you must be able to iterate faster. Steps away from that are steps away from a better platform. Today’s WebKit defeats that imperative in ways large and small. It’s not anybody’s fault, but it does need to change. And changing it will allow us to iterate faster, working through the annealing process that takes a good idea from drawing board to API to refined feature. We’ve always enjoyed this freedom in the Chromey bits of Chrome, and unleashing Chrome’s Web Platform team will deliver the same sorts of benefits to the web platform that faster iteration and cycle times have enabled at the application level in Chrome.

Why couldn’t those cycle-time-improving changes happen inside WebKit? After all, much work has happened in the past 4 years (often by Googlers) to improve the directness of WebKit work: EWS bots, better code review flow, improved scripts and tools for managing checkins, the commit queue itself. The results have been impressive and have enabled huge growth and adoption by porters. WebKit now supports multiple multi-process architecture designs, something like a half-dozen network stack plug-ins, and similar diversity at every point where the engine calls back to outside systems for low-level implementation (GPU, network, storage, databases, fonts…you name it). The community is now committed to enabling porters, and due to WebKit’s low-ish level of abstraction each new port raises the tax paid by every other port. As James Robinson has observed, this diversity creates an ongoing drag when the dependencies are intertwined with core APIs in such a way that they can bite you every time you go to make a change. The Content API boundary is Blink’s higher-level “embedding” layer and encapsulates all of those concerns, enabling much cleaner lines of sight through the codebase and the removal of abstractions that seek only to triangulate between opaque constraints of other ports. Blink gives developers much more assurance that when they change something, it’s only affecting the things they think it’s affecting. Moving without fear is the secret of all good programming. Putting your team in a position to move with more surety and less fear is hugely enabling.

Yes, there are losses. Separating ourselves from a community of hugely talented people who have worked with us for years to build a web engine is not easy. The decision was wrenching. We’ll miss their insight, intelligence, and experience. In all honesty, we may have paid too high a price for too long because of this desire to stay close to WebKit. But whatever the “right” timing may have been, the good that will come from this outweighs the ill in my mind.

Others will cover better than I can how this won’t affect your day-to-day experience of WebKit-derived browser testing, or how it won’t change the feature-set of Chrome over-night, or how the new feature governance process is more open and transparent. But the most important thing is that we’ll all be going faster, either directly via Blink-embedding browsers or via benchmarks and standards conformance shaming. You won’t feel it overnight, but it’s the sort of change in model that enables concrete changes in architecture and performance and that is something to cheer about — change is the predicate for positive change, after all.

Origin(al) Sins – Alex Russell from OWASP AppSec USA on Vimeo.

I made some pretty glaring errors in the talk: you can’t combine sandboxing with seamlessness for cross-origin content. It’s something I’m hoping we can improve on in the browsers/specs, but it’s not the current state of play. I also failed to mention that CSP is Mozilla’s brain-child and they deserve huge credit for pushing it down the field. Similarly, I failed to mention that IE 10′s CSP support is actually quite shite, supporting only the sandbox directive. Lastly, my objections to the OCAP worldview may have been oblique so, before the flames arrive in the comments, let me try again:

I think that you’ll always end up with some variant of “object capabilities”, if only through wrapper objects that hide protocol details. The OCAP world calls these “membranes” for particularly high-fidelity versions of this. When you have a word for it, it’s probably common. Vending objects that represent capabilities is natural at some level, but I strongly resist the urge to take the pun too far. Don’t get me wrong, I’m a huge fan of capabilities as the model for building apps that have real security by default; and I hope their pervasive use combined with more restrictive, separated execution contexts creates the world we all want to be in. My only quibble is on the developer ergonomics front. OCAP encourages the (perhaps naive) programmer to build many things inside the same “vat” (heap, context, whatever), leading to brittleness whereas protocols and true sandboxing can create secure boundaries that, importantly, look like boundaries. Systems that provide big “this is a security boundary!” disclaimers on their APIs while making it hard to screw them up stand a better chance of weathering the storms of human imperfection. Can you do OCAP right? Sure, it’s possible, but as I argue in the talk, betting on humans to do the right thing is eventually and inevitably a loser. So I favor large, knobby interfaces over which you can send messages and no more. Wrap ‘em up with an RPC layer…cool…whatever. But design a protocol with side-effects that are straight-forward to reason about on both sides — not an object which can be easily intertwined with many others in a dense graph — and you’ve got my vote. I’m even in favor of building those protocols and then wrapping them with easier-to-use APIs (call it “CAP->O”, if you will), but eliding the step of a large boundary over which you can only send data, and making it relatively hard to cross? Nah, I’ll be over here with the easy-to-reason about solutions that don’t make my small-ish brain melt, thanks.

Also, I wasn’t sure to what extent Doug was joking about “incompetent” programmers in his talk, so our disagreements may not be what they seem. Caveat emptor.

Thanks to Jeremiah and the other organizers for taking a risk and inviting someone who’s been out of the security space for so long to give a talk. I promise to them that should they be so foolish in the future, I’ll be sure to duck out and get one of my betters on the Chrome Security Team to stand in instead ;-)

Your Moment Of Zen

The backdrop to this debate is that CSS is absolutely the worst, least productive part of the web platform. Apps teams at Google are fond of citing the meme that “CSS is good for documents, but not for apps”. I push back on this, noting the myriad ways in which CSS is abysmal for documents. That isn’t to minimize the pain it causes when building apps, it’s just that the common wisdom is that CSS surely must be fantastic for somebody else. Once we find that person, I’ll be sure to let you know. In the mean time we should contemplate how very, very far behind the web platform is in making it delightful to build the sorts of things that are work-a-day in native environments.

But it’s worse than simply being under-powered: CSS has the weakest escape hatches to imperative code and demands the most world-view contortion to understand its various layout modes and their interactions. Imagining a more congruent system isn’t hard — there are many in the literature, might I humbly suggest that now might be a good time to read Badros & Borning? — and even CSS could be repaired were we able to iterate quickly enough. Things have been moving faster lately, but fast enough to catch up with the yawning gap in platform capabilities? We’ll come back to the speed/scale of change later.

For now, consider that the debate (as captured by Nate Vaughn) is about the retrospective implications of the few things that have already gotten better for some set of developers in some situations. That this sort of meaningful progress (corners, gradients, animations, transitions, flexing boxes, etc.) is rare makes the debate all the more bone-chilling to me. We finally got a few of the long list of things we’ve been needing for a decade or more, and now because the future is unevenly distributed, we’re about to blow up the process that enabled even that modicum of progress? How is it we’re extrapolating causality about engine usage from this unevenness, anyhow? None of this is obvious to me. The credible possibility of losing prefixes as a way to launch-and-iterate is mind-exploding when you realize that the salient competition isn’t other browsers, it’s other platforms. Either the proponents of squatting other vendor’s prefixes haven’t thought this through very hard or they’re bad strategists on behalf of the web as a platform…not to mention their own products. The analysis that we’re being asked to accept rests on an entire series of poor arguments. Lets start with the…

Uncomfortable Assumptions

In an interview out yesterday with Eric Meyer, Tantek Çelik of Mozilla tried to present this debate as a question of barriers to the adoption of non-WebKit based browsers, specifically Firefox Mobile. Opera has made a similar case. What they ommit is that the only platforms where they can credibly ship such browsers are Android and S60 (a dead end). That’s a large (and growing) chunk of the world’s handsets — good news for me, as I now work on Chrome for Android here in London — but for whatever reason it appears that iOS users surf a whole lot more.

Let that sink in: on the devices that are the source of most mobile web traffic today, it’s not even possible to install a browser based on a different engine, at least not without a proxy architecture like the one used in the excellent Opera Mini or Amazon’s Silk. iOS and Windows Phone are both locked-down platforms that come with only one choice of engine (if not browser shell). When folks from the vendors who want to appropriate others’ prefixes talk about “not being able to compete”, remember that competition isn’t even an option for the most active users of mobile browsers. And it’s prefixes that are keeping us down? We must go deeper.

The tension comes into focus when we talk in terms of conversion, retention, and attrition. Conversions are users who, if able, switch to a new product from an old one. Retention is a measure of how many of those users continue to use the product after some period of time. Today (and since Windows first included a browser), the single largest factor in the conversion of users to new browsers is distribution with an OS. This is the entire rationale behind the EU’s browser choice UI, mandated on first start of new Windows installs. Attrition is the rate at which users stop choosing to use your product day after day, and for most desktop installed software, attrition is shockingly high after 3 to 6 months. The attrition rate is usually measured by cohorts over time; users who installed on the same day/week/month to measure what % of that group continue to use the product over increasingly long periods of time. The rate of decay falls, but the overall attrition invariably continues to rise. You might not get un-installed, but that doesn’t mean you’ll still be the go-to icon on the user’s home screen or desktop. Eventually every device is recycled, wiped, or left for history in a drafty warehouse and along with it, your software. A key factor in getting attrition under control for Chrome has been evangelism to improve site compatibility, e.g. “I’m not using your browser because my bank website doesn’t work with it”. That argument — that site compatibility is key to ensuring a competitive landscape for what otherwise are substitutes — puts the entire thing in some perspective. Attrition isn’t the same thing as conversion, and conversion is driven primarily by integrations and advertising. Implicit in the arguments by Tantek and others is a sub-argument of the form:

Our product would have measurably more users if sites were more compatible.

Thanks to what we know about what drives conversions, in the short run this is simply false. Long term, what invariably gives you more users is starting with more users. The set of things that are most effective at convincing users to swap browsers, even for a day, include: advertising, word-of-mouth, a superior product, distribution/bundling, and developer advocacy. Depressingly, only one of those involves actually being a better product, and the prerequisite for all of them is the ability to switch (thanks, Android team!). There’s a similar dynamic at work when doing advocacy to web developers: if you’re nowhere in their browser stats, they’re adding support for a standard or worse a second prefix in order to do service to a cause, not because it’s measurably good for them. Clearly, that’s going to be somewhat less effective. Where, then, is the multi-million dollar advertising campaign for Fennec? The carrier and OEM rev-share deals for bundling on new Android phones? Hmm. To hear Tantek et. al. tell it, non-WebKit-based browsers would be prevalent on mobile if only it weren’t for those damned browser prefixes causing users of other browsers to receive different experiences! Also, those kids and that damned dog.

Over the long haul compatibility can have a dramatic effect on the rate of attrition by changing the slope of the curve — which, remember, is a rate with decay and not a single % — but it begs the next uncomfortable question: what do we mean by “compatibility” here? What sorts of incompatibility cause attrition? Is it content that looks slightly worse but still essentially works (think grey PNG backgrounds on IE6) or does it simply turn you away, not allow you to play in any way, and generally fails (think the ActiveX dependencies of yore)?

Inaccessible or Ugly?

Eric was good enough to call out what I view as a key point in this debate: what sort of “broken” are we talking about? Tantek responded with a link to side-by-side screenshots of various properties rendered on Chrome for Android’s Beta and current Fennec. In some of these cases we may be looking at Fennec bugs. WordPress.com serves the same content to Fennec which seems to bork what float: left; means. That, or some media query is preventing the main blocks from being floated; it’s hard to tell which from a quick view-source:. For the versions of google.* included in the list, the front end is simply serving the desktop version to Fennec which makes the wonky button rendering even stranger. Is there room to improve what gets sent to Fennec? You bet, but that’s not what’s being argued in the main. Ask yourself this: is what you see on that page worth destroying the prefix system for? ‘Cause that’s what the advocates of prefix-squatting would have you believe. In effect, they’re suggesting that nothing will cause developers to test on non-pervasive engines, a deeply fascinating assertion. Even if we accept it, it doesn’t point clearly to a single tactic to resolve the tension. It certainly doesn’t argue most strongly for prefix-squatting.

An important point Eric failed to follow up on was Tantek’s assertion that Mozilla will be cloaking user-agent strings. Does he imagine that the only thing that might be cause someone to send different content is CSS support? API support for things like touch events differs, the performance characteristics of device classes and browsers vary wildly, and application developers are keen to deliver known-good, focused experiences. The endless saga of position: fixed; as plumbed by Google teams and others is a story of competing constraints: browser vendors optimize for content, content fights back. Repeat. What does Mozilla imagine is going to happen here? Maintained content will react to the browser usage of end-users (and as we’ve covered, compat != conversions). Unmaintained content, well, that’s what fallback is all about. And bad things deserve to lose. Assuming that your browser is 100% compatible with developer expectations and testing if you only switch the UA and implement a few prefixes is NPAPI-level crazy all over again, and it’s entirely avoidable. Tantek and Brendan, of all people, should be able to reason that far. I guess they’ll find out soon enough — although we will have all been made poorer for it.

Now, what about the related argument that Mozilla & Co. are only going to be doing this for properties which are “stable” (nevermind their actual standardization status)? The argument says that because something hasn’t changed in another vendor’s prefixed version in a while, it must be safe to squat on. Not only is this (again) incredibly short-sighted, it says that instead of forcing a standard over the line and clobbering both developers and other vendors with the dreaded label of “proprietary” (the usual and effective tactic in this situation), they’re instead willing to claim ownership and therefore blame for the spread of this soon-to-be-proprietary stuff, all the while punting on having an independent opinion about how the features should be structured and giving up on the standards process…and all for what?

Product vs. Platform

Perhaps there wasn’t space in Tantek’s interview with Eric, but both of them chose not to be introspective about the causes of WebKits use in so many mobile browsers, with Tantek merely flagging the use of a single engine by multiple products as “a warning sign.” But a warning of what, exactly? Eric didn’t challenge him on this point, but I sorely wish he had. Why did Safari, the Android Browser, Chrome, Silk, Black Berry, and many others all pick WebKit as the basis for their mobile browsers?

WebKit isn’t a browser. It’s just not. To make a browser based on WebKit, one might bring along at least the following bits of infrastructure which WebKit treats as bits to be plugged in:

• Networking
• Caches of some sort
• Graphics rendering
• A build system
• POSIX or other platform plumbing

And that’s a minimum. Competitive ports tend to include WebSQL, LocalStorage, and Indexed DB back-ends, video codecs, 3D infrastructure (deeply non-trivial), perhaps an alternative JavaScript engine (V8 or other), and alternative/additional image decoders (e.g., WebP). All of that is in addition to needing to create your own UI for bookmarking, navigation, etc. WebKit is an engine, not a fully-functioning vehicle. Therein may lay some of the difference in the relative success of the WebKit and Gecko on mobile to date. Want to build a Gecko-based browser? Great, first clone the entire Firefox codebase from Mercurial, then layer your stuff on top/around. Oh, wait, things might not cleanly be factored to allow you to plug in your own X, Y, or Z? Your builds take forever? Welcome to life in the Mozilla universe where your product is always second fiddle to Firefox. Now, that’s not by way of criticism, mind you. It is entirely reasonable for a product like Firefox not to pay coordination costs with other vendors/users of their code. God knows the overhead over here in WebKit land of trying to keep the menagerie of ports building against all changes is downright daunting. Mozilla (the organization) has made choices that prioritized the success of their product (Firefox) over their codebase (Gecko). WebKit was structured as platform only (no product), both forcing enormous costs onto every port while also freeing them from swimming upstream against a single product’s imperatives in the codebase.

What we’re witnessing isn’t open vs. closed, it’s differences in initial cost of adoption. In JS terms, it’s jQuery (focused core, plugins for everything else) vs. Sencha or Dojo (kitchen sink). Entirely different target users, and both will find their place. Nobody should be shocked to see smaller, more focused bits of code with good plugin characteristics spreading as the basis for new projects. The Mozilla Foundation wants to help prevent monoculture? In addition to making the Firefox product a success, there are concrete engineering things they can do to make Gecko more attractive to the next embedder, Firefox-branded or not. I haven’t heard of progress or prioritization along those lines, but I’m out of the loop. Perhaps such an effort is underway, if so, I applaud it. Whatever the future for Gecko, Product success isn’t related to platform success as a first approximation. Having a good, portable, pluggable core increases the odds of success in evolutionary terms, but it’s absolutely not determinant; see MSIE.

Speaking of IE…I respect those guys a lot, but the logical leap they’re asking us to swallow is that the reason people return Windows Mobile phones is that some CSS doesn’t work. That’s what attrition means on a platform where they’re the only native runtime. Data would change my mind, but it’s a hell of a lot to accept without proof.

The Time Component

Lets take a step back and consider Tantek’s claim that Mozilla has gotten very little traction in evangelizing multi-prefix or prefix-free development for the past year: Firefox for Android has been available since Oct. 2010 and stable for just 6 months. Opera Mobile on Android has been stable for just over a year. IE 9 (the only IE for mobile you could ever seriously consider not serving fallback experiences to) only appeared with Windows Phone 7.5 (aka “Mango”), shipped to users an entire 6 months ago.

And we expect webdevs to have updated all their (maintained) content? Never mind the tenuous correlation between the sorts of soft incompatibilities we’re seeing at the hands of CSS and user attrition; the argument that even this lesser form of harm hasn’t been blunted by evangelism appears suspect. Taking the incompatibilities seriously, I can quickly think of several other measures which are preferable to destroying the positive incentives towards standardization the prefix system creates (from least to most drastic):

• Continued evangelism to web developers with particular focus on major sites
• Political pressure on browser vendors to start dropping prefixes (i.e., we’d all be equally disadvantaged until users pick up the standard version)
• UA spoofing without prefix squatting
• Blacklists to trigger alternative identity (UA/prefixes) on a subset of sites

All of these are less blow-up-the-world than what MSFT, Mozilla, and Opera are proposing. It’s not even an exhaustive list. I’m sure you can think of more. Why these have either been not considered or dismissed remains a mystery.

It’s More Complicated Than That

In all of this, we’re faced with an existential question: what right do web developers have to shoot themselves in the foot? Is there a limit to that right? What sort of damage do we allow when some aspect of the system fails or falls out of kilter for some period of time? It’s a question with interesting parallels in other walks of life (for a flavor, substitute “web developers” with “banks”).

Can we show active harm to other browsers from the use of prefixes? The data is at best unclear. Arguing that any harm rises to a level that would justifies destroying the prefixes system entirely is rash. I argued many of the reasons for this in my last post, but lets assume in our mental model that developers respond to incentives in some measure. If, concurrently with achieving as-yet un-managed distribution, Mozilla et. al. implement others’ prefixes, what should we expect developers to do in response? After all, they will have reduced whatever tension might have been created by content that “looked wonky” and, where standards exist, will have reduced the incentive to switch to the standard version.

Now lets play the model one more turn of the wheel forward too: assume that Chrome or Safari (or both!) act in good faith and contemplate removing the -webkit-* prefix support for standardized features at a quick clip…and Mozilla doesn’t. You see how this quickly leads to a Mexican standoff: web developers won’t stop using prefixed versions because those are the way you get 100% support (thanks to Mozilla’s support for them); vendors won’t un-prefix things because others who squat their prefixes will then have a compatibility advantage; and nobody will be keen to add new things behind prefixes because they can no longer be assumed to be experiments that can change. Lose, lose, lose.

Some on the other side of the debate are keen to cite game theory as a support for their course of action, but the only conclusion I can draw is that their analysis must be predicated on a set of user and developer motivations that are entirely unlike the observable world we inhabit.

A Call To Reason, Not Arms

Based on a better understanding of the landscape, what should the various parties do to make the world better for themselves now and in the long run and for the web as a platform?

• Web Devs: first, do no harm; test in multiple runtimes, pointedly including a “fallback”. Then enhance with prefixes. Do not apologize for giving some (or even many) of your users a better experience. That, after all, is your job. But know this: prefixed properties are not supported, will go away, and when something you didn’t test the fallback for falls over, it’s your fault.
• Browser Vendors: invest in advocacy and distribution enhancing moves for your product before threatening to blow up effective standards policies. If you’re going to implement a prefixed version, please have a different opinion or push to ram a standard through to Recommendation ASAP. Incompatible right-hand-sides help developers understand that things are still evolving. DO NOT squat on prefixes. It’s both relative ineffective and will make developer’s lives harder when they want to legitimately move to standard or support your prefixes.
• Vendor CSS WG Reps: get it through your heads, you’re behind. It’s not quaint and it’s not excusable. The platform needs more powerful CSS features, and stat. It’s long past time to start stealing good ideas from the pre-processors. Appeals to a lack of manpower to implement must never block others and shouldn’t block standardization, so please stop making them. If you care about the platform’s success, let those who are able and willing to take risks do so.
• The CSS WG (as a whole): get the lead out. It’s not exclusively the W3C’s fault that things are slow, but the current MTTR (Mean Time To Recommendation) is still glacial. It is unreasonable to expect vendors to drop prefix support immediately upon standardization, but the W3C has a role here to advocate for quick sunsetting. Daniel Glazman is, as ever, right on most of this, but more can be done to streamline the process post CR.
• The WebKit Project: Add build flags to allow WebKit-based products to enable/disable vendor prefix support independently.
• Chrome/Safari/Other-prefix-supporting-browsers: Sunset prefixes as soon as is practicable post-standardization. Similarly, don’t ship prefixed features you’re not willing to be on the hook for via your reps to the CSS WG. Disabling them may be painful, but it’s the only good-faith thing to do.

Endnotes

I’ve left a lot out of this post, but it’s too long already. I do truly hope it’s the last I write on prefixes because, as I said up front, we have much bigger fish to fry. Stat. Prefixes do work, they’re essential to delivering a future platform that can compete, and yes, they should be torn down at the same pace they’re erected.

A few things that folks have asked about as tangents to this debate:

• It’s never a good thing for there to be homogeneity in the experimentation phase. The explicit goal of the prefixes system is to enable diversity of early opinion and fast coalescing around the best answer, thereby enabling the writing of a standard which is likely to need less revising and iteration. Diversity provides some value, the market tests the alternatives, and we deliver the most value we can over time through the standard version. It has always been thus, but prefixes make it less risky…assuming we don’t start stepping on everyone else’s toes.
• If the reasoning behind prefixes is to set up and tear down large-scale experiments, iterate, and collect feedback then Lea’s -prefix-free approach and PPK’s -alpha-*/-beta-* proposals are equally counter-productive and should be avoided at all costs. Making prefixes less painful to use reduces the natural incentives for migrating to a standard while blindly assuming the same right-hand for a future standard version as we have for some prefixed versions is plainly idiotic. What were they thinking?
• @-vendor-unlock is only slightly smarter, but in every possible way inferior to CSS Mixins. Would that the WG spent as much time on Mixins as they have on this prefix kerfuffle.
• Yes, I was in Paris when the CSS WG F2F was happening. No, I wasn’t at the meetings. Duty (Chrome for Android) called.
• If you’ve read this far, congrats. You may be the only one. I’ve been assured by CSS WG delegates that nobody cares what I think, which statistically seems to just be rounding down by a tiny bit. Fair enough.

Update: Michael Mullany of Sencha adds epicly good, epicly long context about what causes developers to target UAs and what the incentives that’ll change their minds about supporting a given browser really are.

Thanks to Frances Berriman, Jake Archibald, Tony Gentilcore, and Tab Atkins for reviewing earlier versions of this post. Errors of fact and form are all mine, however. Updated occasionally for clarity and to remove typos.

<!--[if lt IE 9 ]>
<p>Your browser is <em>ancient!</em>
<a href="http://microsoft.com/ie">Upgrade</a> or
<a href="http://www.google.com/chromeframe/?redirect=true">
   install Google Chrome Frame</a> to experience this app.
</p>
< ![endif]-->

The redirect=true ensures that once the the install completes, users are automatically redirected back to your site (slick, huh?) and the conditional comments keep the prompt from being shown to folks with modern browsers.

At the top of your document you’ll still need to add the header or meta tag to your apps/pages to opt-in to Chrome Frame rendering:

    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

Couldn’t be easier, and if you’re using a starter kit like the excellent HTML5 Boilerplate, it’s already in there!

Nearly forgot…

So, why, you might ask, did it take this long from showing user-mode at I/O to get this to the the world?

Good, if convoluted question. The answer is long, complicated, and involves a harrowing-yet-seamless transition of hundreds of millions of Chrome installs to a new installer infrastructure, but I’ll skip to the punch line: millions of users won’t even have to download Chrome Frame to install it. Chrome Frame’s quick-enable mode is available on every system that has Chrome installed — even if Chrome isn’t being used as the default browser — which means that for many of your users installing Chrome Frame can be nearly instant. No download, no traditional install process. Just “activate”, “accept” and those users are on their way back to your site to experience the HTML5 goodness you’ve built.

If you’re contemplating adding a prompt to your site or app, know that you’re not alone either. As promised, GMail is asking all IE 6 and 7 users to upgrade or install Chrome Frame. A growing list of sites like Angry Birds couldn’t have been built without assuming Chrome Frame as a solution to “the IE problem”.

Chrome Frame is all about turning HTML5 from a “someday…” prospect to a reality for your very next project, even if you’re deploying to users and organizations that can’t join us here in the future by adopting modern browsers. Only the trailing edge has been standing still, and now that we’re all free of it I can’t wait to see we build.

The web is about to get better a whole lot faster.

Update: Erik Wright informs me that we don’t even need the prefersystemlevel now! Post updated to reflect this.

Like Chrome, GCF is on the 6 week release cycle, so expect features like per-user install and even faster starts that are arriving in the Dev Channel to become available quickly.

So what are you waiting for? Say no to legacy baggage and start saying yes to HTML5 and the future by adding the GCF header/tag to your sites and apps. It’s nearly zero effort. When you’re comfortable, you can add a prompt and free yourself to build sites and apps against only the modern web. When you do, you’ll see how fast and productive web development can really be. I promise you won’t want to go back. Thanks to GCF, you won’t have to.

Indeed, if you installed GCF prior to the Beta release, you would have been on the Dev version, but when the Beta was pushed, all existing GCF users were moved to it as a one-time transition. That means you might not be getting the new shiny features we’re pouring into Dev as quickly as you anticipated…but fear not! There’s a new Dev Channel Release available. If you’re developing sites with GCF and you want to see what’s coming, I highly recommend getting and testing against this version. You won’t be moved to Beta again, so this uninstall/reinstall is a one-time change.

As folks begin to use and test with GCF, one of the first many try is to use the OptInUrls registry key to over-ride a site’s preference about which renderer to use. This tends to cause confusion and spurious bug reports because many sites employ server-side User-Agent detection to send different content to different browsers. Since GCF uses IE’s network stack and reports a slightly modified IE User-Agent instead of Chrome’s UA, server-side detection may send IE-specialized content instead of Chrome-friendly content. This includes many large sites like Yahoo, GMail, and most sites built with GWT’s server-side detection.

These are not bugs.

Those sites are working as intended and GCF is operating correctly. What’s happening, instead, is that by adding sites to the OptInUrls list that do not understand GCF, you’re breaking the contract at the core of how GCF works: existing content works the way it always has. It’s only when you’re sure that a site is sending browser-neutral content (usually when it’s your site) that you should ever add a site to the OptInUrls list for your system or organization. As usual, if you’ve got questions about GCF that aren’t answered in the FAQs or docs, you can ask them on the Google Group for the project. The whole team is subscribed to the list and we’re focused on helping you make awesome apps, so stop by, say howdy, and let us know how it’s going.

Back when I did security for a living, I quickly noted a distinction between those who saw things as white vs. black and those who viewed things in risks. White vs. black is the mentality of the attacker (you only need to pwn one system, not every system) and of green defenders who can’t yet distinguish severity or haven’t been thought to think about defense in depth. A risk-based view of security pays a lot more attention to questions of who you’re securing a system against and for how long. In this world view, threats are risks to be evaluated and mitigated, not a constant stream of sky-is-falling crises. A risk based view says “yes, the sky might be falling somewhere, but what are the odds it’s falling on me? And even if it is, what’s the worst that can happen?” If the likelihood is high and the severity is high, spend a lot of time on it. When you view security in terms of risks to be mitigated, you make very different tradeoffs. If you think you need to (or even can) control and eliminate every risk, than you might be tempted to build brittle systems. If, on the other hand, you acknowledge that humans are invoked (and are fallible) and that sometimes things break, you might give up a little control to get to a better place on average and be willing to suffer some minor setbacks on the way there.

The difference between Chrome’s update system and that of other browsers is that the Chrome updater turns the dial all the way in the direction of mitigation, treating the window of vulnerability as the most important factor in the risk of an attack. It’s more important in this world to mitigate an attack than to have asked the user if they want their system to be updated. Is there any other right answer to that question for most users than “yes”?

Here’s where the knives come out: rational people with very different perspectives often want totally different things. System administrators for large organizations – tallented people whose job it is to personally assess and deal with risks – may disagree with this policy since it introduces new risks which they can’t effectively mitigate. The Chrome answer to these concerns has been to treat them as the special case they are. You can easily get the standalone installer that doesn’t include auto-update, but it’s not something that’s advertised on the main download page. Why? Because it’s not what will keep most users secure.

The default Chrome update model is designed around the perspective of the average Chrome user. Not the vocal minority of those who know enough to build Chrome from source or even for corporate IT administrators. Their needs are real, and their perspective is valid, but it is not common and should not dominate the discussion about what is best for the majority. If we’ve learned anything through most GUI Open Source projects, it’s that developers have a hard time empathizing with the needs and skills of most users. This shows up in many places, but perhaps the most curious place of all is the extra confirmation box that asks you if you’d like to have a secure browser or an insecure browser. To anyone but an IT administrator or a developer, it’s not a legitimate choice, it’s an opportunity for failure with the deck stacked against you.

I’m glad the Chrome team has prioritized security through convenience at the expense of the illusion of control. It’s one of those things that’s obvious once you change your perspective. Too bad it’s not nearly as easy as it sounds. Everyone’s selling their point of view, but there are predictably few buyers amongst the already enfranchised.

Hat tip: Glen’s excellent ChatGraph.

Frankly, not much, but if I had to nit pick, I’d note that the worst part of Google Analytics is the ga.js script that does the actual tracking of content. It’s not bad, in and of itself, but it tends to load slowly. There are several reasons for this:

• Another DNS lookup to resolve http://www.google-analytics.com/. This DNS entry is likely to be “warm” given how frequently ga.js is used on the web, but as Jim Roskind explained on the Chromium blog, it’s the outliers that kill you.
• It’s kinda big. At 9K on the wire (22K unzipped), ga.js is kinda chunky for what it does most of the time, namely tracking a single page load.
• The default instructions are bone-headed. They direct you to do a document.write() which is a blocking, synchronous operation WRT page loading. This is tres dumb. Reasonable people should just include ga.js with a <script> tag, but nearly nobody does. Turns out that sane defaults still matter.
• Load times seem totally random. As with DNS lookup, ga.js‘s latency varies wildly. This isn’t backed up by anything empirical, but many pages feel blocked by ga.js for a near eternity.

So how to fix this? Dojo 1.3′s dojox.analytics.Urchin to the rescue! Given that I was going to be including Dojo on the page to do other things anyway, I can use 1.3′s new Urchin system to help amortize the cost of using Google Analytics. The code running on this blog now includes the following code (more or less):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<script type="text/javascript"
  src="http://ajax.googleapis.com/ajax/libs/dojo/1.3/dojo/dojo.xd.js">
</script>
<script type="text/javascript">
  dojo.addOnLoad(function(){
    setTimeout(function(){
      dojo.require("dojox.analytics.Urchin");
      dojo.addOnLoad(function(){
        var tracker = new dojox.analytics.Urchin({
          acct: "UA-XXXXXX-X" // your tracking # here
        });
      });
    }, 100);
  });
</script>

You can see the real thing by looking at the bottom of this page which pulls in custom.js which includes this logic. Pete Higgins blogged about how the module works when he first wrote it, and the strategy is to load Dojo from a CDN (since the page wanted it for other things) and wait until after the page has loaded to include ga.js. This delayed loading ensures that the page is responsive before we start doing anything related to tracking. The nested calls to dojo.addOnLoad show how we can wait for one set of modules to finish before kicking off another group, and in this case we also wait until after the page is responsive to load dojox.analytics.Urchin. This module further delays loading of ga.js, meaning that it doesn’t matter how long it takes for things like DNS to resolve and for Google to serve ga.ja since it’s not ever blocking the user.

Looking at the “before” and “after” shots in firebug gives you some idea of how this technique can really make a difference:

onload waits for ga.js

using dojox.analytics.Urchin, we can get a responsive page and *then* track usage

We get page tracking and the user gets an interactive page faster. Rad.

The truly dispiriting thing, though, is how badly cmd.exe still sucks. I fully admit that my personal programming proclivities are not normal, but to be reasonably productive I need a Unix-like shell, a terminal that works (can be resized, has reasonable VT100 emulation, etc.), and the ability to fix the “Caps Lock” key to do the right thing – namely, have it fire the “Ctrl” key instead. This is all relatively straightforward to do on Linux and OS X. Here’s how I got it done with Windows:

Do the MSFT Patch Dance

Make coffee?

Install Cygwin

We’ve all done it a thousand times. This’ll make 1001. It’s kind of comforting that the Cygwin home page hasn’t changed perceptibly in nearly a decade.

Get SharpKeys

Instead of fugly registry hacks, SharpKeys allows you to map the dreaded and useless “Caps Lock” key to something actually useful. If your key-mapping preferences swing some other way, SharpKeys can likely handle that too. Not sure why it’s not built into Windows, frankly.

Set Up Puttycyg

Having cygwin is nice, but having a terrible shell with Cygwin? Not so nice. Enter Puttycyg, a small hack on the venerable Putty SSH client for windows that provides an option to launch a local Cygwin session in lieu of connecting to another system.

Once I extracted it and ensured the Puttycyg directory was in my windows PATH, I created a desktop shortcut to the putty.exe included in the distribution and configured the shortcut (right-click) to read:

"C:\Documents and Settings\slightlyoff\Desktop\puttycyg\putty.exe" -cygterm -

And then set the “Shortcut key:” to be:

Ctrl + Alt + T

Now, whenever I want a fully functional shell from my desktop, I just hit that key combination and it All Works (TM).

To my great surprise, I’ve been at SitePen two and a half years. It has been nothing short of wonderful which may explain why it doesn’t feel like it has been that long. When I look back at what we’ve accomplished it’s also surprising that we’ve been able to do all if it in such a short timeframe. Between the huge client projects and re-building Dojo from the ground up, it has been busy bordering on nutty.

It already makes me sad to leave behind working with the SitePen crew, many of whom I helped to hire in and who I count among my closest friends. But I won’t be entirely gone. I’ll still be contributing to Dojo in my new role, if less frequently. Not that it’ll slow the project down any. Pete, Bill, Adam, and Tom have Dojo well in hand and have been driving things forward at a furious rate. Dojo has always been a team effort, and I’m excited about the improvements coming in 1.3. I’ve gotten a dis-proportionate amount of the credit over the years (and not enough of the blame), and as Dojo evolves from here it will continue to be because companies like SitePen, Uxebu, AOL, and IBM have all been able to contribute to make it happen and that leaders like Pete Higgins have stepped up to lead and teach and learn with the community. My deepest thanks go to Dylan and SitePen for having let me be a part of that process on a daily basis for the last couple of years.

So what could possibly pry me away from such a sweet, sweet gig at SitePen?

In a word, Chrome.

Three years after many of my friends joined Google, the appeal of getting to fix the “web as platform” problem from the inside has finally proven irresistible. There’s much to do, and the WebKit platform seems like the best shot that we have (collectively) at forging a future that’s not just open, but also markedly better. At SitePen I’ve had the chance to make the web a better place through Dojo. At Google I’ll have a chance to do it from the browser itself.

To the friends I’m leaving, it was a privilege to work with you. To the friends I’m joining, thanks for your trust and faith.

I’m incredibly excited about the SitePen Dojo Toolbox AIR app that just launched. I’ve been using early versions for a couple of weeks now, and in that time it has earned a privileged place on my desktop. Being able to make local builds without delving to the command line is something that I’ve wanted to be able to show new Dojo users for years and this tool finally makes it easy. There’s more work to do around configuring the profiles themselves, but the new tool demystifies many of the build configuration options significantly. Having a searchable API viewer available is also a godsend. Huge props to the team that put it together!

Edit: I forgot to note one of my favorite parts of the project, namely that because the Dojo build system is written in JavaScript (thanks to James Burke‘s awesome work), the build system in the Toolbox doesn’t require Java. Instead, SitePen was able to port the few Rhino dependencies in the build tool to work with the native JavaScript engine in AIR. It’s a minor thing, but it speaks to the excellent engineering behind Dojo’s tooling and the power of having actual web-native technologies inside a desktop app.

I’ve been concerned a bit that it may appear as though Joe joining SitePen may carry with it the perception that the Dojo Foundation is an arm of SitePen in some way or that DWR will now need to become Dojo-centric. Luckily neither is the case, although reading assurances to that effect on this blog should be taken with a grain of salt. The Foundation has an open door for deserving projects which need a good legal umbrella and don’t want a lot of process or formality, and we’ve extended personal invitations to many non-Dojo-centric projects over the years to join (including direct competitors).

For anyone still worried about the DWR/DF arrangement, working it backwards from both perspectives should yield some comfort. It does very little good for Dojo to be shoved down someone’s throat by the choice of some orthogonal tool in the same way that it would be tremendously foolhardy for the Foundation to lose its independence in any way. Neither would be very meritocratic and in particular the independence of the Foundation and its track record of providing a level playing field is most of what it has going for it. To that end, putting DWR at the Foundation and not under the getahead legal entity should help to make the distinction between commercial interest and community development even clearer than it previously was.

An umbrella organization to help support projects in meeting their goals is the under-appreciated bit of what separates successful stand-alone projects from projects which can’t escape the yolk of either a closed development process or a sponsoring company that just can’t let go of assumed control or brand affinity. Having your work backed by a legal entity is essential if you’re not going to pick a GPL-ish license, but having that entity be a brand-neutral known quantity helps get projects adopted by organizations which have both lawyers and some experience with OSS. For component software like DWR, Cometd, and Dojo that’s nearly all of the users which an OSS license alone won’t convince. The independent nature of the Foundation also isolates users from the employment decisions of key contributors. Through the Foundation, Dojo’s licensing has survived wholly in-tact through changes in employment status of nearly all of its most prolific contributors.

Having “external” committers, a reasonable process for minting new ones, and a peaceful atmosphere where developers can build trust along with software isn’t rocket science but it does require some amount of prioritization of those concerns over personal and corporate directives. We’re not perfect at this at the Dojo Foundation, and we haven’t yet encountered the wrenching attempts at “brand drafting” which Apache deals with on a regular basis, but we’re committed to keeping the process as hands-off as we can and working to ensure that the umbrella doesn’t imply more than it really provides.

Our door is open. All that we require of new projects is that all committers on the project sign a CLA, that the lineage of the code be “clean” (within reason), that the project community is relatively healthy, and that you can convince the existing committers that yours is worthy of Foundation support. It has always been the intent of the Foundation to host projects that have nothing to do whatsoever with Dojo and it’s my sincere hope that the DWR announcement drives this home, but we’re not going to leave it to chance. More on this in a forthcoming post.

Until then, my congrats again to Joe and the entire DWR community. Thanks for giving the Foundation the opportunity to make good on the trust you’ve invested in us.

Lets take a look at each of those in order.

First, the obligatory IANAL disclaimer. That I happen to deal with some of the licensing policy stuff for Dojo does not mean that you should trust your project’s licensing doctrine to my (mis)understanding of the law. At Dojo we do retain lawyers to help answer our questions and I strongly recommend you do the same. You might even be able to get some advice that’s worth more than you pay for it. Lastly, lots of other stuff is much more important that licensing in the future of your project. Getting these bits right won’t matter if your software sucks, so make sure that’s your first priority.

How the heck should I pick a license?

My personal take on this is that you should pick a license for your project based on your personal goals with regards to the software you’re giving away (or maybe not giving away). If your goal is to get your code into the most people’s hands with the least fuss, go BSD/MIT/Apache-ish. If you care about software freedom at the expense of potential users, or if you want to be able to sell your code later without real competition, go (L)GPL-ish. Those are gross oversimplifications of the choices involved, but as we’ll see they largely line up on-side because they imply that you sort of have an idea of who you want your users to be. Is your project a success if it is the basis for commercial products that you’re not involved in? Or do you personally want people to know that you did that? If Microsoft (or whoever you cast as “evil”) starts using your code, would you be upset or happy?

These decisions are inherently social. They lay the groundwork for how others perceive you, your code, and the people you may attract to your project. Much like a university degree, these perceptions may have absolutely no basis in fact other than that you did, indeed, pick a particular license. The things others assume about your project as a result are very likely to be wrong, but like a lot of statements of values, you should pick a license whose social contract implies something that you want your project to be when it grows up. By doing this you’re setting a flag which potential contributors to your project and consumers of your software will look to to get a feeling for “what is it?”.

At the Dojo Foundation, our licensing goals are explicitly tactical: adoption over control, 100% of the time. We’ve picked the AFL and BSD licenses because they are “friction free” in conjunction with the rigor of the Foundation (which I’ll get to). They set the flags for “commercially friendly”, “anyone can play”, and “politics unwelcome”. Are those things strictly true? Probably not. But they say a lot about the ideals we’d like Dojo Foundation projects to embody. Other organizations have very different sets of goals, and their licenses reflect that. The FSF’s licensing policies throw the flags of “your rights matter”, “politics acceptable”, and “commerce tolerated (on our terms)”. In the particulars of any individual project these sets of flags may be indistinguishable from each other, but how others perceive them has an impact upon who will show up to “play” at your project.

So what does all of that mean for how you should pick your license? It implies that you need to figure out why you’re giving your work away. Is it just a way to get adoption (BSD-ish) or is it The Right Thing To Do (GPL-ish)? Once you’ve figured that, the rest is just mechanics. There’s no wrong answer, but there are consequences for doing the mechanics wrong.

So does it matter which one I pick?

As you may have gathered from the preceding comments, it may matter which license you chose. Or not. Some very large organizations won’t touch code that is of (L)GPL origins if they can help it, but those same organizations will back hugely successful GPL projects when they’ve already won the market. Other organizations and individuals prefer (L)GPL-ish code.

Reasonable people apparently disagree on which style is right, so maybe we should rephrase the question a bit: “How can I ensure the success of my project through my licensing decision (insofar as it matters)?”

First, you’re going to need to consider the cultural impact of licensing. You’re more easily going to be able to contribute to a Debian-centric project if you use the GPL since that community “gets” and appreciates the freedoms embodied by that license. You’ll have a tough rode to hoe, though, if you want to then take that code to FreeBSD and expect it to be “blessed” without a license change. Ensuring that your code can be mixed with other code that you care about is often down to licensing, so look around and see what others are doing before you pick. If your boat can rise in their tide, it’s a good bet you’ll want to use their license too.

Secondly, consider commercial use. Big Open Source companies like IBM and Sun have a strong preference for clean BSD-ish code. It’s no wonder, then, that enterprise software vendors are beating down the doors of the Eclipse and Apache Foundations to get their projects accepted and released under those licenses. Doing so makes them both presumptive “winners” in those communities for their target feature sets, but it also signifies that the code is palatable for many of the largest corporate consumers.

Next, remember that your project isn’t just trying to court new users, it’s also trying (hopefully) to find new developers to pitch in and make it even more awesome. If you pick a license that people don’t know or aren’t familiar with, you raise the bar to acceptance in both groups. Going with a “well known” or “name brand” license can help steer your clear of those shoals, even if the license itself isn’t as strong or accurate as the one you’d prefer to use.

Lastly, remember that licensing may be a no-op. Even if you throw all the right flags with your licensing, your code may still suck or your UI may be totally unusable. See Debian vs. Ubuntu for a graphic demonstration of how energy spent on licensing may be utterly wasted. No matter how culturally deft and no matter how clean your code, if your app/toolkit sucks, you’re not likely to win.

What do you mean by “clean”?

Cleanliness usually boils down to “what are the odds that someone can sue me down the road for using this code?”. No one can know those odds up-front, and success (or distribution, if you define “success” differently) increases the likelihood of legal antics. You, the OSS project lead/maintainer may never be directly affected by these kinds of machinations, but your potential users think long and hard about them. Dojo is still a tiny fish in the Open Source pond and even I field questions from corporate legal counsels on a weekly basis. Each of those messages means someone is paying lawyerbucks to figure out if they feel comfortable using Dojo. That’s a lot of money. Clearly it’s got to be worth it to them to have peace of mind.

So how do we keep code “clean”? The short answer is “by knowing where it came from and having a license to back it up”.

If you pick a GPL-ish license, a lot of that solution is baked into the license itself. Since no one can create derived works that are under less permissible (or more permissible) terms, and since the GPL speaks to patent as well as copyright rights, code under these licenses usually only needs to have some sort of public lineage (anonymous access to project SVN will do) to allay fears of lawsuits coming out of the sky.

Assuming that you have the right to put that code under such a license in the first place, that is.

The biggest weakness not solved by any OSS license (yet) is that things which are assumed to be under a particular license may not be “cleanly” given. For instance, a well-intentioned employee at Big Co. Inc. decides in her spare time to get involved in Dojo. Now, generally, Big Co. has an employment agreement with some really nasty language about “intellectual property”, and the take-away is usually that no matter what our mythical employee thinks up while she works there, it belongs to the company. Usually these things are written in such a way as to ever cover what she does on her “own time”.

So what happens when our well-meaning (but not a lawyer) employee wants to start working on OSS in her spare time? If she donates code without first getting approval from the company, the odds are pretty high that the project will then be (potentially) screwed, no matter how “share alike” the license may be. This is a Bad Thing for the project. Most OSS projects guard against it by either asking very pointed questions of new contributors or by getting a legal contract in place from the contributor which makes them state in a legally binding way that they are actually giving a license to the code to some other entity (typically a Foundation) and that they have the right to do so. That last bit is important. By having folks attest to the fact that they either own or have the right to donate the code in question, the project has done its best to make sure that the right-to-donate hole is filled. It also prevents “malicious contributors” (think SCO) from claiming later that they didn’t actually mean to donate the rights and IP embodied in the code to users of your project.

These contributor contracts, or “Contributor License Agreements” have been made prevalent through the hard work of the Apache Foundation. Notably, though, they require a legal entity on the other end of the line to sign a contract with. Hrmmmm….

What about those Foundations?

Foundations like Eclipse, Mozilla, Apache, and the FSF all provide legal resting places for rights embodied in code. By acting as umbrellas against personal liability amongst contributors and by providing a legal structure in which to execute license agreements and CLAs, Open Source Foundations are a handy (but time consuming) legal structure that successful projects have employed to help promote their adoption. Generally organized as non-profit corporations, Open Source Foundations are time-consuming to set up, but may be essential to ensuring the cleanliness of your project’s code, particularly if it’s under a BSD-ish license like Apache, Eclipse, or MIT.

So should you set up a Foundation for your new project?

Probably not. Setting up a Foundation is a PITA, and the odds are pretty high that you don’t want much out of the Foundation…at least not until the project is successful. Your best bet is to start your new project inside the umbrella of an existing Foundation. If that’s not possible, you might be able to re-purpose an existing CLA to be between contributors and yourself (personally) to ensure that you hold all the rights to all the code or simply not allow much in the way out outside contributions. I’ve used both strategies in the past with success.

Alternately, if you’re going to try to get your project accepted at an existing Foundation (recommended!) sometime in the future, you may just want to ask that all new contributors sign a CLA with that foundation before submitting code to your project. Until your project is accepted under that Foundatin’s legal umbrella, you’ll still be out on a limb, but at least you’ll have set the stage for success later and may unblock development in the short term. I don’t know the legal ramifications of this approach, and you might want to augment it with assignment of copyright to you personally as well. Regardless, getting your project out from under your own name (and therefore, personal liability) is a Good Thing (TM). Find a good home for your code ASAP, and if that means setting up a new Foundation, so be it. When you’re drowning in paperwork, though, remember that you were warned.

Shameless plug: the Dojo Foundation wants to help young projects avoid the licensing fate of many of the currently popular JavaScript toolkits which didn’t pay enough attention to licensing up-front. We’re easy to work with and provide just enough of an umbrella to help grow your community without suffocating a small project with process. If you’re starting a new OSS web project and need a good home for it, send me mail. The Dojo Foundation may not wind up being the right home for your code, but we’ll try to help however we can.

Dual licensing: good or bad? And can I change the license later?

Firstly, if you’ve already released some code and you’ve taken patches from someone from a mailing list (without a CLA), or if you’ve borrowed code from someplace and didn’t think too hard about it because it was “obvious” or “open source too”, you can stop reading here. Unless the patches are blindingly trivial (think less than 5 foreheadslappingly-obvious lines), your project is no longer “clean” and you’ve probably already shot any hope of being able to dual-license or re-license in the foot. Since the code that you’re integrating from other people starts with their copyright, you can’t just change the terms of their licensing decisions retroactively any more than they can say that your software is governed by the Windows EULA without your permission. If you haven’t taken patches or if you think you can easily track down your contributors and get them to sign CLAs, you’re in a very good place. Either way, now’s the time to figure our your strategy for accepting contributions.

The CLA that Dojo requires of all contributors provides the Foundation with a broad license to the rights over donated code. Original authors keep their original authority over their copyright and patent interests, but they also “cut us in” on the ground floor. The CLA gives the Foundation the ability to repurpose the donation as it needs to (under the oversight of the Foundation Board) by providing sub-licensable access to both copyright and patent for the code. Practically speaking, this type of arrangement allows an Open Source project to “dual license” without asking every contributor for permission all the time. In the case of the Dojo Foundation, we use that power to offer Foundation projects under BSD-ish licenses which promote adoption, and other licenses on a one-off basis where it will encourage adoption. We wouldn’t be able to put the Perl bits of Cometd under the Artistic and AFL licenses if the Foundation didn’t have a license to all the rights for that code.

At the Dojo Foundation, we use the rights which we’ve accumulated through CLAs to do what’s necessary to make Foundation projects successful. If that means that the dominant license in the Python community is the General Foo License, we’ll probably adopt it alongside the AFL for Python code we release to make sure it’s got the maximum chance for success in that community. That doesn’t mean that dual-licensing is always a good idea, though. It can create confusion with users, and many people associate “dual license” with something very different.

Other kinds of organizations do dual-licensing for different ends, but use much the same mechanism. By controlling all of the copyright and patent interests in a bit of code, many companies that provide their products under Open Source licenses can also turn around and charge users of that software money under a different license agreement. Projects like MySQL, QT, and EXT can’t accept “external” patches for the bits that they sell, and they manage that tension with their community in different ways. In the case of MySQL, you can pay for packaged, tested releases with support and extra features. This allows the community to develop the core as GPL’d software without needing a CLA for every little change. QT and EXT, on the other hand, have pursued strategies which put the entire project development process behind the “rights wall”. This means that they can offer the whole thing with particular guarantees to commercial users and even proscribe commercial use without purchase of a license. What affect this has on communities (often negative) and on the quality of the software itself (often positive) is a matter for a different article, but if you’re thinking about dual-licensing in order to start a business around your code, just know that you’ll need to decide early on to keep control or else you’ll be looking at the services/support/add-ons model for making money from the project.

As for changing the license on your project, note that you’re going to require all the rights to all the code in order to make a full license change. Think of it as adding a license (dual licensing) and dropping one. Your project will need to have accumulated CLAs or have a “rights wall” in order to pull it off. Alternately, you can ask everyone who ever contributed for permission. Oof.

This is a pain. Can’t I just put it in the Public Domain?

It’s unclear. At Dojo, we’d put all of our code into the public domain if we thought we reasonably could. We’ve even asked our laywer (at length) about this. Her reply has left us feeling squeemish enough about the legal underpinnings of the Public Domain to question whether or not we can actually use it. If you’re looking to get your new project adopted widely, I’d recommend against trying to go this route. Until the situation is much clearer, a liberal license like BSD, MIT, or Apache + a CLA system seems to be the best way to provide users with the broad rights the public domain would imply and also the assurance that they’re not going to get sued over it.

I know i’ve glossed over a lot of the pertinent legal issues in this post, but hopefully it’ll help new project leads help themselves before it’s too late. If I had to sum it all up to someone asking my advice, I’d just say “find a Foundation that will take your project when it’s still very small”. By the time your project is medium-sized, it’s probably too late and that’s the very time when setting the right flags may matter most. Setting them won’t guarantee your project success, but you’ll never get hit but the bus of destiny if you don’t stand in the middle of the road.

To be honest, SitePen is usually hiring, so why the blog post? Because I’m hiring for a SitePen R&D Associate. This isn’t your average programming job. Not only will all the work from this new position be released as Open Source software,it’s a self-directed research job. Combined with SitePen’s completely-virtual structure, you can work on what you feel is important and live wherever you want.

Read on for the full description:

Position

R&D Associate (title negotiable)

Description

SitePen is a fast-growing services company with deep roots in Open Source web software and an ongoing commitment to give back to the Open Web. The problems we solve for clients sit at the intersection of Computer Science and Interaction Design while cutting across a wide variety of problem domains. As an R&D Associate at SitePen you’ll be responsible for investigating and developing solutions to the thorniest problems in real-world web application development and since everything you do will be Open Source, your impact will be both meaningful and lasting.

Some topics currently of interest to SitePen include:

• web framework scalability
• parametric CSS
• ES3/ES4 implementations across VMs
• publish/subscribe messaging and scalability
• web-based interaction design/analysis tools
• Open Data portability and metadata normalization
• browser-based data visualization

But those are just the problems that keep us awake at night. What we’re really interested in is hearing about how you’d like to make a difference in the evolution of the web. At SitePen, you’ll have the freedom to pursue your interests and a mandate to work with broader communities to make your ideas reality.

Required Qualifications

• contributor to at least one Open Source project (active committers preferred)
• fluent in one functional or scripting language (C experience a plus)
• must be able to author technical papers
• must be comfortable presenting and defending work to groups of various sizes
• permanant legal right to work in the United States

How To Apply

Send a plain-text email to “alex@sitepen.com” with the subject line “R&D Associate Application”. In the body of the email, please explain why you think you’d be good for the job, what research interests you would like to pursue, and if you have one, a link to your website/blog. Please include links to your Open Source involvement and note major contributions (planning, design, features implemented, research contributed, UI/UX/IxD, etc.). Also, either include a link to an online resume or attach one in plain-text or PDF format.

There is no deadline for application, but the earlier you apply the better your odds.

Benefits

• Senior Engineer grade pay
• Comprehensive health insurance
• All work product Open Source

Additional Information

• Location: anywhere you damn well please. SitePen is an entirely virtual organization.
• Travel:10-25% travel, depending on personal choices regarding conferences and symposiums. Presenting papers and speaking on your work is encouraged.
• Job Type: Full Time
• Reports To: Director of R&D (Alex Russell)

Uniquely for an R&D job, there are no minimum education requirements. We only care how effectively you can advance the state of the art on the Open Web. If that sounds like a calling you can get behind, I’d love to hear from you.