[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