Tip

For alternative editing methods use Pandoc to convert from HTML into your favorite markup language (Markdown or reStructuredText):

pandoc -f html -t rst -o landing_post.rst landing_post.html

Edit in your favorite editor then convert back to HTML:

pandoc -f rst -t html -o landing_post.html landing_post.rst

Contents

• 1   Target audience
• 2   Goals and purposes
• 3   Learning Outcomes
• 4   Course process
• 5   Accreditation
• 6   Content
• 7   Selected reading
• 8   Selected sites

1   Target audience

Programmers, Technical support personnel, sys admins, IT managers

2   Goals and purposes

This read/write course provides an opportunity to learn about issues and technologies concerned with free and open source software (FOSS) with a view to critically and reflectively using, contributing to and selecting open source software.

3   Learning Outcomes

Author note: each outcome should be:

• distinct - no combinations of multiple outcomes
• clear and assessable - qualitatively or quantitatively
• describe what a successful student will be able to do - nothing fuzzy like 'understand' or 'know'

At the end of this course, the successful student should be able to:

• distinguish between a wide range of different open source licence models
• argue the strengths and weaknesses of open source licences
• use open source software legally and ethically
• contribute effectively to the development of open source
• effectively use FOSS in a for-profit business
• debate the ethics of FOSS
• manage open source installations
• integrate open and closed source software
• critically analyze the strengths and weaknesses of FOSS and closed-source systems
• present a business case for open source implementation
• design a business solution based on open source
• work with and/or build upon the work of others in an open source process
• increase the value of work written by others
• engage in an open source community

4   Course process

Author note: this is about the pedagogies and activities that might contribute to the formal learning process, not the content

Independent study, shared content: students will both contribute to and learn from the course. There will be multiple paths and approaches to match individual student needs, knowledge and interests.

Activities may include:

• Sharing of research into different models
• Taking what others have done and developing it further, repurposing or refining it
• Debate
• Reflection
• Planning and designing
• Implementation
• Contribution to open source project(s)
• Joining distros working groups (e.g. Debian, Fedora)
• Virtual field trip: using and improving a project using appropriate tools (Google Code, SourceForge, GitHub, CodePlex etc)

5   Accreditation

Author note: accreditation should clearly demonstrate mastery of all learning outcomes. Duplicate assessment of same outcomes should be avoided if possible.

Form of accreditation to be negotiated by/specified by learners. As long as the student can provide evidence of meeting the outcomes, any format, activities and methods may be used (potential for peer review of proposed methods?). It is assumed that effective methods will evolve as the course progresses.

Copying, re-use and collusion are strongly encouraged: cheating is only an issue if original sources are not cited or collusion/contracted work is not described. In fact, we strongly encourage students to start with the previously submitted work of others and to develop, refine or repurpose it.

Examples of suitable evidence might include:

• evidence of competence from the workplace or contributions to open source products
• blog posts or similar reflections using social media
• contributions to course materials
• software (including documentation of process and product)
• design documentation
• system documentation
• radio play/script of fictitious argument
• actual argument and debate, drawn from contributions including not just the course space but other systems such as GitHub, SlashDot, StackOverflow, etc.

The final submission will take the form of a portfolio of evidence of meeting learning outcomes, accredited with open badges (potential for peer badging?), annotated with reflections and observations about the process. Students will have to make a case that they have met the outcomes.

Idea: maybe we could specify a few core outcomes and make the rest optional but with a target number to be achieved in order to receive accreditation. There would be a badge for each outcome that, together, can add up to course credit. We may consider allowing open badges from other courses or learning activities to be used for this.

6   Content

History and background: Early models of software licensing, Stallman, GNU, etc, free as in speech, Cathederal & Bazaar, etc

Licence models: closed source, shareware, freeware, freemium, GPL (inc versions), BSD, Apache, Mozilla, MIT, PD, CC,etc

Open vs closed - arguments for and against open and closed options

Comparisons and debates: issues and factions within the FOSS community,  libre vs open, etc

Legal and ethical issues: using open source

Governance models: central vs decentralized, etc

Development models

Management and Implementation: issues of maintenance, management, version control, forks and branches, etc

Profit models, monetization, commercialization, hybrid models, economics of open source, etc

Costing and valuing - identifying the real costs of open source, different measures of value (e.g. control, social good,

Integration and standards

Security issues and concerns

Documentation issues and approaches

7   Selected reading

Eric Raymond: The Cathedral and the Bazaar

Yochai Benckler: The Wealth of Networks

Kevin Kelly: New Rules for the New Economy

The Open Source Way

8   Selected sites

Github

Google Code

SourceForge

Mozilla Foundation