From Symbian Developer Community

The principal point of FOSS is to have a community to work together on the software. Releasing software for use by others but without allowing them to participate is little different from releasing proprietary software with a zero license fee.

A FOSS community is like any other community – its members need to develop norms of behaviour in order to work together effectively.

A FOSS project may include more than one type of community, in fact this is common. A FOSS project may include a group of users and a group of contributors and these groups will have different levels of commitment and different needs. The terms ‘users’ and ‘contributors’ have specific meanings within the FOSS world. Users use the software while contributors provide some contribution to the project.

Users simply want access to software that meets their needs. Beyond immediate access to the software, users benefit from active forums to provide some form of support and a live roadmap to guarantee that the software will not just stagnate.

Contributors are also users (which is one reason why they are motivated to meet the needs of the users) but contributors want a say in the roadmap so that they have a chance of influencing it in directions that benefit them and they want to be able to get their contributions accepted into the project. Contributors may provide code for bugfixes and new features (the most obvious form of contribution) but they can also contribute support services, translations, documentation etc.

The contributing community do not need to like each other but they have to be able to work together collaboratively. Sometimes, the contributors will even be competitors (this topic is covered elsewhere) but even if they are not, their interests may not always be the same.

Given the diversity of interests in the contributing community, there is a need for a process to create the roadmap and a need for a process to control contributions. A roadmap may be a clear plan of what will be developed or may simply give some indication of which features will be accepted and which will be rejected. If contributions are rejected arbitrarily then their developers may stop contributing while if unsuitable contributions are accepted then the whole project is at risk of being de-stabilised.

Regardless of the details of the processes used to manage roadmaps and contributions, they must be transparent. If the reasons for decisions are not clear then community members will become disillusioned. If the reasons are clear then members may still disagree with the decisions but at least they have a chance of working with future decisions.

Attracting Participants

As a community, any FOSS project needs to attract participants to grow or simply to stay alive. Most FOSS projects have some form of plan for the future (formal or informal) and so need contributors to develop new features. Even if a FOSS project has no plans for future enhancements, defect fixes and security updates are still required. FOSS projects with no activity are common (browse through any of the public open source repositories for examples) but they are also dead. This lack of interest can happen for a number of reasons, for example, projects can merge, they can be superseded by newer projects or the software can fulfil its original need and reach a high level of maturity.

Many smaller FOSS projects are the work of an individual contributor but larger ones rely on a community. Over time, some contributors, whether individuals or organizations, drop out as their needs or circumstances change or as they move to competing projects. This means that a healthy FOSS project continually needs to attract new participants.

In most FOSS projects, participants start as users of the software who may then be motivated to learn more about the project and to contribute. In order to attract users, a FOSS project needs to offer real benefits. This does not mean that the project has to be complete – many FOSS projects spend years in development versions – but it really helps if they are complete enough to be of value to some users.

The number of new contributors will depend on the balance between the benefits of entry and the barriers to entry.

Benefits for new users are normally based on the functionality and value of the software so a more functionally rich project is more likely to appeal to new users.

Benefits for new contributors can include ensuring that a feature that they want is included in the project and ensuring that bugs that are causing them problems are fixed. They may want changes that other participants are not interested in (so they cannot simply wait for somebody else to make them) or they may want to accelerate their development. Essentially, they believe that they will obtain benefits by contributing to the project that justify the investment of doing so.

Barriers to entry for contributors can include the difficulty of becoming a user in the first place. If a project is unstable, includes little or no user documentation or is difficult to deploy then it increases the chance of potential users giving up. Once a user is active, good discussion forums help to overcome problems and can also give a sense of community. In contrast, a project where nobody is prepared to help newcomers or, worse still, where existing members pour scorn on naïve questions will put off all but the strongest users.

If a user wants to contribute then a fresh set of potential barriers come into play. In order to contribute, a developer needs access to the source code, the ability to build the software and to test it and a different set of support forums. It also helps if there is a prominent list of bugs to fix or other introductory tasks.

Source code can normally be accessed using one of a handful of free source code management tools but building can be very difficult. Historically, older and simpler Unix or Linux programs would have a configuration script and use make and a C compiler. For these programs a standard sequence of commands was all that was needed. Once programs began to rely on shared libraries they began to have dependency problems. A lot of work has been done in Linux and similar distributions to manage dependencies for packaged software but dependencies among the libraries and development packages are less mature. The large and more complex programs tend to be harder to build than the simpler ones and programs designed to work in a range of environments tend to be harder to build than those that only work in a single environment.

Existing developers on a project may not be worried by an idiosyncratic build system (by definition, they have overcome the problems) but they should be aware of the potential contributors that they may lose.

Testing is of critical importance to most projects and investment in a good automated test system can pay dividends in preventing regressions (or at least catching them so early that they never make it into the wild). If a project has a good set of tests then a condition for any contribution should be that it does not break any tests. If a contribution includes a new feature (as opposed to being a bug fix) then it should also include new tests to cover the new feature. All of this assumes that a contributor can run the automated tests. If the tests are difficult to run then contributors will either ignore them (and rely on a committer to run them on their behalf) or will abandon their contribution. Therefore, the test system needs to be as robust and as well documented as the main project.

If new users need documentation and support then this is even more true for new contributors. Some projects declare that the source is the documentation and expect new participants to read the code to work out what is going on. This may be acceptable at the earliest stages of a project but is guaranteed to put off participants once the project matures. The same type of arrogance can be a problem in developer forums. A FAQ can save time for everyone and avoid loss of face for beginners but an active and supportive forum is really essential to introduce new contributors, particularly as most FOSS projects cannot rely on co-location.

It can be seen that existing participants need to invest effort on areas beyond the core source code if they want the benefits of a healthy community. Documentation, the creation of a robust build system, the maintenance of good tests and supporting user and developer forums are all key to the long-term success of a FOSS project.

Structured communities

In smaller FOSS projects, users and contributors may be the only types of participant required but in larger and more complex FOSS projects, additional levels of organization may be necessary. When a project is too large for any one individual to know the whole codebase it needs to be divided into smaller units - in the case of the Symbian Foundation, these are called packages and each is represented by a package owner who is the public face of the package.

When a project has to be divided in this way, it is inevitable that it will also need processes to co-ordinate between the parts and so the Symbian Foundation has defined a council to oversee architecture and one to agree on roadmaps.

Comments

Sign in to comment…