Crowdsourcing has had a pretty big impact upon most industries, but perhaps software development has seen a bigger impact than most.  The rise of social coding sites such as BitBucket and GitHub have transformed the way software projects are undertaken.

Such sites offer developers the opportunity to collaborate on projects with other coders from around the world.  The success of the sites has been overwhelming, with millions of developers contributing to applications on all manner of topics.

A recent paper set out to explore whether there were any fundamental differences between successful projects and unsuccessful ones.  The study, conducted by researchers from Nara Institute of Science and Technology in Japan, combed over some 300,000 software projects on GitHub to try and understand the things that contributed to success.

As with any software project, the initial stages will often see a group of developers who have an idea for a project come together to work on it.  These are known as internal developers, and they will update their software via a series of ‘commits’.  Add these together and you get a sense of the activity levels on a project.

External developers can then get involved in the project by following its progress (or starring it on GitHub).  The number of stars therefore is a useful proxy of the projects popularity within the community.  External developers can also suggest changes to the project, which is known as a pull request.

The researchers downloaded all of this data across 300,000 projects and began trawling through it to uncover those successful traits.  One of the first nuggets the researchers found was that the number of internal members was key to both the activity levels, popularity and sociality of a project.  The higher the number, the higher each of those corresponding traits became.

Alas, it also emerged that the more internal members there were on a project, the fewer commits each of those people made to the project.  Indeed, it transpired that the most efficient projects were when a single developer was working on their own.

Efficiency would be relatively constant from 2 developers up to the 60 mark, at which point it would start falling rapidly.

“We conclude that it is undesirable to involve more than 60 developers in a project if we want the project members to work efficiently,” they suggest.

Work distribution

The study also explored how work would be distributed between internal members of the project.  Perhaps not surprisingly, they found that when work was evenly distributed, it tended to produce higher activity levels.

It also emerged that popularity amongst the external community was highly dependent upon the faithfulness with which suggestions were implemented by the internal team.

Suffice to say, there are some doubts around causation and correlation with the study, but overall it’s an interesting look into a fascinating area, and should provide some guidance for coders looking to do better with their own projects.