On Tue, Nov 14, 2006 at 07:04:45AM -0600, Aaron Spike wrote:
Jon Phillips wrote:
Bryce can point you to it...yes, we need way more news and publicity (and more releases to garner more publicity IMO)
I've put a lot of thought into how we can increase the number of contributors to the project. I've got some ideas, which I'll enumerate down below...
But first I should mention that I think raw PR by itself - while important and useful - is not sufficient for getting development work done, and has some risk of being counterproductive. I actually think Inkscape has been doing fine at getting visibility (both with formal PR and word of mouth). But as a tool for getting contributors, publicity is sort of a two-edged sword: For every new contributor we get, we also gain increased usership with the correpsonding increase in labor to support them (answering questions, handling bug reports, etc.) Also, we can expect that new users will stick around and continue to require support, whereas new developers may or may not stick around; thus publicity could actually end up increasing the workload on existing developers, rather than offloading them.
I think that we probably actually get a fair amount of "passers by" who _could_ contribute, but for one reason or another don't. Some possible reasons they might have:
* Feel that they don't have... - adequate coding skill - knowledge of inkscape internals - time - authorization - an itch to scratch
* Perceive there is insufficient "ego gratification" - Want full authority over their work - Want recognition/respect
* Fear of having work critiqued/rejected/ignored - Embarrassment - Worry of being shut out - Risk of wasted time - Risk of arguments
* Assumption that other developers will get to it eventually - Feel their time is best spent on other priorities - Seems like an obvious need, surely someone will get to it - Posting a bug report seems "good enough"
So, the key to gaining more developers is to find ways to solve or work around these concerns. Fortunately, many are just misconceptions.
Here are ideas:
0. Invitation to participate ============================= The most effective way to get people involved is just to give them an invitation to try implementing it themselves. E.g., I often ask, "Can you code? Why don't you give it a shot?"
I thing this approach shortcircuts a lot of the above worries or something. In any case, it's easy to do, and it seems to work more often than not for Inkscape.
Be sure to make it a friendly, open ended invitation to do something they have a strong itch to do. Avoid pressuring them or imposing expectations - this can just scare them away.
Note that invitations can be directed at old developers as well as new ones. Sometimes expressing interest in something the old developer was working on, plus encouragement to continue can be enough to stimulate them to do more.
1. Newbie training program ========================== Organize a structured education effort where novices can learn and practice skills in a comfortable environment, where risks are low, and where they feel they are gaining something tangible for their time.
This would require core developers to devote some time to teaching, which includes preparing training material, designing projects, answering questions from students, and doing evaluations.
In exchange for the training, the student would be expected to complete one or two class projects. These projects would be geared towards solving real Inkscape bugs or rfes.
2. "Paint by Number" projects ============================== I think the reason our roadmaps, bug/rfe trackers, etc. haven't worked at getting more people contributing, is because oftentimes the procedure for doing the fix or implementation is extremely obscure.
From my own personal experience, the codebase can be quite difficult to
understand until someone gives you some clear guidelines. Sometimes 90% of the effort is just figuring out *what* to do.
But if an experienced core developer put in 1 hour just describing how to do a task, then later someone with less experience could use that description as a map to doing the solution.
It may seem that this would be inefficient - it may take less total manpower for the developer to just do the work directly. However, for the core developer, they could probably outline several tasks in the time it'd take them to complete one. Even more importantly, the end benefit is that the new developer gains expertise that may enable them to contribute more in the future.
IOW, "Give a man a fish, he'll eat for a day; teach a man to fish, and he'll eat for a lifetime."
An interesting experiment would be for a core developer to spend a day going through bugs or rfes and rather than investigate them, to simply describe the steps they themselves would take to do it, and encourage others to give it a shot. Then later look back and count how many of the tasks were able to be completed by someone else. I bet we'd see a large net gain.
3. Code documentation ====================== As mentioned in the previous item, just figuring out *what* to do can be the bulk of the challenge. Inkscape's rather sparse code documentation tends to contribute to this problem.
I make a habit when studying the codebase, to add comments for each function I go through, to describe what it does and what its inputs and outputs are. This helps me because I have such a crappy memory, but also it should end up helping decrease the amount of work others need to figure out what to do. Maybe reducing the effort from 90% to 80%. ;-)
4. Break functionality out into libraries ========================================== With any coding project, the sheer size of the codebase can pose a hinderance to looking under the hood. The more code, the more intimidating it must seem to a potential new developer.
A possible solution to this is to move core code out into separate (either new or existing) libraries. In addition to reducing our core linecount, libraries can have better defined interfaces. It can also be given sufficient independence from the core codebase that it satisfies the need for control that some desire.
A good general purpose library could be shared between multiple open source projects, and in theory would be able to pull in contributions (or at least ideas) from a wider group.
Of course, there are a whole host of trade-offs to having code in a separate library, so it is important that this be undertaken only if there are dedicated developers and clear boundaries.
5. Emergency calls to action ============================= I put this one last because while can work, it's pretty snarky. As they say, sometimes it's the squeaky wheel that gets the grease, so sometimes in order for a wheel to get greased it first has to get a lot squeakier.
Thus, sometimes putting out complaints about how terrible something is, and how it is being completely ignored, can be effective at drawing people in - particularly 'firefighter' style personalities who like being the hero. Or threaten to take some undesireable alternative action (like closing the project, dropping a buggy feature, etc.)
There is often some political price you must pay for taking this approach: Threats can engender bad will; forcing decisions can risk alienating key developers; making demands can make you seem like a tyrant. Also, there is always the risk you will be seen as "crying wolf", and future calls you or others make may simply be ignored.
Bryce