Generally there's the lossy pipeline of get people interested (1) -> give people a motive to contribute and obtain a first contribution (2) -> foster the contributions into long term collaboration (3).
Right now my primary target for attracting contributors is a synthesizer project. It's pretty interesting from the perspective of all the different working parts, though it does have sizable hurdles to attracting a large contributor base. Most users don't have a strong programming background and as such open source contributions appear to be too difficult (limiting 1->2). Individuals who are familiar with programming may still be unprepared for domain specific problems limiting the 1->2 transition as well.
Most of my attempts are trying to make the software more approachable in general, improving general internal quality, presenting the information to crowds who are familiar with it (multiple conference pubs), presenting it to groups mostly unfamiliar with it (HN/Reddit style threads/AMAs), encouraging community members who work on related sub-projects, using most popular hosting options, posting information on how to get started on the project's web presence, trying to convey that the project offers opportunities to learn skills rather than just apply existing ones, etc, etc, etc.
I'm not really sure which techniques really work or not since results are typically either delayed or are muddled with many different factors.
My newest attempt was based on a suggestion in a HN thread to list possible project roles (similar to if they were job listings). See http://zynaddsubfx.sf.net/contribute.html for that idea in action.
I'm not sure what the next effort will be, though I plan on discussing that on the project's mailing list this next week. Any suggestions or comments are welcome.
> My newest attempt was based on a suggestion in a HN thread to list possible project roles (similar to if they were job listings). See http://zynaddsubfx.sf.net/contribute.html for that idea in action.
A job-like PR aggregator sounds like a stellar idea, the key there is to have well-defined tasks instead of nebulous buzzwords, and knowing how to delegate as a maintainer.
The bottleneck in OSS is mostly lack of objectives and not lack of skill nor free time, given the availability of remote talent.
I'm the person who made the suggestion, just wanted to say that's a great page. It's really helping to figure out what are the desired contributions.
Only mildly related but I was actually looking for a synthesizer the past few weeks (I was just composing stuff I could actually play (and notate) myself before). Part of what was intimidating me about it was the user interfaces of that class of software are always super difficult to get started with... So I guess you gained a new user who does have a programming background!
Yeah, there's a lot of new lingo when you get started with synth interfaces (both from the design and usage perspectives). One of the goals I had for the new user interface was to start integrating more visualizations as a means of giving users feedback on what they're doing.
When you get started out, you just want to mess around an gain an intuitive feel for how to use something and what knobs do. Unfortunately many soft-synths miss out on that user feedback (since it's hard to do right).
Typically supply a tool/app they need. Then hope they want to improve it. My project gets contributions from the community of users. What I would call "Drive by" contributors aren't a thing.
Generally there's the lossy pipeline of get people interested (1) -> give people a motive to contribute and obtain a first contribution (2) -> foster the contributions into long term collaboration (3).
Right now my primary target for attracting contributors is a synthesizer project. It's pretty interesting from the perspective of all the different working parts, though it does have sizable hurdles to attracting a large contributor base. Most users don't have a strong programming background and as such open source contributions appear to be too difficult (limiting 1->2). Individuals who are familiar with programming may still be unprepared for domain specific problems limiting the 1->2 transition as well.
Most of my attempts are trying to make the software more approachable in general, improving general internal quality, presenting the information to crowds who are familiar with it (multiple conference pubs), presenting it to groups mostly unfamiliar with it (HN/Reddit style threads/AMAs), encouraging community members who work on related sub-projects, using most popular hosting options, posting information on how to get started on the project's web presence, trying to convey that the project offers opportunities to learn skills rather than just apply existing ones, etc, etc, etc.
I'm not really sure which techniques really work or not since results are typically either delayed or are muddled with many different factors.
My newest attempt was based on a suggestion in a HN thread to list possible project roles (similar to if they were job listings). See http://zynaddsubfx.sf.net/contribute.html for that idea in action.
I'm not sure what the next effort will be, though I plan on discussing that on the project's mailing list this next week. Any suggestions or comments are welcome.
> My newest attempt was based on a suggestion in a HN thread to list possible project roles (similar to if they were job listings). See http://zynaddsubfx.sf.net/contribute.html for that idea in action.
A job-like PR aggregator sounds like a stellar idea, the key there is to have well-defined tasks instead of nebulous buzzwords, and knowing how to delegate as a maintainer.
The bottleneck in OSS is mostly lack of objectives and not lack of skill nor free time, given the availability of remote talent.
I'm the person who made the suggestion, just wanted to say that's a great page. It's really helping to figure out what are the desired contributions.
Only mildly related but I was actually looking for a synthesizer the past few weeks (I was just composing stuff I could actually play (and notate) myself before). Part of what was intimidating me about it was the user interfaces of that class of software are always super difficult to get started with... So I guess you gained a new user who does have a programming background!
Yeah, there's a lot of new lingo when you get started with synth interfaces (both from the design and usage perspectives). One of the goals I had for the new user interface was to start integrating more visualizations as a means of giving users feedback on what they're doing.
When you get started out, you just want to mess around an gain an intuitive feel for how to use something and what knobs do. Unfortunately many soft-synths miss out on that user feedback (since it's hard to do right).
I really love your instrument! Excellent work. I'll definitely start helping out as soon as my job settles down.
Awesome :)
I look forward to hearing from you.
Typically supply a tool/app they need. Then hope they want to improve it. My project gets contributions from the community of users. What I would call "Drive by" contributors aren't a thing.
need to have better documentation,
and should not have a complex code review/ commit procedure