[CREATE] LGM11 panel proposal: attracting new devs

[Boudewijn Rempt]

On Saturday 19 February 2011, Yuval Levy wrote:
> 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?

Well, not really any accurate statistics. But most seem to come from Google Summer of Code -- and I do not like that one bit. The reason for that is that I've had a couple of interested people coming to me who thought that participating in gsoc was a precondition for being allowed to work on Krita. If that idea spreads, the consequences are pretty bad. Fortunately, KDE has anticipated this, somewhat, by creating the KDE Season of Code, which doesn't do money.

Most active contributors are students; I used to have lots of time because I had a long commute by train, but since I've started working from home, and since my job has become a seven-day-a-week job, that's gone downhill.

We are actively trying to make krita an attractive project by being open, welcoming and even accepting code that isn't totally mature or perfect yet. If it's cool, it can go in, and then we can work together on fixing what needs fixing.

Artists using Krita are an important part of what I consider our team: any artist who joins us and gives us feedback is made very welcome.

> For the past four years Hugin had an good flow of contributors - developers,
> builders, translators, documenters, designers.

documenters is a problem -- and that is purely my fault. I've tried to write the manual on my own, but I don't have time.

> 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
> 


-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org