[Ica-osgeo-labs] How much code should Open Source leaders write?

[Cameron Shorter]

Here is a summary of conversations between Charlie Schweik and myself, 
leading to what I think could be some really interesting Open Source 
Research. Anyone interested?

http://cameronshorter.blogspot.com.au/2015/12/how-much-code-should-open-source.html

Which is more effective for building an open source project? Do you 
write code, or engage with the community?
My team are regularly asked variants on this question when called in to 
review software systems, which include open source extensions and have 
been out-innovated by the open source community.
Just writing code leads to a development team of one. It works, but is 
slow. The illusive promise of open source is the potential to attract 
external developers. But to attract and retain developers you need to 
connect with them, talk with them, support them, encourage them. You 
need to help them achieve their goals, which might be only slightly 
related to yours. And hopefully, after all that, they might contribute 
back. It is a tough ask, which is probably why5 out of 6 open source 
projects are abandoned 
<https://www.thecommonsjournal.org/articles/10.18352/ijc.397/>.
So what percentage of time should be dedicated to communication in order 
to build a successful open source community? My gut feeling, after a 
decades contributing to open source, is around 20% to 40%. But I'd love 
to find some solid research to back this up.
An extensive study by Schweik and English, sponsored by the U.S. 
National Science Foundation,researched the factors that lead some open 
source projects to ongoing success, while others become abandoned 
<https://www.thecommonsjournal.org/articles/10.18352/ijc.397/>. Key 
attributes of successful projects included:

  * A clear vision
  * Leaders who lead by doing
  * Good documentation and a quality web presence
  * Fine scaled task granularity, making it easier for new users to
    contribute

However, I'm unaware of studies, including Schweik and English's, which 
have mined communication archives, such as email lists, to correlate 
communication styles with project success. Why is that? Communication is 
the lifeblood of any organisation, so you'd think that by now there 
would be evidence based guidance on optimising our communication 
techniques. Especially considering how much value could be easily mined 
from these archives.
Here are some indicators I'd like to see mined from communication 
archives and then correlating with project success rates:

  * What is the frequency, response-rate and response-time to conversations?
  * What is the proportion of experienced verses in-experienced people
    initiating and responding to topics?
  * What is the "signal to noise" ratio? Do people write concisely?
  * Is communication constructive? Do topics lead to practical actions
    or implementations?
  * Is communication respectful and supportive? (This might be hard to
    measure, but I'd argue that practicing mutual respect is key to
    community building.)
  * How much time do people spend coding compared to the time they spend
    communicating? (This could be roughly calculated based on lines of
    code written vs lines of email composed).
  * Which communication mediums are more effective? Email, IRC, twitter,
    blogs, other?
  * What styles lead to communities becoming more or less engaged?

Based on results of the information mining, I'd expect to discover that 
successful open source projects:

  * Have core contributors responding quickly to community questions
  * Have a community who are supportive of each other, resulting in many
    community members having the confidence to answer new user questions
  * Having new ideas being initiated, discussed and then implemented
    from many members of the community


-- 
Cameron Shorter,
Software and Data Solutions Manager
LISAsoft
Suite 112, Jones Bay Wharf,
26 - 32 Pirrama Rd, Pyrmont NSW 2009

P +61 2 9009 5000,  W www.lisasoft.com,  F +61 2 9009 5099

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geoforall/attachments/20151222/7c337211/attachment.html>