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.
My understanding was also that 0.1 was an "attract developers
release". Otherwise why would you do a release for something that
didn't work for users? As Mikael pointed out in his reply, there is
reason to believe that some of the core components in Scooby will be of
interest to developers. Making that componentry available a bit more
publically is a good way to attract participation.
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?
I certainly think that we could expect to see bug fixes against the
component level code, and perhaps someone would so something more
ambitious, such as a month view or mini-calendar.
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?
I expect us to have a process where both code and design contributors
continue to collaborate on the direction of the project. If we
actually get people participating in a productive way, that would be a
push for us to bring our internal processes up to speed at working with
people outside of OSAF. People would of course be free to fork our
code and go do whatever they want, but it is really in everybody's
interest for a community to grow up around Scooby.
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.)
Well, I think that we are in a different place between Scooby and
Chandler, and I also think that we can work out a strategy and vision if
necessary (although I don't believe it is a prerequisite for 0.1).
+ 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?
One thing I'll observe is that it is possible for OSAF to maintain its
own priorities while incorporating work done by people outside of
OSAF. Many of the Apache projects have large numbers of committers
from corporations. Those corporations have their own priorities for
those people to work on. It has been a part of Apache's success that
we have a community where the corporations (often more than one) and
"volunteers" are able to collaborate effectively. I think that we at
OSAF can do the same (with OSAF staff in the role of a corporation).
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.
I agree that this sort of discussion would have helped. I'm a bit
concerned that we're only finding out about a mismatch of expectations
at this late date.
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)
Some people look at something and can see "the angel in the marble" and
are motivated to help sculpt the marble until the angel remains. This
is the scratch your own itch thing, which is another motivation aside
from reputation based motivations you list above.
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.
If people feel that they are able to make a contribution, are respected,
and are having fun, they will get involved and stick around.
We have a lot of work to do on all the projects at OSAF, and I think
that there are plenty of places where new folks could come in and make
lots of positive contributions.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
