Survey and comparison for Open and closed sources in cloud computing

Cloud computing is a new technology widely studied in recent years. Now there are many cloud platforms both in industry and in academic circle. How to understand and use these platforms is a big issue. A detailed comparison has been presented in this paper focused on the aspects such as the architecture, characteristics, application and so on. To know the differences between open source and close source in cloud environment we mention some examples for Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service. We made comparison between them. Before conclusion we demonstrate some convergences and differences between open and closed platform, but we realized open source should be the best option.

💡 Research Summary

The paper presents a systematic survey that contrasts open‑source and closed‑source cloud platforms across the three canonical service models—Software‑as‑a‑Service (SaaS), Platform‑as‑a‑Service (PaaS), and Infrastructure‑as‑a‑Service (IaaS). After a brief introduction that frames cloud computing as a rapidly evolving field, the authors select representative products for each layer: Google Workspace and Microsoft 365 as closed‑source SaaS examples versus OpenProject and Nextcloud as open‑source counterparts; Microsoft Azure and Google App Engine for closed‑source PaaS compared with Cloud Foundry and Red Hat OpenShift for open‑source PaaS; Amazon EC2 and Google Compute Engine as closed‑source IaaS contrasted with OpenStack and Apache CloudStack as open‑source IaaS.

A nine‑point comparison framework is then applied: (1) architectural design, (2) scalability, (3) availability, (4) security model, (5) cost structure, (6) operations and maintenance, (7) community and vendor support, (8) licensing and regulatory compliance, and (9) ecosystem interoperability. For each criterion the paper provides narrative discussion and a concise tabular summary.

Key findings include:

• Architecture – Open‑source stacks are typically modular and plugin‑driven, allowing fine‑grained customization and component swapping. Closed‑source offerings present integrated, vertically‑aligned stacks with uniform APIs that accelerate development but limit deep customization.
• Scalability – Both paradigms support horizontal scaling, yet open‑source solutions (e.g., OpenStack) enable virtually unlimited node addition through self‑managed clusters, while closed‑source services rely on vendor‑managed auto‑scaling mechanisms that reduce operational overhead.
• Security – Closed‑source platforms deliver vendor‑issued patches, certifications, and SLA‑backed guarantees. Open‑source projects benefit from transparent code, rapid community‑driven vulnerability disclosure, and the ability to audit code, but responsibility for patching often rests on the user organization.
• Cost – Licensing fees are absent for open‑source software, making it attractive for cost‑sensitive deployments. However, the paper notes that total cost of ownership (TCO) must include infrastructure provisioning, staff training, and ongoing maintenance. Closed‑source services usually involve higher upfront fees but provide predictable operational expenses and bundled support.
• Operations & Support – Open‑source ecosystems offer extensive documentation, forums, and third‑party extensions, yet lack a single accountable support entity. Closed‑source vendors provide dedicated support teams, SLA‑defined response times, and managed services that align with enterprise operational models.

The authors also observe a convergence trend: many closed‑source vendors contribute to open‑source projects, and several open‑source platforms now offer commercial support packages. This blurring of boundaries suggests that hybrid models—leveraging open‑source flexibility with vendor‑managed reliability—are becoming increasingly viable.

In the concluding section the paper argues that, because of its cost efficiency, customizability, and transparency, open‑source cloud computing “should be the best option.” The authors temper this claim by acknowledging that real‑world adoption decisions depend on factors such as regulatory compliance, security posture, internal expertise, and required service‑level guarantees. They recommend future work to incorporate quantitative performance benchmarks, explore integration with cloud‑native technologies (e.g., Kubernetes, serverless), and develop strategies for seamless hybrid deployment of open‑ and closed‑source components.