Teaching with Humanitarian Free & Open Source Software

James Walden Department of Computer Science Northern Kentucky University

Topics

1. What is HFOSS?

2. Student Participation in HFOSS 3. Virtual Tour of a FOSS Project 4. FOSS Community Involvement 5. Using FOSS in your Class Licensing This presentation is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License . Some slides are based on slides from the POSSE 2014-5 workshop, which were also available under this license and which can be found at http://www.foss2serve.org/index.php/Stage_2_Activities.

HFOSS o o o Humanitarian Free Open o o Source Software

Acronyms

Open Source Software

1. Access to read source code.

2. Can change source code.

3. Can distributed software.

4. Typically developed by loose geographically distributed collaborations.

Reading Source Code

• • In many disciplines, students read more samples of work than they produce.

Why don’t we read more code?

• • •

Changing Source Code

Most development is changing existing projects.

Most students won’t start on a greenfield project.

Why not have class assignments to modify existing code?

Distribute Software

Do students understand what rights a license gives a user to distribute software and documentation?

o Can software be used as a dependency of a work project?

o Under what conditions, can workers copy code snippets and reuse them?

Distributed Development

OSS developers have created many useful tools for coordinating distributed development that can be re used in the classroom.

o Version control o o o o Chat Wiki Etherpad Code review tools

Challenges in Student Participation

1. FOSS project complexity o o Code and technology base Tools used 2. FOSS culture and process o o Dynamics of interaction with FOSS communities Release schedules and process 3. Meaningful involvement for students o FOSS project cooperation o Maintaining local knowledge of project over time

• • • • • • • •

50 Ways to be a FOSSer

Use & Evaluate FOSS Participants HFOSS Project Overview Communication Tools Business Model Philosophy and Politics Privacy and Security • • • • • • • Documentation Visual Design Quality and Testing Usability Design Style Coding http://xcitegroup.org/softhum/doku.php?id=f:50ways 10

Activity Structure

• • • Students could work as: o Individuals, pairs, teams, interacting teams Deliverables could be: o Development artifacts, assignments, blog posts, podcasts, vlogs, wiki pages, articles for magazines, newspapers, web sites, etc. Results could be o Submitted to instructor for evaluation, submitted to the HFOSS community for comment, posted or shared for peer review , presented in class, discussed in class or online, etc. 11

Scope of Learning

Student learning can span: o HFOSS as an item to be studied o o o Draw artifacts from HFOSS Contribute back to HFOSS Individual assignments or sequences of assignments 12

Learning Opportunities - Technical

• • • • • • Coding, testing and debugging Code reading and understanding Specification and design Development platforms Communication tools Collaboration and development tools http://www.xcitegroup.org/softhum/doku.php?id=f:50ways

Learning Opportunities – Soft Skills

• • • • • Teamwork Communication Cultural exposure Understanding of humanitarian issues Copyright legal issues

Learning – Domain Knowledge

• • • • • Health systems Financial systems Cryptography Bioinformatics Social issues

Ex: OSS Participants

• • • Interview a FOSS user and find out why they use FOSS, benefits/drawbacks, etc. Interview a FOSS contributor to find out how they got involved, their role(s), their background, etc. Shadow a FOSS contributor over time to see what they do, and summarize. 16

• • •

Ex: Project Overview

Research history of HFOSS project and summarize. o When did it start? How many releases? How many users? Review archived discussion of a chat, thread, or forum and summarize, categorize or reflect on the content. Study completed defect or feature proposal, and create a concise summary.

o Include details, people involved and roles, steps taken, etc.

17

• • • •

Ex: Communication

Choose an RSS client, subscribe to RSS feeds for HFOSS, read, and summarize. Subscribe to an IRC channel, listen to a meeting, write summary.

Work remotely with another student to develop profiles for each other Study the social norms of communication within a FOSS community. (i.e. how to ask questions, respond, etc.) 18

• • •

Ex: Usability

Evaluate usability of a specified feature or screen and summarize results.

o o Using formal guidelines or rubric Using heuristic evaluation Evaluate accessibility of feature. Brainstorm possible enhancements for project, choose a few to document. 19

Students Have…

1. Created install instructions for the dev environment for OpenMRS 2. Added a keyboard to the Caribou onscreen keyboard 3. Written guidelines for downloading and installing products 4. Added color filters to vision software 5. Created a volunteer management module for disaster management software 20

Virtual FOSS Project Tour

It’s All About Community

• • • Mindset: Joining a HFOSS community.

o Rather than just working on a project Community drives the project, not vice versa.

Need to work within the community, not as individual outside of community.

22

Get to Know a Community

Each Community has its own culture Channels of communication: o o o o o o o Mailing lists Bugzilla comments Gerrit code reviews IRC chat IRC meetings F2F Meetings Video chats Read communications before writing.

o Read FAQs too.

23

Get to Know a Community

Processes for code submission o o o File a bug and attach a patch Send patch to a mailing list Add a comment with patch to bug tracker o o Fork a repo, branch, then send change to subproject maintainer Code review process (Un)written rules o o o Who do you need to convince?

Your patch might not be looked at w/o a regression test Style conventions 24

Get to Know a Community

