A Little History

A group of JavaScript developers starting talking about the future of DHTML. Alex Russell (original creator of NetWindows), in looking for assistance at Informatica, started talking to many of the members of the DHTML community, culminating in the April 25, 2004 email titled "Selling the future of DHTML". David Schontzler (Stilleye) spent a summer working at Informatica, and Dylan Schiemann (currently at SitePen) also joined Informatica. The first lines of code contributed to Dojo were done by Alex and Dylan with the support of Informatica. There were many other community members that were active participants in shaping the direction of Dojo, including Joyce Park (mod_pubsub), Tom Trenka (creator of f(m)), Mark Anderson (bustlib), Leonard Lin (who suggested the name Dojo), Aaron Boodman (YoungPup, before GreaseMonkey and Google), Simon Willison (before Django, now at Flickr), Cal Henderson (Flickr), and Dan Pupius (animation, now at Google).



After several months of discussions on the ng-dhtml (now dojo-developer) mailing list about licensing, choosing a name, coding conventions, build tools, server configuration, and requirements (what would this Dojo thing actually become), we began writing code and setting up a foundation to own the copyright to the Dojo code. After writing some initial specs, the first Dojo code was written and/or ported into Dojo in early September, 2004, by Alex Russell and Dylan Schiemann. In addition to new code, early contributions and inspirations were made from NetWindows, burstlib, and f(m). In March, 2005, we started to receive contribtions from other Dojo members, and by the end of 2006, we have completed four major releases, with over 300,000 downloads to date, and contributions from more than 60 developers and companies.



The Dojo Foundation was established in 2005 as a 501c(6) organization. Currently, Alex Russell serves as the president, and Dylan Schiemann is the Secretary/Treasurer. Voting of issues is done by +1/-1 by the contributor mailing list.



Over the first two years since that initial e-mail discussion, Dojo has grown in a manner that we could have only dreamed of. Through several major releases, and extensive contributions by the community, Dojo has become a much more diverse and flexible toolkit in a shorter amount of time than any of its predecessors. We were originally just hoping to build a toolkit that would learn from the limitations of toolkits of the day, make real use of DOM-capable browsers, and build something with real capabilities and a real software engineering approach. Our goal was to avoid reinventing the wheel so that we could move on and make new mistakes.

Developing a Module

All the magic that is the dojo module system takes place in the src directory. Take a look in your distribution at the various files an directories. You'll notice that there are many directories and many js files. Now look inside the directories. Most of the directories have a file named __package__.js along with many other js files.

There are several ways to develop a module. Basically, it all has to do with how you plan to divide up your code. If you're writing a small module which needs the full source code to work, you'll want to put a js file in the base of the src directory with the same name as your module and a .js on the end. This can be called by putting the following in your source code:

dojo.require("dojo.packagename");

If you want to split your module into several unrelated files (called "resources"), you'd create a directory an put each part into a seperate js file. The only way you could call this is by using a deeper require statement, as follows:

dojo.require("dojo.packagename.subpackage");

If you want to split your module into smaller pieces that sometimes rely on each other, then you'll want a __package__.js file. What this file does is specifies default resources to load depending on the environment. Open up some of your files and see how it looks. There are two important functions: kwCompoundRequire and provide.ÂÂ

The first function specified which packages to load in an object with keys consisting of the different environments. An example is as follows:

dojo.kwCompoundRequire({

    common: ["dojo.package.first", "dojo.package.second"],

    browser: ["dojo.package.browser"]

});

The second function tells dojo that your module was loaded properly.

dojo.provide("dojo.package.*");

In all the other js files, you'll need to have a require statement to inform dojo that the package pieces have been loaded. This is also true of the files in the base of the src directory:

dojo.provide("dojo.package");

Developing For Dojo

The Dojo team is always looking for new code contributions. Please see the resources below for more info:

