Skip to content

digital-sustainability/module-eoss

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

BFH

Open IDE

Module: Open Source Software Management (EOSS)

Responsibility and lecturer: Markus Tiede

Version: 1.0.2

Valid from: HS 2024

Formal description

Module name and abbreviation

Open Source Software Management (EOSS)

Responsible institute / section

Institut Public Sector Transformation (IPST), Digital Sustainability Lab

Course of study

Bachelor of Science Wirtschaftsinformatik (BWI)

Module level additive

Advanced level

Semester

3rd semester full-time, 4th semester part-time

ECTS-Credits

3 ECTS-Credits

Language

verbal: german; content & material: english

Target Group

primarily for BWI-students
open to all students from other degree programs or students with a general interest in open source software

Content

Short Description

This module covers the foundation and concepts for building effective open source practices in companies and organizations. The focus is on the following phases:

- Using open source software
- Contribute to exisiting open source projects
- Starting new open source projects and building welcoming communities

These three key stages are embedded in strategic considerations, governance processes and implementation.

Long Description

In the first section, you will learn the basic components of open source and open standards. You will also learn about the differences between open source and closed source software, the reasons for the use of each, and how the combination of standards and open source provides increased value to an organization.

The second section discusses the various open source business models and how to develop practical strategies and policies for your organization’s chosen model. It also explains the value and importance of an Open Source Program Office (OSPO) as well as how the OSPO helps provide assistance in defining ROI and other open source metrics.

In the third section, you will learn how to build an effective OSPO and articulate the different types of roles and responsibilities needed to run it successfully.

Section 4 talks about the role of continuous integration and testing in a healthy open source project, and how you can apply open source development principles to internal projects within your organization to take best advantage of the value these principles bring.

In the fifth section you will learn about the importance of effective open source license compliance and how to build programs and processes to ensure safe and effective consumption of open source in the enterprise. You will also get familiar with the most common open source license types, and their major characteristics, as well as how to choose the most appropriate license for a given situation.

Section 6 discusses how to work most effectively with upstream open source projects and how to build sound contribution strategies in organizations to get the maximum benefit from working with project communities. It also describes multiple common upstream project governance models, and explains how these governance practices affect an organization’s ability to make effective contributions.

Finally, the last section discusses the rationale and value for creating new open source projects as well as the required legal, business and development processes needed to launch new projects.

Schedule & Structure

Block of 4 lessons every 2 weeks

Week 1: Open Source Introduction
- Introducing Open Source
- A Short History of Open Source Software
- Reasons to Use Open Source

Week 3: Open Source Business Strategy
- Introducing Open Source Business Models
- Developing an Open Source Strategy
- Developing Open Source Policies
- Introducing the Open Source Program Office

Week 5: Effective Open Source Program Management
- Open Source Program Offices & Your Organization
- Building an Effective Open Source Program Office
- Additional Information & Case Studies

Week 7: Open Source Development Practices
- Effective Open Source Development & Participation
- The Role of Continuous Integration & Testing
- Applying Open Source Methodologies Internally

Week 9: Open Source Compliance Programs
- Open Source Licensing and Compliance Basics
- Building an Effective Compliance Program
- Choosing the Right License Compliance Tool
- The Role of Open Source Audits During M&A Activities

Week 11: Collaborating Effectively with Open Source Projects
- Understanding Upstream Open Source Projects
- Effective Upstream Contribution Strategies
- Upstream Development Practices

Week 13: Creating Open Source Projects
- Open Source Project Creation Overview
- New Project Preparations
- Successful Project Launch & Sustainment

Case Studies
https://todogroup.org/guides/#ospo-case-studies

Collaboration
- Inner Sourcing
- Open Sourcing

Teaching and learning methods

On-site, hybrid and remote lectures combined with ~30+ tasks

Self study:
literature, videos

Literature

https://digital-sustainability.github.io/module-eoss-ospo101/
https://ospo101.org
https://todogroup.org
https://opensourcefriday.com
https://openpracticelibrary.com
https://ossbenchmark.com

Entry requirements

Professional skills
- Basic know how of software engineering principles
- Basic business concepts

BFH-W competency model:
- Competencies of vocational baccalaureate «Engineering, Architecture, Life Sciences» or
- «Business and Services»

Competencies upon completion

Professional skills
Establish OSPOs: an open source program office (OSPO) is designed to
(1) be the center of competency for an organization’s open source operations and structure and
(2) put a strategy and set of policies on top of an organization’s open source efforts.

BFH-W competency model
- Problemsolving / Design Thinking

Agile methods
- Definition of Ready
- Definition of Done

Collaboration
- Continuous Integration
- Code Review

Self Organization
- Retrospectives
- Shared Principles

Handling complexity
- Test Automation
- Test Driven Development
- Everything-as-Code
- Docs As Code
- GitOps

Follow-up modules

- module/wseg - Software Engineering
- CAS - Public Sector Transformation
- SDG1 - Public Sector Trends

Competency assessment*

Exam (60%) at the end of the module
- PC exam using Safe Exam Browser / Lernstick EXAM
- 90 minutes

Tasks (40%)
- Individual ongoing (~ 6 x 5) tasks during semester
- Teamwork research and presentation

Aids for written examination

- Summary (max 10 single or 5 double pages)
- Dictionary (printed) mother tongue <> english

Comment

All contents are available here https://github.com/digital-sustainability/module-eoss licensed under CC-BY 4.0 as OER.

Appendix

Timing

timing

Zweck des Dokuments

Das Modulkonzept dient dem gemeinsamen Verständnis aller an einem Modul Beteiligen bezüglich Inhalte, Didaktik und Tools. Es ist das zentrale Dokument beim Aufbau und bei Überarbeitungen von Modulen. Darüber hinaus hat es aber weitere Zielgruppen:

  • Dozierende/WMAs anderer Module: zum Aufbau und zur Abgrenzung von eigenen Modulinhalten, zum Angebot eines ausgewogenen Mixes von didaktischen Methoden sowie für einen koordinierten Einsatz von Tools

  • Studiengangsleitende: für die Kenntnis von Ansprechpartnern sowie zur Koordination von Modulinhalten, Didaktikvielfalt und Tooleinsatz

  • Instituts-, Abteilungs- und Fachgruppenleitende: zur Festlegung der Zuständigkeiten, für organisationsübergreifende Zusammenarbeit sowie zur Förderung von Themen der jeweiligen Organisationseinheiten

Die Studierenden sind keine direkte Zielgruppe des Modulkonzepts. In der Regel werden Ihnen nur Auszüge aus dem Konzept zur Verfügung gestellt; diese werden in die Modulbeschreibung auf IS-Academia übertragen. Die einzelnen Blöcke der Modulbeschreibung in IS-Academia sollen möglichst direkt aus dem Modulkonzept übernommen werden.

Das Modulkonzept wird im Rahmen des Neuaufbaus eines Moduls erstellt und bei Überarbeitungen angepasst. Zu jedem Zeitpunkt soll eine aktuelle Version verfügbar sein.

Die in der Vorlage zum Modulkonzept enthaltenen Blöcke sind Pflichtbausteine, zusätzliche Blöcke sind möglich. Diese sollen direkt im Konzept und nicht in separaten Dokumenten ergänzt werden.