Something different in scooby 0.1 than any other product 0.1 is that
it is using relatively new technology which is currently the talk of
town in silicon valley, AJAX.
Matt has stressed to me a few times the lack of open source
javascript libraries and the simple tasks which he has written from
scratch because of a lack of previous development in the area. To top
it all off the AJAX/Web2.0 development crowd is a very blogging heavy
crowd that checks out anything new and cool when it's released. I
think that scooby 0.1 _will_ get looked at by potential developers
and _will_ have some contributions before the next release even if we
do our damnedest to not promote the release or reduce the barrier to
entry.
We need to think about this influx of people touching the product
before release, but _I personally_ think that this crowd is going to
care less about a polished page and more about having decent
documentation and a simple way that they can contribute to the
project. The focus of this and other threads seems to have been more
about polishing and reducing the barrier for end users and less about
the amount of content and policy we have that will be useful for the
people who are probably going to show up.
What we can't do: Create our own Mozilla.org before 0.1
What we can do: Use the extra time that we have, which is very
little, to beef up our documentation and determine a process for our
community to participate in the product.
Regardless of what we intended the release to be, I think we are
going to get more web 2.0 junkies looking at this and wanting to
tinker with it than previously thought.
-Mikeal
On Feb 14, 2006, at 2:09 PM, Mimi Yin wrote:
Lisa,
I think that's a totally valid position to take. But I'm not sure
that was the shared understanding when we agreed to a Feb 14th
release date.
So if attracting volunteers is the no. 1 reason for 0.1, that would
be a significant change in policy that has consequences for both
the content of the landing page as well as how it's laid out and
presented. It may have consequences for general product strategy
and planning. ie. What we decided to get done for 0.1, how much
time we allotted *ahead of time* for things such as the landing page.
1. What kind of developers do we want? Are we ready to deal with?
2. To contribute in what ways?
ie. If someone wrote up a month view or mini-calendar, do we just
stick that in, run with it and iterate accordingly? Or do we need
to massage it into a coherent design first? Both are perfectly
valid approaches. We probably wouldn't do the former for Chandler,
but I'm not sure which one is appropriate for Scooby.
4. How much do we expect contributors to socialize their ideas and
get buy-in on the Scooby list? How do we get contributors up to
speed on our internal processes for doing that?
Without a clear 3 paragraph description of higher level Scooby
product strategy and product vision will we squander early
developer interest? (That sort of happened with Chandler.)
+ Will Scooby be a personal use calendar (a la Yahoo calendar)
+ Will Scooby be a social calendar (a la EVDB)
+ Will Scooby be a "calendar" canvas that can display any time-
based data (a la Google Maps)
If all of the above? What are their relative priorities?
We don't need to answer all these questions before 0.1, but a
public discussion exploring various scenarios and possible
directions would have been in order.
Mimi
====
A minor point: I agree that that the barrier to entry for
contributing to Scooby is lower than it is for Chandler, but by the
same token, there are also a lot more projects to contribute to.
In the end, my assumption would be that open source communities
abide by the same laws of human nature that all organizations do.
+ I want to join a club because it's really important (ie. the
Supreme Court OR A piece of software that lots of people use and
love).
+ I want to join a club because it's really exclusive (ie. the
Supreme Court, going to the Olympics)
Very few people join up and stick around just because they can.
Low barriers to entry are important because you want to make it
easy for people to make contact and you don't want artificial
barriers getting in the way of attracting potentially valuable
contributors (ie. Priscilla's points about how things like bugzilla
make it harder for designers to participate in open source projects.)
However, unless there's a compelling reason to stay (ie. users or a
clear vision), people generally tend not to stick around.
But of course, I would defer to Ted on any of this.
Mimi
On Feb 14, 2006, at 12:41 PM, Lisa Dusseault wrote:
On Feb 14, 2006, at 11:58 AM, Mimi Yin wrote:
When 0.1's release date was reset to Feb 14, we all agreed that
it was:
+ Primarily for internal validation of release process for Scooby
+ While we're at it, we should make cool new AJAX things we're
doing available to people
+ We always want to be attracting developer interest, but it's
not the raison d'etre of the release
I put "attracting volunteers" at the top of the list, myself, for
motivating the release. I have no serious worries about
validating a release process that worked fine for Chandler and
Cosmo many times. I have no problems with making Scooby
technology available to people early but frankly my reason for
doing so is self-interest more than altruism as I think that will
spark more contributions :) We have one code contribution to
Scooby already (some JavaScript date util stuff) and I'd like to
see more.
(The mantra with Chandler has always been, you'll get developers
when you get users.)
This seems not to be the case with Scooby. The barrier to entry
to becoming a Scooby developer may be much lower than becoming a
Chandler contributor because it's a smaller system built in a more
conventional way. You might also consider the existing
contributor to be a "user" as he downloaded the .js files for use
in his own project.
I guess a slightly different angle on this is: When we look back
on the 0.1 release to evaluate whether it was a success, a draw
or a failure, how will we evaluate the release?
If we get any rise in contributions.
If the QA process breaks down OR no one can download Scooby OR
the demo-instance craps out, but 3 new developers wanted to join
up on the project because they're psyched out our logo, would we
have met our objectives? (It's unlikely that the latter would
happen if the former did happen ;o)
I'd say yes.
Now given those goals and their relative priorities, how does a
nicely organized text-based page (html or wiki) fail to
communicate these things?
Don't have an answer to that one :)
Mimi
Lisa
_______________________________________________
Scooby mailing list
[EMAIL PROTECTED]
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/scooby
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