• Contributor License Agreement
• Individual - http://dojotoolkit.org/dojo-cla.pdf
  
  
• Corporate (if you work on Dojo for your employer, you will most likely need to file this one) - http://dojotoolkit.org/files/dojo-ccla.pdf
• Style guide http://dojotoolkit.org/docs/js_style_guide.html
• Inline code documentation - http://dojo.jot.com/WikiHome/Code+Documentation
• SVN http://dojo.jot.com/WikiHome/Getting+Started+With+Subversion

Filing Bugs And Patches

The Dojo bug database is located at http://trac.dojotoolkit.org. You need to login with your dojotoolkit.org user name and password before filing bugs. If you don't already have an account, you can sign up for one here.

You don't need to sign a Contributor License Agreementto submit bugs, although you do need to sign it before submitting patches. See this post for a fuller explanation of why we insist on CLAs for patches.

A good bug report should include:

• Version of Dojo and build name if applicable
• Browser versions and platforms where the bug occurs
• Error messages displayed (if any)
• A contact address so we can follow-up with you
• Describe the exact situation in which the bug occurs as precisely as possible. Is it reproducible? Did it break in a certain release? Is it still an issue with nightly or subversion head? etc.
• Testcases and patchces are even better.
• Version is the version of Dojo in which you have the issue (usually the current release), and milestone is the version in which it will be fixed. Unless you are a Dojo commiter, we prefer that you leave milestone blank so we can triage it as appropriate.

Getting Involved

Dojo is a community effort, and we need your help!

It's easy to get involved and there are lots of ways you can make a difference:

• Helping other users on IRC and mailing lists
• Writing documentation (like this manual)
• Filing good bugs (and test cases) to help developers solve issues quickly
• Working on widget visual design and HTML/CSS
• Writing translations for i18n support
• Writing patches to fix bugs
• Submitting code for new features

The Road To Becoming A Committer

Inside the Dojo community, there are two "levels" of participants. The word "contributors" refers to anyone who submits documentation, bug fixes, or even bug reports and test cases. This large group of designers and developers who are using the Toolkit to improve user experience are the lifeblood of the project. You can become a contributor by sending in a Contributors License Agreement and starting to pitch in in any of the ways noted above.

"Committers" are a subset of the contributor community who have been granted the ability to make changes directly to Dojo. Committers can also vote in Toolkit and Foundation matters. With that power comes significant responsibility. Committers are required to act as the front line of defense against IP pollution, follow community development standards, merge or reject patches sent in by contributors, vote, participate in weekly IRC meetings, and work on criticial release issues. Becoming a Dojo committer is considered to be an honor as it means you've impressed a discerning group of hackers with the quality of your contributions and feels that they can get along with you.

So how do you go from "contributor" to "committer"?

The first step is to file a Contributors License Agreement (outlined below). Once it's been received, start contributing! There's no hard-and-fast rule for how many contributions it takes before you are considered for committer status, but in general you'll need to close important bugs, demonstrate that you are willing to participate in the community (mailing lists, IRC, etc.), and show that you respect community norms and standards. Committers make recommendations to the Foundation Board regarding people they think should be considered for commiter status, so working with a committer to assist him/her with issues that are important for an upcoming release is a great way to ensure that your contributions are integrated and that you will be considered for committer status in a timely fashion.

The Contributors License Agreement

Most forms of contribution aside from providing support to other users requires that you sign and submit a Contributors License Agreement (or "CLA" for short) with the Dojo Foundation. All additions to this manual, for instance, require signed CLAs.

There are two versions of the agreement:

1. The Individual CLA
   • use this version if you're working on Dojo in your spare time or can clearly claim ownership of copyright in what you'll be submitting
2. The Corporate CLA
   • have your corporate lawyer review and submit this if your company is going to be contributing to Foundation projects

Summarized, the CLA asserts that when you donate fixes or documentation, you both own the code that you're submitting and that the Dojo Foundation can in turn license that code to other people. While the text on the agreement suggests that you fax it in, you can submit a valid CLA by:

