Crowdsourcing as a Service: A New Reference Model for the Cloud Era
A reference model for crowdsourcing as a service
This paper introduces a pioneering four-phase cloudified reference model for "Crowdsourcing as a Service" (CaaS). It formalizes the architecture required to transition traditional crowdsourcing into a scalable, cloud-centric framework that integrates task management, evaluation, and incentive mechanisms.
TL;DR
As mobile devices and cloud computing converge, traditional crowdsourcing is evolving from static web platforms into a dynamic, scalable utility. This paper presents the first Reference Model for Crowdsourcing as a Service (CaaS), defining a four-phase architecture that transforms how tasks are generated, distributed, evaluated, and rewarded within a cloud-centric ecosystem.
Problem & Motivation: The Need for "Cloudification"
Current crowdsourcing platforms like Amazon Mechanical Turk (MTurk) or Gigwalk operate largely as isolated silos. While effective for their specific niches, they face significant hurdles:
- Infrastructure Rigidity: High human intervention and manual management.
- Resource Constraints: Limitations in storage and processing power for large-scale sensing data.
- Lack of Standardization: No universal architectural language exists to describe the life cycle of a crowdsourced task across different domains.
The authors argue that the "Everything as a Service" (XaaS) shift in cloud computing makes the cloudification of crowdsourcing inevitable. By treating the crowd as a service provider, organizations can scale resources on-demand and offload complex processing (like outlier detection) to powerful cloud servers.
Methodology: The Four-Phase Reference Model
The core contribution is a systematic workflow that standardizes the interaction between the Crowdsourcerer (the seeker), the Platform (the cloud infrastructure), and the Crowd (the providers).
1. The Architectural Framework
The model defines four primary players and four computational sub-components (Task Manager, Evaluation, User Ranking, and Incentives) hosted on a cloud platform.

2. The Four Phases of CaaS
- Registry and Task Generation: Users and workers register (anonymous or via social IDs). The cloud manages unique Task IDs and matches types (e.g., voting vs. complicated work).
- Task Distribution: Intelligent matching based on criteria such as location, reputation, and even the residual battery power of the participant's device.
- Evaluation: The cloud platform filters "noise" or anomalous data. This is crucial for maintaining quality without manual auditing.
- Ranking and Rewarding: A reputation-based loop ensures that high-quality contributors are prioritized for future tasks and rewarded appropriately (monetary or altruistic).
Critical Analysis: Why This Matters
What sets this model apart is its focus on Task Attributes. The authors provide a granular template for task definition, ensuring that every job is trackable and measurable.
| Attribute | Significance |
|---|---|
| INCENTIVE | Defines the "Why" for the crowd (Payment/Reputation). |
| REQ-proof | Ensures accountability in the evaluation phase. |
| LIMITATIONS | Allows seekers to filter by gender, region, or expertise. |

The Mobile Cloud Synergy
By offloading the heavy lifting of data processing and analysis to the cloud, mobile devices can act as "lean" sensors. This increases participation longevity by saving device energy while allowing for real-time data submission through ubiquitous wireless networks.
Conclusion & Future Outlook
This reference model serves as a foundational bridge between the Internet of Things (IoT) and human-in-the-loop systems. By formalizing Crowdsourcing as a Service, the authors pave the way for a future where sensing resources are as accessible as virtual machines on AWS.
Key Takeaways for Researchers:
- Security and privacy remain the "grand challenge" in this cloudified model.
- Future systems must focus on more sophisticated "Task Recommendation" engines to keep the crowd engaged.
- The integration of social media as a "Data Publisher Layer" is essential for reaching a disorganized mass of users.
Limitations: While the model is robust, it primarily focuses on the architectural structure. Future work will need to address the quantitative "tuning" of incentive mechanisms to prevent worker fatigue in high-frequency sensing tasks.
