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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