• snail-mail to the address on the form
• fax to the number of the form
• or an email'd digital photograph of the signed document to <carrie at dojotoolkit dot org>

Sending in a CLA is a one-time thing, and once it's done, you're in the clear to start contributing to all Dojo Foundation projects! To be effective, though, you need to know a little bit about how contributors coordinate their work.

Mailing Lists

Most decisions, support, and coordination happens on the project's mailing lists. The dojo-interest mailing list is our most active list, with over a hundred messages sent to subscribers on some days. Everything from how best to theme widgets to complex debugging of applications happens here. There are several web interfaces onto this list, including the searchable gmane archive and the Nabble interface which allows for participation via the web UI.

Project mailing lists are broken up more-or-less by function. The full list:

• dojo-interest
  
  "The big one", this list is ground zero for the Dojo community. While very high volume, it's the best place (aside from this site) to find answers to your Dojo-related questions. Remember to search the archives, though! With over 15-- subscribers, someone has probably already run into (and solved) the same problem before.
• dojo-accessibility
  
  Developers and users alike use this list to discuss strategies for making Dojo widgets easier to use with assistive technologies such as screen-readers, high-contrast-mode displays, and magnification systems.
• dojo-jobs
  
  JavaScript devleopers are in short supply, and as always, so are great employers. The dojo-jobs mailing list tries to help Dojo-clued employers and job seekers alike find each other. There's no charge to post a resume or job listing.
• dojo-checkins
  
  Notifications of every change to the code of the toolkit are sent to this list along with notifications of changes to bug tickets in the project's bug tracking system.
• dojo-soc
  
  Dojo sponsors students that participate in Google's Summer of Code program. Discussions on this list center around project status updates, how to best tackle problems, and other Summer of Code related matters.
• dojo-contributors
  
  This semi-private mailing list is by invite only, but don't let that scare you from requesting to be on it if you're contributing to the toolkit. Just send mail to "alex at dojotoolkit dot org" explaining why you should be on the list. Some of the best minds in the DHTML world (including all the Dojo committers) are on this list, and discussion tends to be highly-technical. Dojo Foundation votes take place on this list as well, and the archives are public and searchable. While trying to keep the signal/noise ratio high, Dojo is firmly committed to staying a transparent community.

General mailing list ettiquete holds on these lists, but here's the short list of do's and dont's in case your youth wasn't mispent reading mailing list archives like our was:

• DO search the archives and the FAQ for an answer to your question before posting to the list. The odds are much higher that you'll get a response if your message shows that you respect the time of those who can help you with your problem.
• DO assume that the person on the other end of the discussion isn't out to make you feel stupid or hurt your feelings. Things got much more smoothly in a lossy medium like email when everyone assumes that other folks are just trying to help.
• DON'T tell others that they shouldn't be asking a question because you don't think it's Dojo related. If the question involves JavaScript then there is almost always a Dojo solution just a few keystrokes away. Let the community leaders and senior (I use this term to identify time contributed to the community) list members police inappropriate topics.
• DON'T send email in HTML format. It's fine to send both HTML and plain-text versions of the same message, but never send only HTML-formatted mail.
• DON'T post something if you think it will offend the other person. Civility and common decency is expected of all. No exceptions.
• DON'T set "out of the office" responders for mailing list traffic. Leaving your OOTO message enabled is a fast way to get your list subscriptions suspended.

IRC

Many project developers and users can be found in the #dojo channel in irc.freenode.net. Discussions here range from user support to design of new toolkit features. The IRC channel functions kind of like a "real-time dojo-interest list".

As with email, you should google for an answer to your question before asking it in IRC and civility is expected of everyone.

Every Wed at 3pm PST, contributors of every stripe gather in the #dojo-meeting room (also on irc.freenode.net) for the weekly development meeting. Agendas for these meetings are kept in the main project wiki and the log of each week's discussions are uploaded there once the meeting for the folks who couldn't participate in real time.

