FOSS In Courses Activity

When many people think about including FOSS in a class, they are typically thinking of one of two things:

1. Finding an artifact from the FOSS project such as a code segment that provides the base for study within the classroom (e.g., code review), or
2. Making a code contribution to the project by fixing a bug or making an enhancement.

However, there are myriad different activities based on FOSS as well as ways of contributing to FOSS projects that go beyond coding. The purpose of this activity is to explore some of the other ways to introduce students to and/or involve students in FOSS projects.

Observing some of the different activities and ways to contribute starts with understanding what these are. Helpful resources for new developers trying to learn about it are:

1. Andy Lester's 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star
2. Craig Buchek's great list of ways to contribute other than code
3. The list of activities on the 50 Ways to be a FOSSer page

For educational purposes, there are further resources to draw from:

1. There is a set of learning activities
2. TeachingOpenSource has a Teaching Materials Catalog
3. Steve Jacobs at RIT has a Open Source Course

For OpenMRS in my course, activities or topics that I am interested in are:

• The introductory assignments as we are doing right now for POSSE.
• Solving introductory issues across the system to get students used to the way of working in this particular project and to get them set up with the development environment.
• Bigger topic or module: I am not sure which one to choose here.

Existing materials for those activities are:

• Introductory assignments: Intro to FOSS, project anatomy (and evaluation), learn IRC and other types of channels or forums, version control (git), bug tracking (also on github)
• Solving introductory issues requires the list thereof and the new developers guide
• The to-be-chosen bigger topic requires the technical overview of the project and then more documentation on that active project or module.

Walk through of an evaluation of the OpenMRS project

There are many criteria which should be looked at when determining if a project is appropriate to use in your class. These criteria are broken into two groups - mission critical and secondary.
I am using these criteria to determine whether the OpenMRS project would be a good fit for the software engineering senior design course in Spring 2017 at CSULB.

Mission Critical Criteria-Viability

1. Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complex.
   1. On the OpenMRS web page (http://openmrs.org/), there's the OpenMRS Wiki (under Other OpenMRS sites). From the menu on the left expand the Developer Guide and the Getting Started as a Developer options and then look at the Technical Overview. From examination of the technology stack, the architecture looks modular and further search shows it is documented elsewhere on the site. This provides a first look at the complexity of the application and the number and various different technologies involved.
   2. Based upon the results from OpenHub (gathered in the FOSS Field Trip activity) and the information from the OpenMRS Technical Overview page, think about the size of the code base and how many different technologies and layers are involved in the application. What would you score this project for size/scale/complexity on a scale of one to three where one is "low" and three is "high"? Probably a medium because it could be more complex but it is certainly sufficiently complex to learn the ropes and to have to focus.
2. Activity - To support student participation a project should be reasonably active. Number of commits can be used as an indicator of activity.
   1. Based upon the number of commits (gathered in the FOSS Field Trip activity) would you consider this project active? This project can be considered as active because it had on average more than a commit per day over the past 12 months, so that is a good basis for assuming that the activity will also continue for a while longer.
3. Community - A suitable project has an active user community. While it is difficult to quantitatively evaluate the activity of a user community, some indicators include a regular history of project downloads and documentation updates over time, current activity on user mailing lists, and testimonials on the project web site.
   1. Examine download activity
      1. Go to sourceforge.net and enter OpenMRS into the search box.
      2. Choose OpenMRS from the search results.
      3. Click on the number of downloads that is listed on the project page. 976 downloads this week is pretty good!
      4. Change the date range to give a graph of downloads over the last year. 72,490 downloads in the last year. This certainly makes for a large enough user community.
   2. OpenMRS has begun migrating legacy mailing list activity to OpenMRS Talk. Examine discussion activity: The user and developer forum is very active and well moderated.
   3. Examine the IRC logs: The IRC logs show good communication, high activity, and good netiquette.
   4. Based upon the download history, discussion activity, and IRC activity, do you feel this project has a good community? This project certainly has a good community, multiple leaders, highly spread developer community, everything that seems to be necessary for a community to thrive.

Mission Critical Criteria-Approachability

Here you are evaluating a project's on-ramp to contribution, scoring as follows:

1-Insufficient-Few or no pointers on how to become involved.

2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.

3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.

1. Examine project on-ramp.
   1. Link to getting started - The website has a Get Involved page with links to ways you can contribute and share your ideas.
   2. Each of the links (Develop, Test, Document, Translate) contain more detailed information about what and how you can contribute.
   3. The Getting Started as a Developer page contains a detailed list of how to get started including a list of introductory issues.
   4. Detailed instructions - The Developer Guide contains instructions and information in many areas including process, architecture, tools, and developer documentation.
   5. Based upon the resources you looked at, how would you rate the approachability of the OpenMRS project? This project certainly has everything in place for thriving development, and I would rate it as very approachable. Developing, testing, documenting, translating are all options for contributing. Sharing is also encouraged via connecting, suggesting, spreading the word, or just getting an OpenMRS ID.

Mission Critical Criteria-Suitability

1. Appropriate Artifacts - Since evaluation is dependent on class objectives, in this example we'll assume the objective is to learn the process of working in an authentic development environment by contributing bug fixes to OpenMRS.
   1. Opportunities to contribute bug fixes - Examine the issues found at the bottom of the getting started as a developer page. The introductory issues are categorized into curated and non-curated, which means that there are some that have a thorough description of how to solve them, while others don't. There are 39 curated and 70 uncurated introductory issues listed.
   2. Documentation on how to contribute bug fixes - On the Tickets pagethere is information on how to create and work on an issue, including links to coding standards and the code submission process. 
   3. Based upon the number of bugs suitable for students to tackle and information on the process of how to submit bug fixes, do you think this would be an appropriate project for your students? Based on the number of introductory issues, even though I think my students would especially like to start on curated ones, I think this would be a suitable project.

2. Contributor Support - Does the project have a high volume of guidance to help students as they learn?

1. Communication Tools - Communication tools are directly available from any of the Wiki Spaces (Documentation, Projects, Resources). The Resources page contains links to OpenMRS Talk and IRC Chat, as well as links to group meetings (under Events), and training opportunities.
2. Web Presence - Examine the IRC logs. There has been plenty of activity during the last week.
3. Operating Processes - Links to information about coding standards, the code submission process, and commit privileges can be found on the How-To Submit Code page. The process for making feature requests is available on the Tickets page. These processes are well documented.
4. Response to Questions - Review a few of the posts on the OpenMRS discussion platform. Posts to this forum seem to receive timely and supportive responses.
5. I would you rate the support that newcomers to OpenMRS receive as really good.

In summary, it looks like the OpenMRS project is a very suitable project for the course according to the mission-critical criteria. The project is viable, approachable, and suitable. The community is very active, very supportive, and very well documented. The cause of the project is to support healthcare worldwide. It is a medical records system.

For the secondary viability criteria, for understandability of the domain, the required domain-knowledge is not too complicated. Maturity, user support, and roadmap are all given as well.

Secondary for approachability, the types of contributions, the openness to contributions, and the friendliness to students also seem to be given.

Secondary for suitability, the project description is very accessible, the project is platform-independent, and the development features provide enough options for all students to find general as well as very specific issues.

So for the secondary criteria, the rating is also good for OpenMRS.

Exploring Open Source

I am on a mission to explore open source and I am learning how to teach it so I can incorporate it in my software engineering senior design project in Spring 2017. This is an account of some of my activities while exploring and learning.

FOSS Field Trip 

Part 1 - Exploring SourceForge

One of the best known of these FOSS project hosting sites is Source Forge (http://sorceforge.net/). I explored projects in SourceForge to gain an understanding of the key characteristics of a FOSS project.

I used the Search feature in the center of the screen to view applications in the area of

"Mountains" because I am a mountain addict.

There were 19 projects in this category?

Five different programming languages are used to write software in this category.

The top two programming languages used to write programs in this category are C++ and Lua, and there were only 3 other programs in other languages.

The meaning the different statuses of an open source project is the following:

Inactive - "no longer actively maintained"

Mature - "well established"

Production/Stable - "ready to promote for wide use"

Beta - "ready for rigorous wide user testing"

Alpha - "test phase by general users, unstable, preliminary release"

Pre-Alpha - "not ready for public, under development"

Planning - "under planning"

Comparing two projects in this category that have two different statuses did not give me a whole lot of choice because most of the projects were rather inactive, but some more than others :)

Project that was the most used was called "Fracplanet" according to the number of downloads (22 last week).

Fracplanet is an interactive application to generate and view random fractal planets and terrain with oceans, mountains, icecaps and rivers, then export them to POV-Ray format or Blender.

The programming language the project is written in is C++ with Qt and OpenGL.

The people who are likely to use the project are 3D modelers, which I take from the categories provided in the description and in the reviews.

The most recent change made to the project was in April 2016.

The project is not very active according to the code repository updates. Furthermore, it has only one committer.

I wouldn't use the project unless it is for a one-time need and fits me well enough, because it is not active enough with one contributor, even though somewhat recently updated.

Part 2 - OpenHub

In this activity, I used OpenHub to gather information about a Humanitarian Free and Open Source project named OpenMRS (https://www.openhub.net/).

For the OpenMRS Core project, I identified when the data in OpenHub was last analyzed and the last commit date. It was analyzed 25 days for the 3 months ago committed code; 2 months ago was the last code pull but no commit.

The main programming language used in OpenMRS Core is Java.

The lines of code of OpenMRS Core are 3,739,232 lines of code.

OpenMRS is written in 15 languages and the second highest number of lines of code is in JavaScript.

Of the programming languages used in OpenMRS, the language that has the highest comment ratio is Java.

The average number of contributors in the last 12 months was about 15.

The Top Contributors have been involved in the project for 3-5 years.

The average number of commits over the past 12 months was about 40 per month, so a little more than one per day.