Introduction

Introduction to the roles in FLOSS

FLOSS communities and projects don't have a "typical" structure they follow in their internal organization. There are however some prevailing models which appear more frequently than others and are more well known. The fact is that roles within FLOSS projects vary based on its size, its form and style and also its evolution.

Main Part

There are different roles that FLOSS community member might have.

Looking at this presentation might helps to get an initial understanding on how to group community members.

However, community member might also have multiple roles, as this presentation indicates.

The wide variety of roles can be separated in two categories in FLOSS communities: The general contributors category, where everyone can find a suitable role and the more demanding developers category, which is the "core" of every FLOSS project.

The general contributors category includes the following roles:

Documentation writers : These people are responsible for writing the documentation targeting end-users. This comes in many forms as FAQs, manuals etc.
Bug testers : They are responsible for bug-testing the software, reporting every bug they find to the community.
Graphic Designers : Every single application needs graphics (logos, icons etc.), so Graphic Designers' responsibility is to create them.
Translators : Most applications come along with multilingual support, and since developers can't know every single language these people are here to help.

The developers category includes the following:

Coders : Vital role for every FLOSS project, coders are needed for the hard part of code writing that will bring the application to life.
Porters : Since FLOSS application are intented to run on different platforms, porters are responsible to modify the code accordingly.
Maintainers : Maintainers are taking care of the code maintainance as the application evolves, making sure performance will be the best possible.
Tool builders : These people create scripts and bug reporting systems that automate the activity of other roles.
GUI Designers : Well console applications are really part of history, so this category creates an appealing user interface for the application.

In which way are those different roles important from an educational point of view?

Since every person has different skills, there should be roles available for every single one. So, let's say someone joins a FLOSS project without having any programming knowledge. He can simply start with something easy, like bug testing, documentation writing etc. and learn while doing it through more experienced members of the community. It's just like in a game with increasing difficulty levels: you start at the first (easiest) level and when you have finished it you have learned the "basics" about the game. So you can move to the next, more difficult level and so on till you reach the final level where you know pretty much about the whole game.

Advantages

What works well

Everyone can participate, regardless of their experience.
Applications are easier to build, since the initial application requirements split to smaller requirements that different people can take over (a kind of "divide and conquer" strategy).
Team spirit is raised.

Criticism

What does not work that well, what needs to be improved, etc.

Sometimes different roles come in conflict when it's not clear who should do what.

Examples

Including practical activities

Roles in FLOSS bring a "divide and conquer" strategy to every project. This means it can easily be appliead to education, helping to solve every single problem. So, the teacher can give an assignment to a team of students, giving them also a team of "roles" or duties each of them has to accomplish. This way students learn to work as a team and get to accomplish larger tasks faster and easier.

How could it work in education?

Translation of FLOSS principles to education

At the beginning of a FLOSS project it is important that a succinct and well defined mission-statement is put together (for example the Free Desktop mission statement and that ways of working are defined such as Linux workgroups.

Education projects, like all FLOSS projects should consider the need for a steering committee for large projects. For small projects a person (sometimes called a `Benevolent Dictator’) to make a final decision should be considered.

Summary / Resume

What have we learned here?

Questions

Aspects to be answered

Notes and references

Resources used, literature, etc

http://www.oss-watch.ac.uk/resources/roles.xml

Back to mainpage