Bug Tracking

Most project development revolves around "bugs" or "tickets". All bugs that are found are logged in Trac and subsequently assigned to developers and milestones in which they'll be fixed. This process takes a lot of time and work, and generally speaking the quality of the bug report determines how quickly the issue will get corrected. The best bug reports include detailed instructions on how to reproduce the bug, an attachment that shows the code for reproducing the issue, or a link to a URL that demonstrates the problem.

All bug reports need to include the following information:

• Browser type (IE, Firefox, Opera, ...)
• Browser version
• OS and OS Version
• All steps necessaray to reproduce the issue
• An email address of the person filing the bug or a way to get ahold of him/her.

If you think you've found a new bug in the system, we encourage you to file a bug report on it using the following proceedure:

1. Search the bug database to find similar issues that might have already been reported.
2. If you find an existing bug that covers the issue you're experiencing, ensure that it's reported against the right version, assigned to the right module maintainer, and includes sufficient information to quickly diagnose and fix the bug. Add any additional information necessaray to this bug, potentially logging a comment noting your interest in seeing the bug resolved.
3. If no existing bug is found, create a new one that includes all of the information listed above.
4. If the bug is of significant importance to you, place your email in the CC field so that you will receive any updates that are contributed to the ticket. This also provides a way for the developers to contact you if there is a need to get more information regarding the bug.

The better the bug reports, the faster we can fix things, and improving existing bug reports for issues scheduled to be addressed in the next major release is a great way to get involved and speed improvement in the toolkit. And writing good test cases is just a small step away from writing patches to fix the issues.

Contributing Fixes

In many cases, the hard work of fixing bugs is understanding them well enough to determine what the system is doing and what it should be doing. If you've reached this point in the process of filing a bug report, you may find it just as easy to fix the bug as to report it. What then, though? How do you get your fix merged back into the toolkit?

The easiest way to submit patches to the toolkit is to create diffs and attach them to existing bug tickets. This is a straightforward process, but we'll need a "Contributor's License Agreement" (CLA) on file from you. The process for this is outlined above.

Once your CLA has been received, project committers can review and (potentially) merge your changes to fix the bug. To increase the odds that your patch will be merged, remember the following:

• your patch must conform to the project's JavaScript Style Guidelines
• your patch should be created against the latest version of the toolkit, which you can get from a Subversion checkout (TODOC: notes about SVN, anonymous SVN, etc.)
• All changes should be submitted in "unified diff" format
• A test case should accompany any patches in order to verify that the change actually fixes the issue in question

Special Note For Corporate Contributors

Many companies send inquiries about how to "join the Foundation". While The Dojo Foundation does not have a concept of corporate membership the way some other OSS foundations do, it is still possible for companies to get their needs met inside the community processes outlined above. Most companies who are deeply involved in Founation projects attempt either to hire existing committers or encourage one of their existing employees to become committers. For corporate contributors, the steps to getting involved at a level appropriate for moderate to heavy investement in Toolkit technology (e.g., shipping a product with a Dojo-based UI) are:

1. execute a CCLA with the Foundation
2. plan for IP donations and build a process to ensure oversight inside your organization. The Dojo Foundation is not set up to look out for your IP interests, it is designed to shelter users of Foundation projects from liability related to their use of donated IP. Plan accordingly.
3. find some person(s) inside your organization who will become your public face in the Dojo community. Please select this person carefully. They must be patient, be willing to work with a diverse community, and be familiar with general Open Source development tools and practices. Obviously, you may wind up with any number of committers over time, but selecting someone to attempt to hurdle the bar initially and then help others inside your organization has worked well for other firms in the past. Once you let the project lead know who this person is, the project lead often ensures that he or she is on the right mailing lists.
4. donate code or documentation, pending community review, via bug and enhancement tickets. Code donations must meet community standards including adherence to the style guidelines. A good-faith effort to strictly conform to community norms is greatly appreciated and goes a long way toward building a reputation in the community.
5. as your representatives make a difference in the community, impress the project lead with their involvement and technical ability, and show a willingness to "play well with others", they will be considered for committer status through exactly the same process as non-corporate contributors. The amount of time this takes is variable but is generally measured in months. You are advised not to make product planning decisions based on any timeline for "getting a committer".

