[CREATE] LGM11 panel proposal: attracting new devs
Yuval Levy
create07 at sfina.com
Sat Feb 19 09:24:17 PST 2011
On February 19, 2011 06:49:40 am Boudewijn Rempt wrote:
> Krita is one of the few libre graphics projects that
> doesn't really have a dearth of developers. I'm sometimes worried about
> the churn, and about the way my day job interferes these days, but getting
> new people doing cool stuff hasn't been a real problem for us since ~2003.
do you have statistics/ideas where they come from?
For the past four years Hugin had an good flow of contributors - developers,
builders, translators, documenters, designers.
Most coders come, implement one or two nice features, and go. I would
estimate 50% are Google Summer of Code students and 50% come "out of the blue"
with an entry on the Tracker such as [0] or [1]. Many (if not most) of them
are not very active in the (users) community and I assume the motivation is
"scratch your own itches".
What I think has helped attracting them is empowerment, recognition, and
formalized processes:
EMPOWERMENT:
* Documentation: help get them started quickly with build documents like [2]
maintained by community members for community members on all platform. Almost
every user with basic typing skills can get started. Most maintainers of the
build documentation are actually not coders. We still lack proper code
documentation, although we do work hard on it, asking coders to document their
code (doxygen) and trying to collect information in a way that it is
accessible to new contributors.
* Repository Write Access: we have been very very very liberal with SVN write
access. Since we moved to Mercurial this is embedded in the tool.
* Our processes are empowering. You do not need to ask for permission, just
do what you think is right. The documented processes give you an idea of what
will happen - see below.
RECOGNITION:
* I have taken extra care to update our authors list; and to display it in the
about dialog.
* I got some industry players (hardware manufacturer) donate gear in
recognition.
* From the next release (hopefully timed for LGM) we will have new user-
contributed artwork in every release.
PROCESSES:
1. Release frequently. This gives contributors a sense that their
contribution will become useful soon.
2. Manage integration. Make the process predictable to contributors so that
they know what will happen next after they have done their effort. In our
case it is documented in [3].
3. Make yourself redundant! Every process I have run for the project, I have
taken extra care to document so that anybody with basic typographic skills can
step in my shoes. If they don't, it just mean that the process is not useful;
and on a larger scale, that the software is not useful.
This, I believe, makes it for a receptive environment. It still does not
address motivation. One great idea I have heard about for motivation is to
encourage academics to use the software as a test-bed for exercises. Students
can do what they want in their own "exercise branch"; and get graded on it.
The community is left with code that it can harness and integrate into the
main code line if appropriate.
+1 for a talk/presentation/panel/discussion on the subject.
Yuv
[0] https://bugs.launchpad.net/hugin/+bug/679708
[1] https://bugs.launchpad.net/hugin/+bug/679753
[2] http://wiki.panotools.org/Hugin_Compiling_Ubuntu
[3] http://wiki.panotools.org/Development_of_Open_Source_tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/create/attachments/20110219/c28069ca/attachment.pgp>
More information about the CREATE
mailing list