Big communities are made of sub-communities o o Based on modules – or subsets of code Based on task area Sub-communities are made up of individuals o Located all over the world o With quirks and pet peeves 25

Get to Know a Community

Getting lost in the forest o o o IN THEORY, all projects have up-to-date roadmaps, etc.

IN PRACTICE, design documentation is not readily available • • May be many versions w/ no indicator of which is current Everyone in OSS was once a newbie • May be difficult to find.

But have forgotten what it is like 26

Get to Know a Community

Get connected; stay connected!!!!!

o o o Figuring out all of this takes time Best to figure it out all once The community will look out for you 27

Be Productively Lost

“… state where the scope of a project exceeds the scope which a person is able to master, and yet that person is able to productively navigate and accomplish goals by working in community.” Learn who to turn to with questions about architecture, code, and more.

o o Replaces the need for perfect technical understanding Navigating the community 28

FOSSism: Giving Back

FOSS survives on contributions from users and developers.

Pay back in: o Documentation, reviews, testing, answering questions, etc.

You don’t have to be an expert.

Small contributions can be very valuable.

o Most people start with small contributions.

29

Opportunism reigns

• • • FOSS developers have limited time and limited resources. As a result, FOSS development is very opportunistic with development taking advantage of resources as they appear. Progress may happen in spurts and have a convoluted path to the final product.

30

If It isn’t Public, It Didn’t Happen

Decisions only get made on public artifacts.

o Includes mailing lists, forums, IRC too.

If artifacts are not public, they are not contributions.

o Public means accountable o Also enables community to understand and help Hint: Get used to public communication. 31

Radical Transparency

• • • • All processes and artifacts are open.

Distributed development can only happen if all information is accessible.

Students may be more comfortable with this than you are.

Supports vast learning opportunities.

32

Ask Forgiveness, Not Permission

• • Very little in FOSS world that can't be reverted. So just try something then ask if it is OK o You’ll almost always get a “yes!” answer 33

• • • •

FOSSism: Branches are Free

No cost to make a copy of existing code and play with it.

If you mess up, just revert or delete.

Sometimes experiments have useful results.

Share these results!

o Comment extensively!!!

34

FOSSism: Keep a History

• • • • • History-keeping should be automatic when possible.

Version control helps with this.

Helps students understand project history.

Helps with decision making.

Helps if you leave a project so someone else can pick up where you left off. 35

Begin with the Finishing Touches

AKA o o o don't reinvent the wheel stand on the shoulders of giants scope a small project first Start with something very small. o Fix documentation o o Verify a bug Test a feature 36

It’s not what you know; It’s what you want to learn

• • • • You are already good enough to contribute to FOSS.

FOSS communities understand newbies.

In fact, every member of a FOSS community was a newbie!

You’ll learn the skills you need as you interact with the community.

37

Release Early, Release Often

• • • • Tight feedback loop between developers and users. o Ensures that change is what community wants Catch errors early.

Faster development process (or some claim).

In the classroom, this may mean releasing every couple of weeks or so.

38

Show Me The Code

• • • Linus Torvalds: “Talk is cheap. Show me the code.” Don’t just say that you’re going to do something, do it.

And show the results.

39

Shallow Bugs

• • • • “With enough eyeballs, all bugs are shallow”.

Let people help you as much as possible as early as possible. Quality of FOSS projects is typically higher than commercial software.

The more people who know about your problem, the more likely it is that one of them can help you solve it.

o Radical transparency and release early, release often 40

Uncommunicated work

• • • It's better to communicate undone work than to do uncommunicated work. When courses end students need to gracefully hand off/close their work.

o Document remaining work o Try to find someone to take it on o Or at least to leave it in findable place with a clear indication that a maintainer is now needed. Contribution isn’t “complete” until hand off is complete.

41

Steps to Use OSS in Class

1. Getting Organized 2. Lurking 3. Introducing Yourself 4. Finding Things to Do

• •

Step 1: Getting Organized

Project evaluation activities should help you identify possible HFOSS projects. Cursory examination for:

Project Wiki/Page Mailing list(s) Roadmap Documentation IRC Committers Bug Tracking Source Code Control Releases

43

Step 1: Getting Organized

• • Think about kinds of deliverables for students. Find Roadmap/bug tracker and identify possible contributions. o See if you can trace the process of one or more bug fixes or enhancements 44

Step 2: Lurking

• • • Join mailing list(s) and observe for several weeks.

o Read logs for several months or year back o Who are the major community members and what are their roles?

Join IRC and lurk.

Identify meeting times and lurk in meetings.

o What are the areas of interest to the community?

45

Step 3: Introducing Yourself

• • • Introduce yourself and your motivation for joining the group.

Identify what you (and students) can contribute to the project.

o Not details, but generalities (e.g., work on documentation) Describe the student body that you’ll be introducing to the community. 46

Step 3: Introducing Yourself

• • Identify what you are looking for from the community.

o Project ideas?

o Contact for particular aspect (e.g., documentation) Remember, goal is to facilitate student entrance into the community, not “find a project”.

47

Step 4: Finding Things To Do

• • • Identify a small task that you can accomplish. o Identify the committer and commit process for the task Let the community know what you’re working on.

Accomplish the task and get it committed!

48