Learning objectives

• Describe the key open-source concepts in the context of organizational work
• Learn how to use the collaboration features of Git, including forks, pull requests, merges, and issues
• Familiarize with the key elements of open-source project documentation

Open Source

Open-source software (OSS) is software with source code that anyone can inspect, modify, and enhance. OSS development is typically decentralized, community-driven, and publicly accessible.

Open source is enabled through specific licenses that allow use, modification, and redistribution. Examples: MIT License (permissive), GNU General Public License (GPL) (copyleft), Apache License 2.0.

Development Process:

• Code is hosted on public platforms (e.g., GitHub).
• Contributions via issue tracking, pull requests, and peer review.
• Guided by the "bazaar" model (Raymond, 1999) — fast iterations, collective debugging.

Open-source offers a new model for organizing work, with distinct principles for task division, task allocation, reward distribution, and information flows (Puranam et al., 2013).

Diffusion and Impact

Pervasiveness:

• Commercial applications include OSS components (even exceeding 95%).
• OSS underpins operating systems (Linux), programming libraries, infrastructure (Kubernetes), AI (TensorFlow).
• Dedicated organizations support OSS (e.g., Linux Foundation, Apache, OSI).

Economic Value:

• Firms would need to spend $8.8 trillion to replace freely available OSS (Hoffmann et al., 2024).

Labor Market:

• Open-source skills (Linux, Python, Docker) are in high demand.
• GitHub contributions act as a public portfolio for developers.
• Companies (e.g., Red Hat, Microsoft) hire and sponsor OSS contributors.

Hiring open-source experts brings external credibility and internal expertise. (Hoffmann et al., 2024)

Open Source in the Industry

Linux:

• Powers 100% of top supercomputers, 90%+ of cloud infrastructure.
• Forms the basis of Android OS (70–85% global mobile share).
• Red Hat offers Linux support services and was acquired by IBM for $34B — OSS as strategic infrastructure.

Microsoft:

• Migrated Windows development to Git in 2017–2018, building custom tooling (GVFS) to scale Git for 8,000+ developers and a 300GB codebase.
• Acquired GitHub for $7.5B in 2018, underscoring strategic importance.
• GitHub Copilot uses open-source code to train AI models, demonstrating the value of community-created code.
• Microsoft transitioned from criticizing OSS to fully embracing OSS:

2001: “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches.” (Ballmer)
2014: “Microsoft loves Linux.” (Nadella)
2025: Full support for Linux apps, open-sourced WSL (Windows-Subsystem for Linux).

Principles and Influence of Open Source

Core Principles:

• Self-selection: Contributors choose tasks freely.
• Meritocracy: Influence is earned through contributions, not hierarchy.
• Transparency: All code and discussions are public.

Beyond Organizational Boundaries and Hierarchies:

• Teams operate without formal management and beyond organizational boundaries.
• Trust, documentation, and community guidelines replace supervision.

Influence on Models of Organizational Work:

• Agile & DevOps: Iterative, transparent workflows echo open-source development.
• InnerSource: Internal OSS-style collaboration across departments.
• Holacracy: Inspired by OSS governance (no managers, roles evolve).

The Open-Source Collaboration Game

Materials for this part are available here

Technical Foundations of Collaborative Open-Source Work

• Transparent version control: Git enables a fully traceable history of all code changes. On platforms like GitHub, commit logs, pull requests, and contributor activity are publicly visible, enabling accountability and stigmergic coordination.

• Fork-and-pull workflow: Anyone can fork a repository, make changes in a personal copy, and propose those changes via a pull request. This decouples contribution from direct repository access, supporting large-scale, distributed work.

• Issue tracking and discussion: GitHub Issues and Discussions provide structured ways to report bugs, propose features, or discuss design decisions — forming a transparent backlog of community-driven development tasks.

• Code review and maintainership: Project maintainers use pull requests to review proposed changes, provide feedback, and decide whether to merge contributions. This process is often supported by:

  • Pre-commit hooks and CI checks for enforcing style and standards
  • GenAI-assisted code reviews to surface issues or suggest improvements

• Licensing and governance encoded in the repo: Licenses (LICENSE file) and contribution guidelines (CONTRIBUTING.md, CODE_OF_CONDUCT.md) are stored in the repository, clarifying legal and community norms.

Work in Open-Source projects

The well-known book of Raymond (1999), "The Cathedral and the Bazaar", compares two models of software development:

• The Cathedral model, in which an exclusive group of developers works on a project and releases it to the public.
• The Bazaar model, in which code is developed publicly, allowing anyone to contribute.

This distinction raises interesting questions on how effective work can be organized in the absence of hierarchical control.

Work in Open-Source projects (continued)

Raymond summarizes 19 lessons learned from open source software projects. These include:

• Every good work of software starts by scratching a developer's personal itch.
• Good programmers know what to write. Great ones know what to rewrite (and reuse).
• Plan to throw one (version) away; you will, anyhow
• Release early. Release often. And listen to your customers.
• Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
• The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

Challenges in Open-Source work

Challenges:

• The lack of hierarchical control can lead to conflicts and coordination problems
• Self-selection into tasks can be inefficient (e.g., for beginners, tasks that are not interesting)
• Establishing open, welcoming, and inclusive communities
• Values and goals may differ across contributors ("free as in beer" or "free as in free speech")

Open-Source projects implement measures to address these challenges:

• Licenses (e.g., GPL vs MIT), which are legal documents, but also signal shared norms and values
• A code of conduct, which defines acceptable behavior and sanctions for violations
• Governance structures, which define the roles and responsibilities of contributors
• Organizing best practices and technologies, which facilitate coordination and collaboration (e.g., issue labels identifying "good first issues" for beginners)

Materials

Aksulu, A., & Wade, M. R. (2010). A comprehensive review and synthesis of open source research. Journal of the Association for Information Systems, 11(11), 6.

Crowston, K., & Howison, J. (2005). The social structure of Free and Open Source software development. First Monday, 10(2).

Fitzgerald, B., & Stol, K.-J. (2016). Continuous software engineering: A roadmap and agenda. Journal of Systems and Software, 123, 176--189.

Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The value of open source software. Harvard Business School Working Paper, (24-038).

Puranam, P., Alexy, O., & Reitzig, M. (2014). What's “new” about new forms of organizing?. Academy of Management Review, 39(2), 162-180.

Raymond, E. S. (1999). The Cathedral and the Bazaar. O’Reilly.