Employers should note that committers are individuals, and committer status is not tied to an individuals employment situation in any way. Sponsoring a developer's time on Dojo has historically been the largest factor in reducing the time required for that person to be considered for committer status.

Lastly, if your business needs assistance with Dojo but does not want to sponsor an employee to become directly involved with the project, companies like SitePen, the TurboAjax Group, or even individual committers can provide development and support services that may shortcut the time and effort required to both develop high-quality Dojo code and speed its inclusion in the toolkit mainline.

Intellectual Property Policies

All Dojo Committers are expected to ensure that all code checked into the Dojo repositories is contributed under the terms of a Dojo CLA. Generally this means simply asking a contributor whether or not they've submitted a CLA. If they're not a well-known contributor, you may need to verify this with Carrie Sackett (<carrie at dojotoolkit dot org>).

In some cases, however, it may be necessary to pull in code from other sources. In these cases, Committers should take the follow the steps:

• Before pulling in external code under an alternate license, attempt to secure a CLA and code donation from the original author(s) of the external software. For software which is not from a single developer, this may not be feasible. Committers MUST NOT include external code under CLA if the committer cannot verify that all contributors to the original work have filed a CLA.
• In some cases, it may not be possible to verify the external CLA situation or we may not be able to reach the author(s), it is in some cases appropriate to import an external chunk of code wholesale. This step should not be taken lightly. If you feel like this may be the right step in your situation, you MUST get clearance from your project lead.
• Project leads may only provide authorization to import external code if the code being imported is licensed in a way which is compatible with foundation goals. This may mean that even licenses for which a project itself has received a licensing variance to use. If you are a project lead and you are in the slightest bit unsure about accepting some external code or have questions about the process, do not "wing it". Ask the Foundation's Board of Directors.
• If you receive authorization from your project lead, you MUST create a file with the name "LICENSE" in the directory in which the new code resides. See an example of the format to use here. You MUST also attribute the original author in ALL imported code and note the license under which it is being used.

In most cases, the above system is not likely to come into play and all committers should work to avoid pulling in external code where is it not absolutely necessary.

Licensing

Dojo is Open Source software, distributed by a non-profit foundation which has been set up for the purpose of providing a vendor-neutral owner of Dojo intellectual property. In order to ensure to users of Foundation projects that there is no ambiguity or hidden liability regarding the use of Foundation code, all contributors are required to provide signed Contributor License Agreements.

All committers on Dojo Foundation projects have a vote in Foundation matters. The Foundation is run by contributors, operates in a transparent way, and is funded exclusively by donations. The licensing goals of the Foundations are spelled out in a short document that informs Foundation decisions.

Dual Licensing

The Dojo Toolkit is currently dual-licensed. The preferred license is the Academic Free License v2.1. All Dojo Foundation projects release their code under the terms of this license. It is almost never necessary to exercise the "dual" portion of the dual-licensing terms since the AFL is well written, widely accepted, and incredibly permissive.

For users who face the problem of artificial ambiguity the FSF has created regarding the compatibility of the AFL and the (L)GPL, The Dojo Toolkit may alternately be used under the terms of the BSD License. Both the AFL and the BSD licenses meet the licensing goals of the Dojo Foundation.

This "dual licensing" system is similar to licensing systems employed by projects such as MySQL and the Mozilla Foundation. In almost every case, you will not need to understand the differences between the Dojo licenses or choose anything other than the AFL. If you have questions regarding Dojo licensing, please do not hesitate to contact Alex Russell, current President of the Dojo Foundation.

