After trending on GitHub, time to be a manager?
When crowdsourcing goes really well, team leaders often need to rely on traditional organizational management structure to get the work done, research on GitHub finds.
When crowdsourcing goes especially well, team leaders often need to rely on traditional organizational management structure to get the work done, research on GitHub finds.
When a collaborative crowdsourced project enters the limelight, the impact—or shock—of so much attention forces the original creators to carefully manage community engagement or risk stalling progress.
The research from the University of Michigan School of Information shows that often the core team members find themselves in somewhat traditional management roles as they seek to move the work forward, sometimes by enlisting members of the crowd for more involved assignments.
“They struggle with staffing and response. This forces them to carry on as before or open up and accept outside help,” says Danaja Maldeniya, doctoral candidate at the University of Michigan School of Information and first author of the paper to appear this week at the Web Conference, which is taking place virtually.
Maldeniya and colleagues looked at how a deluge of “good Samaritans” on more than 1,100 open source software projects that topped the GitHub Trending Projects page resulted in growing pains, requiring the team to adapt work routines, organizational structure, and management style. The researchers analyzed millions of actions of thousands of contributors by scraping data from the GitHub trending page every three hours for seven months.
In crowdsourced ventures there typically is a small core team—Maldeniya calls them “passion project creators”—who open their projects to the masses but expect to continue in the role of developers. Newcomers typically show interest by “starring” the project, reporting issues they encounter, suggesting additional features, or contributing code or other content. They sometimes express interest in forking, or taking the software in a new direction, for which they make a pull request for the data.
Most newcomer contributions are shallow and transient, but in cases where the shock is strong, the original team must transition into administrative roles, responding to requests and reviewing work of the newcomers. As a result, projects follow a more distributed coordination model, with newcomers becoming more central, albeit in limited ways, the researchers write.
When the original team is unprepared for the shock, the result can be long delays in responding to interest and ideas from the crowd, which can chill interest or stall momentum. After the shock, response time for an issue or pull request increased by 30% and 42%, respectively.
“When you have a team of say five people and you get 1,000 external engagements, how do you respond to that? Most likely you will be overwhelmed and not respond,” Maldeniya says. “Most engagements will be shallow. There will be a limited number of high-value engagements but how do you find them among the 1,000?”
Maldeniya says rather easy fixes to help keep momentum following a shock could include creating to-do lists for crowd members with specific tasks to tackle or using an automated system to weed out bots and frivolous responses, with boilerplated messaging to acknowledge interest, including a promise to be in touch.
The research had partial support from the National Science Foundation.
Source: University of Michigan