Customers

Dojo is cool; it has an amazing amount of really cool technology. But we have to remember, Dojo exists because it has the open-source equivalent of customers. These customers don't pay in money (generally); they pay in man-hours. And, believe me, the old addage "time is money" is in many ways true.

Dojo seems to have two distinct sets of customers:

1. Corporations looking to create production quality applications;
   
2. Individuals and organizations looking to advance the state of web development.

Corporations may also wish to advance the state of web development, and individuals may also want to create production quality applications, but (forgive me) corporations have good reason to want such advancements to remain in-house, and individuals don't have much hope of competing with corporations in creating commercially viable applications.

Dojo, like other open-source projects of this kind, exists as a compromise between the two groups: corporations agree that it's a good thing for the general state of development to advance for everyone to profit, and individuals agree that it's a good thing for the advancements they contribute to be used by corporates for the benefit of users everywhere.

My point is this:

We cannot ignore economic and business arguments when discussing Dojo's future, because Dojo is used and funded by corporations who have a stake in the project.

We cannot ignore community and social arguments when discussing Dojo's future, because Dojo is created by and moved foward by the effords of volunteers.

Vision

Dojo is Javascript, Dojo is Browsers, Dojo is the Web. As such, Dojo's vision is:

• To smooth over platform differences between different Javascript implementations.
• To provide a high-quality Javascript standard library.
• To be included in the next major generation of Javascript platforms.
• To promulgate high-quality interface patterns on the web.
  

Purpose(s)

Dojo (the toolkit) can be used in a number of ways; this summary is based on my readings of other people's emails and proposals.

1. Dojo is a powerful Javascript standard library for building powerful, event-driven, production-quality interactive client-server web applications that successfully run in a number of web platforms (browsers).
   
2. Dojo is a collection of UI tools (Widgets, etc.) enabling successful rapid application development on the web, which is useful for prototyping new applications, and also for building custom small-deployment applications (intranet apps).
3. Dojo is a toolkit for creating and sharing reusable interface components (Widgets) that work on a wide variety of Javascript platforms extending beyond even the web.

It is my impression that, in practice, (2) is built on (3), which in turn is built on (1).

(1) appeals to anyone wanting to create production-quality large-deployment applications. It is, in fact, the largest corporate motivation behind Dojo. (2) comes as a close second for providing an economic argument for supporting Dojo, as prototyping is an incredibly important part of software development.

(3) appeals to anyone wanting to foster a community of web developers contributing to a common pool of knowledge. The community of web developers really like (2), because it eases the burden that lone hackers have to deal with when creating sites on their own.

Needs

Dojo has several things that it requires in order to keep its vision alive, and fulfill its purposes effectively. Dojo exists as a living thing; these needs will affect Dojo's purposes, and it's purposes guide its needs.

1. Corporate support. Dojo requires too much work for a pure volunteer project. This is understood, clearly, because there are a number of paid participants in Dojo.
   
2. Community support. Dojo is too big to depend on the small number of paid sponsors; it depends on the community to be willing to provide bug reports, feedback, and contributed code.
   
3. A larger community. Dojo needs to expand its community and corporate support enough to have a fighting chance of being included in the next generation of platforms.

Because of these needs, Dojo has a number of....

Problems

Yes, that's right, I said it, Dojo has problems. Atually, I think most people can agree on that. It's the list of problems that people disagree on. The ones we can all agree are problems are, I think:

1. Code Bloat. As a project that has been acreting community contributions for a while now, Dojo is oversided and top-heavy. It has a good deal of architecture that doesn't do a lot, and has a large number of unorganized Widgets. This loses a number of corporate supporters.
   
2. Performance. Don't look at me, I didn't say it. Dojo takes a huge performance hit when you try to instantiate a lot of Widgets. This loses both corporate and community support.
   
3. Stability. Okay, if no one else is going to talk about it, I am. Dojo is still pretty young, and has a lot of work to do to make even the core functionality stable on all the supported platforms. This loses community support fast, and corporate support follows.
   
4. Documentation. I know this is being worked on, but Dojo's documentation is horrendous. This makes it impossible for Dojo to pursue a larger community.
   
5. Website. The website does not effectively support the community or the corporate customers. Period.
   

These are all problems that all the developers agree are problems, and are problems that can be worked on. You'll note: lack of features is nowhere on this list. Dojo has no want for features. It has more features than the project can sustain and handle. Which leads me to the troubling problems:

• Feature bloat. As is obvious from any perusal of the code, Dojo is so wide-ranging that it is nearly impossible to actually define what the toolkit is. Yet someone somewhere uses every bit of this code (otherwise it would never have been written).
• Core interface design. Some people are not happy with the direction Dojo is taking, especially with the Widget library. It is becoming another WebForms?, another YUI, yet another widget library implementing all mistakes of the desktop. It is becoming the Dashboard API of the web, which is a "bad thing". Some people believe Dojo suffers from poor comparisons with libraries like YUI. They feel that Dojo should concentrate on providing a better alternative to such libraries, implementing similar widgets and enabling similar projects. They want Dojo to become a better Dashboard API for the web, which is a "good thing".

Camps

There are several camps that have been proposed to address these problems.

1. Split it Up. This is one of the major camps, and has several sub-camps. All of them seem to agree that purposes (1), (2), and (3) should be split into separate projets; some additionally propose splitting (1) up further, and some propose splitting (3) up further. This camp, if I may say so, seems to be headed up by people who are thinking of Dojo's economic value. Splitting it up makes it easier to market the various sub projects as having specific purposes, at which they can excel.
   
2. Open it Up. This is another of the major camps. It doesn't have many sub-camps, because the basic premise is: Dojo, while it has its problems, is fine as it is, because it makes it possible to contribute all kinds of useful web-development code to one central place. It is essentially a community-driven arguement, and goes on to add that Dojo should be opened up with forums and the like to allow people to upload Dojo widgets in a much less restrictive setting than the source tree.
   
3. Drop Stuff Out. This hasn't been talked about as much, but it's one that I personally would like to consider. Since Dojo has more features than it can handle, eliminate some of them.

These proposals are all attempting to deal with the "feature bloat" problem (in one case by arguing its a good quality not a problem). In addition, some attempts are being made to resolve the core design problem:

1. DUI. Many people want to see Dojo's UI subproject directly compete with YUI (note that this is essentially what the current widget library does by and large).
   
2. IxD?. Several people want to see Dojo participate in an effort to actually advance the state of user interface design, rather than giving developers the ability to recreate Applie GUIs on the web.
3. Open it Up. Again, there is a body of thought that wants to open up the design question to the community, and allow people to contribut any design ideas they have in a way that allows anyone else to use them.

Andrew's Synthesized Proposal

It's really hard dealing with all the different camps, so here is what I propose.

1. Split it up, but not too much. Each additional project created makes it more possible to market that product (being a more specific product), but also creates the nasty overhead of actually having to market it.
   
2. Open it up, but not too much. Community support and sharing is important; but it is also debilitating (there, I said it, I'd say it again if I had to). We absolutely should not allow the general community to dictate Dojo design, but their efforts should be visible to other Dojo users and we should allow their efforts to influence Dojo's design. Allow people to upload and share snippets of Dojo driven code, be they a cool charting app or an awesome new widget. (Or lame versions of either).
3. Drop stuff out, but keep it around. There are a number of widgets that are excellent fodder for seeding a code-contribution community. They are dragging down the Dojo toolkit, and are hard to tie to it's core vision and purposes. Make them part of the community pool rather than part of the core toolkit.
4. DUI and IxD?. By "split it up", the three projects I would make are: DUI (the YUI-killer library), Dojo's Core (the Javascript standard library), and IxD? (the cutting-edge interface project).

So what I'm really proposing is the following:

1. A community for sharing Dojo code;
2. Dividing the Dojo source tree and build process into three parts: Core, DUI, IxD?. BUT! Keeping the code in one central repository, to enable contributions across the three projects. (The Core would contain the Widget infrastructure, but not any actual widgets; obviously the latter two projects depend on the former).
   
3. Remove extraneous widgets (exact list to be decided later) from the DUI collection, and (with the authors' permissions) use them to seed the Dojo code community.
   
4. A marketing strategy that involves:

• promoting DUI as a better version of YUI, for rapid-application development, which is (I fear) the most understandable and commonly desired use of Dojo, and hence the flagship marketing concept;
• promoting the Core as the amazingly and uniquely powerful tool for building ground-up production-quailtiy applications for the web;
  
• promotin IxD? as the "hip new interface design" for the web;
  
• using each of the projects to promote the others, i.e., DUI is cool but IxD? is better; DUI and IxD? are built on the Core; the Core makes it possible to build almost anything from DUI to IxD?; etc.