The Dojo Way

The Foundation

Why A Foundation?

Development of Cometd, the Dojo Toolkit, DWR, and OpenRecord are supported by an independent foundation which is set up as a 501c6 not-for-profit legal entity. Like other Open Source foundations, the Dojo Foundation provides infrastructure for development, shields individual contributors from liability, and helps to ensure that project communities are healthy and successful.



To understand the relationship between the various projects and the Foundation, it helps to understand what the Foundation is responsible for, how the Foundation makes decisions, and what guiding principles shape these decisions. The Dojo Foundation handles:

• Licensing and distribution of Foundation projects
• Development infrastructure
• Sponsorship of new projects
• Project oversight (including accepting new committers)

All of that still doesn't answer the question "why a foundation?" And more importantly, why a new foundation? Having worked on several prior Open Source projects, the project founders realized that a Foundation would be key in helping to avoid legal ambiguity as contributors moved from job to job. Additionally, it was unclear that a pre-existing Open Source foundation would have played host to our efforts in 2004.



Now that the Dojo foundation is several years old and has had a chance to discuss our choices with colleagues from other Open Source foundations, it is pretty clear that any new Open Source project that wants to start a Foundation should think twice. Or three times. In most cases, starting a new foundation shouldn't be necessary, but should it be, finding a good lawyer to assist in the process should be the first step anyone takes.



There appears to be a strong "language affinity" between the communities that spring up at Open Source foundations and that affinity tends to determine what types of projects happen in those communities. In the case of the Dojo Foundation, we inadvertently created the only JavaScript-centric Open Source foundation. As such, we view an important part of our role as being a neutral place where high-quality JavaScript work can get done. The Dojo Foundation today serves as a thin legal structure that attempts to impose as little bureaucracy into Foundation projects as possible while still achieving Foundation and project goals.

Foundation Goals and Principles

The Foundation hasn't adopted a set of official principles and goals at the time of this writing, but historically the Dojo Foundation has worked to:

• Provide a level playing field for everyone who wants to be involved in Foundation projects
• Provide licensing terms that encourage adoption of Foundation projects
  
  
• Help potential contributors and sponsors understand what involvement in Foundation projects entails
  
  

Voting

Decisions inside the foundation are made based on a voting basis handled via mailing lists. Committers on any Foundation-sponsored project are eligible to vote on any Foundation matter and any committer may propose a vote on a topic. Votes are won or lost based on a simple majority of votes cast. Almost all votes take place on the dojo-contributors mailing list, a semi-public mailing list which all contributors to Foundation projects should be subscribed to. Votes are always conducted in a public forum with adequate time provided for all interested parties to cast a vote, traditionally 48 hours from the sending of the email that proposes the vote, but balloting may be left open longer. Since there isn't a formalized concept of membership in the Foundation, voting by committers is the way that the will of the Foundation is assessed.

Licensing

The Dojo Foundation has straightforward licensing goals:

• Encourage adoption
• Discourage political contention
• Encourage collaboration and integration with other projects
• Be transparent

As a result of these goals, and much discussion about how to best achieve them, Foundation projects must:

• Release all code under the terms of the Academic Free License version 2.1 ("the AFL")
• Request a variance from the Foundation in order to release their code under additional licenses. Variances are granted by a vote of Foundation committers and are generally non-controversial as long as the proposed license meets the foundation licensing goals.
• Require that all contributors submit Contributor License Agreements to cover their original works which are submitted for inclusion.
  
  
• Provide a clear disclaimer of origin and copyright ownership when including or distributing 3rd party code. (example)

