[dojo-contributors] what is the raison detre for dojo 2.0.

Dylan Schiemann dylan at dojotoolkit.org
Thu Oct 11 10:05:35 EDT 2012

Hash: SHA1

Ken said this perfectly... it's not that we don't need excellent
marketing, it's that the decision for what 2.0 needs to be should be
based on the needs of the product, not on the marketing "war".

on 10/11/12 6:06 AM (GMT-07:00) Kenneth G. Franqueiro said the following:
> On the contrary, to pretend this *is* a competition (and one that we 
> should "win") is naive to the extreme, and I am glad that Dylan and
> Ken have put their 2c in on this issue (just as myself and Colin and
> Brian and maybe a couple of others did during last night's meeting,
> sorry if I'm forgetting names).  I was seriously losing sleep last
> night over the fact that other people are apparently losing sleep
> over this imaginary "war".
> As Dylan said, we should be focusing on our APIs and on solving
> problems people need to solve.  If we can come up with marketing to
> put us in a better position in the end as a result *of* that, that's
> great.  But the point remains that a lot of people don't *realize*
> they need Dojo because they don't even understand or fathom the
> problems it will solve for them, and as I said in my previous e-mail
> on this thread, that's a hard marketing task to solve - not
> necessarily an up-front design task.
> Trying specifically to compete with something that we are not
> directly in competition with (because Dojo serves a far broader and
> more powerful set of purposes) is a waste of effort, when what we
> should be doing is trying to repeat the success of what we did 7+
> years ago - figure out what people need to be successful, based on
> the technology that exists today and might exist tomorrow - years
> before anyone else figures it out.  Unfortunately, predicting the
> future as well as Dojo has in the past doesn't always win marketing.
> If we try to win by specifically picking a war, we've already lost.
> We need to win based on the virtues of our toolkit - we just need to
> figure out how to better get those virtues across.  At the same time,
> we need to come to terms with the fact that Dojo is for people who
> understand that JavaScript is Serious Business and want to build
> great things, and is not for people who don't like to think (which is
> squarely where jQuery wins biggest in the marketing department).
> Should we put effort into vetting our APIs to make sure they're as
> easy to use as we can fathom?  Absolutely.  But we shouldn't fret
> over users who don't "get it" and have no interest in "getting it",
> because we also have many who DO get it, and they deserve our
> continued support.  On the other hand, if we can do better to help
> educate and guide users who don't yet "get it" but *do* show a clear
> interest in doing so, that is absolutely something we should strive
> for.
> --Ken
> On 10/11/2012 8:29 AM, Rawld Gill wrote:
>>> From: Dylan Schiemann
>>> Frankly, I don't care at all about competing with other toolkits.
>>> I'm tired of hearing about how we can win the war. Why are we at
>>> war, rather than working hard to grow with the community at
>>> large?
>> And I'm tired of investing time only to have a significant customer
>> base complain dojo it "too complicated,  too big, etc.; that's why
>> we use ...." And how many times have we heard one of our key
>> contributors tried to convince management to use dojo...and
>> failed.
>> There is much less to be learned looking at our successes than our
>> failures. Alternative toolkits win in some areas because we have
>> either (1) failed to provide a better solution or (2) failed to
>> communicate the better solution that we have. So, I want to
>> understand * where we have lost * why And then fix it.
>> To pretend this is not a competition is naive in the extreme. I
>> don't care what you call it--"war" or "growing our customer
>> base"--we cannot continue to cede market share because "we're so
>> sophisticated and advanced that those customers are too stupid to
>> use us"...which has been the attitude of some.
>>> Rather than focusing on building the one walled garden yet
>>> completely open toolkit to rule them all, Dojo and the Dojo
>>> Foundation should be thinking about how we can take our knowledge
>>> and make both our toolkit and any others that share our open
>>> ideals better.
>>> What I personally care about is creating a collection of tools
>>> (a toolkit) that continues to make it simpler to build well
>>> architected and highly performant apps, and that is easy to split
>>> up and scale up.
>>> The focus needs to be on the APIs and tools and features that we
>>> need to deliver on, and growing our community by becoming part of
>>> the bigger community. We didn't start Dojo to win the war, we
>>> started Dojo to change the web and make it more open and
>>> collaborative.
>> What do you think "winning a war" means? To me, it means winning
>> the dominate market share. You don't want to do this? Why are some
>> so afraid to say, "we want to be the best and we want everybody to
>> use us"? ...which is a longer way of saying "we want to win".
>>> We need to focus on building an amazing foundation, pushing
>>> things forward, and people will continue to notice. We've had a
>>> lot more interest lately as people take another look at Dojo, and
>>> interesting group of new people that have become involved, or
>>> that want to see where 2.0 goes to see how they can help.
>>> One idea I've had involves sort of having the foundation be a bit
>>> less about silo-ed projects, and more about areas of interest
>>> that one or more projects can come together to collaborate on.
>>> For example, this might look something like:
>>> * Utilities * Modules * Language improvements and shims * UI
>>> (widgets, themes, mobile, effects, vector graphics, etc. ... this
>>> one is probably too big) * Data/MVC * Server-side
>>> integration/REST/Real-time
>>> with the idea being to encourage projects with overlap to more
>>> easily collaborate across projects where it makes sense. People
>>> could either be involved with projects, or just involved in an
>>> area of interest, or both. It might make the foundation a more
>>> inviting place to encourage collaboration, etc.? But more
>>> importantly I think, it would encourage projects to perhaps
>>> share some common APIs, so that each microtoolkit isn't
>>> reinventing the wheel.
>>> The goal for Dojo 2.0 should not be to try and take on the weight
>>> of the world and do everything, but should be to provide the
>>> right set of tools and community and vision so that our users can
>>> do everything with Dojo as part of that story.
>> What, precisely, are you saying we should not do? I keep hearing
>> these kind of fuzzy statements, but nobody will tell me exactly
>> where we are planning on not competing.
>>> Until we have that, I don't care about the competition, because
>>> it frankly doesn't matter and it's the wrong place to put the
>>> attention of an open source project as we're trying to plan
>>> towards 2.0.
>>> Looking at the various suggestions, those from Colin, Rick
>>> Waldron, & James Burke mesh most closely with what I think our
>>> priorities should be for 2.x, as well as what I wrote of course.
>> I don't see how any suggestions made so far by the collective
>> community are inconsistent with competing against any of the other
>> popular toolkits. If that's what we're doing, then we better
>> understand where we've failed in the past and fix that before
>> throwing another bunch of code out there and hoping it will work
>> out better this time.
>> --Rawld
>> _______________________________________________ dojo-contributors
>> mailing list dojo-contributors at mail.dojotoolkit.org 
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> _______________________________________________ dojo-contributors
> mailing list dojo-contributors at mail.dojotoolkit.org 
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list