Collaborative crowdsourcing has become a popular way to advance a technology idea or to spin it off for new uses, but University of Michigan research shows when faced with extreme interest, team leaders must often rely on traditional organizational management structure to get the work done.
When a collaborative crowdsourced project is thrust into 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 U-M 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,” said Danaja Maldeniya, doctoral candidate at the School of Information and first author of the paper being presented 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 wrote.
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 said. “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 said 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.
Other School of Information authors on the paper: Lionel Robert Jr., Ceren Budak and Daniel Romero.
The research was partly supported by the National Science Foundation under Grant No. IIS-1617820.