The Dojo Foundation does not hold the copyright to code and other kinds of IP that are donated. Instead, contributors give the Foundation licenses to those copyrights and the Foundation in turn uses those licenses to distribute the resulting collective works (i.e., the toolkit) under the licenses that the project uses. For example, the Dojo Toolkit is distributed under both the AFL license and the "new BSD" license. Because the Foundation has licenses to all the code involved, it's possible to issue the toolkit under both sets of terms. Users in turn can then decide which set of terms is best for them, but both licenses meet the Foundation's goals. Note that currently, DWR is licensed under the Apache Software License Version 2.

Foundation Projects

Today there are 4 Foundation-sponsored projects:

• OpenRecord
• Cometd
• The Dojo Toolkit
• DWR

Each project releases code independently, has their own development infrastructure (sometimes shared), and manages it's own community, including the introduction of new committers into their project.



Projects may organize themselves "internally" any way they wish, but in general, all critical project decisions should at least be subject to over-ride by committers of the project by a vote on the appropriate mailing lists.

New Committers

There are many ways to get involved in Foundation projects, and becoming a committer is the last and most significant way to get involved. Projects are free to invite new committers any way they see fit. The Dojo Toolkit project, for instance, and historically used a process like this:

1. Contributor starts to help others in project mailing lists and on IRC
   
   
2. Contributor files CLA
3. Multiple non-trivial patches are merged from the contributor
4. Being impressed with the contributions of the contributor, a committer recommends to the project lead that the contributor be offered a spot as a committer.
5. Project lead reviews the submitted patches and consults with others in the community to ensure that the contributor "is a good fit"
6. New committer is added to the project

Other projects might do it other ways, e.g. a vote of all current committers on the project, but whatever the process, the Foundation requires that the process be fair, even-handed, and that the contributor have a CLA on file with the Foundation before they are made a committer.

New Projects

From time to time, new projects are brought under the umbrella of the Dojo Foundation. This has historically been infrequent (less than two new projects per year). New projects are considered on an individual basis, and no one can simply declare a project to be a Dojo Foundation project. A majority vote of all committers on all Foundation projects is required for any new project proposal to be accepted. These votes take place on the dojo-contributors mailing list.



The minimal requirements that any new project proposal should meet are:

• Clear title and license to all copyright and other IP that affects the code base. Since this will all be licensed through the Dojo Foundation once the
  
  
• Willingness to abide by Foundation licensing goals and policies
• Once accepted as a project, all project committers must submit CLAs
• All 3rd party code must be correctly noted
• No variances will be granted for licenses that are not in harmony with Foundation licensing goals (e.g., the GPL).
• No code without committers. The Foundation will not take on "abandonware" projects nor will any projects be considered that don't have a clear group of individual committers who will be dedicated to seeing the project succeed. Corporate-sponsored projects are fine so long as the resulting project will accept committers from outside the sponsoring corporation.

Once a vote on a project proposal passes, the project lead from the new project should propose any licensing variances for a vote and the new project should work with Foundation volunteers to help ensure that their infrastructure needs are met.

The Role of the Board

As noted in the introduction to this chapter, the Dojo Foundation is a thin legal "shim" that binds the various Foundation projects together under a single banner and set of guiding principles. As a result, little formalism is desired or required from the Foundation board or from Foundation projects. The Board simply carries out the will of the aggregated committers. Today, the Board is comprised of:

• Alex Russell, President
• Dylan Schiemann, Treasurer and Secretary

From time to time, votes are taken to elect new Board representatives from among Foundation Project committers.

Project Leads

Every project designates someone to hold the "project lead" position. Currently, these are:

• Brian Skinner (OpenRecord)
• David Davis (Cometd)
• Alex Russell (Dojo)
• Joe Walker (DWR)

Cross-Project Pollination

There is no foundation-wide policy regarding how projects from one Foundation project are accepted into sister projects. It's up to each project to set these policies, but should a deadlock or impasse occur, Dojo Foundation Officers (the Board) reserves the right to settle the dispute.



The Foundation strongly encourages each project to set up a transparent process for accepting committers from sister projects that is less onerous than the process for accepting external committers but leaves the exact details of how this happens up to each project.