Computer Science · 9th Grade

Active learning ideas

Open Source Software Development

Active learning works because open source development relies on hands-on collaboration, peer review, and real-world artifacts. Students need to experience decentralized coordination firsthand to grasp how thousands of contributors build and maintain software without central control. By engaging with authentic projects and debates, students move beyond abstract definitions to understand the practical implications of open development.

• Common Core State Standards
• CSTA: 3A-AP-22
• CSTA: 3A-IC-24

• 20–35 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Gallery Walk
• 30 min · Small Groups

Gallery Walk: Open Source Projects Students Already Use

Post six stations with descriptions of open source projects embedded in everyday tools (Linux, Firefox, Python, VS Code, Wikipedia, OpenStreetMap). Students rotate and add one observation: who maintains this? How do they coordinate contributions? What would happen if the project disappeared? Class synthesizes observations into patterns.

Explain how open source software development relies on version control tools.

Facilitation Tip

For the Gallery Walk, display printouts of project interfaces and license summaries around the room so students can physically move and examine artifacts.

What to look for

Present students with a scenario: 'A team of 5 developers is working on a new app. Two developers accidentally overwrite each other's code. What tool could have prevented this, and how?' Ask students to write a one-sentence answer identifying the tool and its function.

• Understand
• Apply
• Analyze
• Create
• Relationship Skills
• Social Awareness

Activity 02

• Case Study Analysis
• 35 min · Small Groups

Case Study Analysis: Contributing to an Open Source Project

Groups review a simplified GitHub contribution workflow -- finding an issue, forking the repo, making a change, submitting a pull request, addressing review comments. Each group identifies the most likely point of friction for a first-time contributor and proposes one way the project could lower that barrier.

Analyze the benefits and challenges of contributing to open source projects.

Facilitation Tip

During the Case Study Analysis, assign each student a role (e.g., maintainer, contributor, user) to focus their reading and discussion on specific stakeholder perspectives.

What to look for

Pose the question: 'Imagine you found a bug in a popular open source application you use. What are the steps you might take to report it or even fix it yourself, and what are the potential benefits and risks of doing so?' Facilitate a class discussion focusing on contribution pathways and personal investment.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 03

• Case Study Analysis
• 25 min · Pairs

Comparison Chart: Open Source vs. Proprietary

Partners create a two-column comparison of open source and proprietary software development along five dimensions: funding model, quality assurance, feature prioritization, user trust, and contributor motivation. Pairs share their charts and class discusses where the two models have genuinely different strengths.

Compare the development models of open source and proprietary software.

Facilitation Tip

Use the Comparison Chart to require students to cite specific examples from the projects they analyzed in the Gallery Walk, linking evidence to their comparisons.

What to look for

Ask students to list two key differences between how open source software is typically developed and how proprietary software is developed. They should focus on aspects like collaboration, access to code, and licensing.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 04

• Think-Pair-Share
• 20 min · Pairs

Think-Pair-Share: Should Tax-Funded Software Be Open Source?

Present the argument that software built with public funding should be released as open source. Partners discuss: what are the strongest arguments for and against? Each pair shares one argument they find most compelling and one they find least compelling. Teacher facilitates a class synthesis of the key considerations.

Explain how open source software development relies on version control tools.

Facilitation Tip

In the Think-Pair-Share, provide a structured sentence frame for the 'share' phase to ensure equity in participation, such as 'I think [position] because [reason], but my partner’s point about [counterpoint] made me consider...'.

What to look for

Present students with a scenario: 'A team of 5 developers is working on a new app. Two developers accidentally overwrite each other's code. What tool could have prevented this, and how?' Ask students to write a one-sentence answer identifying the tool and its function.

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

A few notes on teaching this unit

Experienced teachers approach this topic by framing open source as a social system first, not just a technical one. Avoid starting with definitions of licenses or version control commands, as these can overwhelm students. Instead, begin with recognizable tools (like the browser they use) to build relevance, then layer in technical concepts as students encounter them. Research shows that students grasp decentralized collaboration best when they first experience the problem it solves, so start with a scenario where code conflicts arise naturally before introducing Git.

Successful learning is visible when students can explain how version control enables global collaboration, compare licensing models, and recognize the diverse ways people contribute to open source. They should move from saying 'open source is free' to articulating how community review, licensing terms, and contribution pathways function in practice.

---

Watch Out for These Misconceptions

• During the Gallery Walk: Open Source Projects Students Already Use, watch for students assuming that free software equals lower quality because they conflate price with value.

  Use the Gallery Walk artifacts to point students to evidence of industry adoption (e.g., Apache server powering 50% of websites) and discuss how community review and transparency maintain quality.

• During the Case Study Analysis: Contributing to an Open Source Project, watch for students believing that 'open source means anyone can use the code for any purpose' without considering licensing terms.

  Have students examine the actual license file in the project repository and summarize its key restrictions or permissions in their case study notes.

• During the Comparison Chart: Open Source vs. Proprietary, watch for students assuming that only expert developers can contribute to open source projects.

  Point students to the 'good first issue' labels or documentation tasks listed in the project they analyzed, and ask how these roles support the project.

---

Methods used in this brief

• Gallery Walk
• Case Study Analysis
• Think-Pair-Share