Realising and Coordinating e-Research Endeavours Openly Position Statement Matthijs den Besten

advertisement
Position Statement
Realising and Coordinating e-Research
Endeavours Openly
Matthijs den Besten
OeRC
Ross Gardler
OSS Watch
March 12, 2007
The methods, technologies, and, in particular, the practices that have emerged alongside
open source software development are, from our point of view, key to realising and
coordinating e-research endeavours. Well known open source efforts like Apache and the
Linux Kernel Project deserve to be studied further as they are likely to provide clues as
to how to make sure that the e-infrastructure will be sustained, how to make sure that
the tools and techniques that are being developed are appropriate for e-research, and
how to make sure that resources and expertise are pooled effectively.
In fact, there are many different models for development within open source. Here we
will focus on the “meritocratic” governance model that is associated with the Apache
Software Foundation and the “benevolent dictator” model associated with the Linux
Kernel Project. The main difference between these two models can be crudely summarised as follows: In a benevolent dictator model a single person is responsible for all
decision making while in a meritocracy the ability to make decisions is awarded to those
participants that demonstrate their understanding of the project through contributions
to that project. Both models recognise the importance of a community to support the
project. Where they differ is in what authority and responsibility that community holds.
The leadership, be it a group or an individual, should look to the wider community for
input before making any given decision. However, the leadership is responsible for resolving any conflicts that emerge within the community.
The importance of the establishment of a community around a project cannot be
overestimated. A project community consists of anyone interested in using the outputs
of the project and/or contributing to the outputs of the project. Usually it is important
to create as large a community as posible in order to ensure that the project is able to
draw on the widest possible knowledge base. Membership of the project community can
be anything from completely open to completely closed. In the completely open model
anyone can join the community simply by joining the provided communication channels
for community members. In the completely closed model only those invited to join are
1
able to do so. It is also possible to provide a two tiered community membership, where
a completely open community is available for users of the outputs of the project and
a restricted community for contributors to the project. Membership of this restricted
community is managed by some defined process such as invitation from an existing
member or a simple request from an interested party. In general however, it is widely
accepted that the more open a community is, the more valuable it is.
Regardless of the governance model, it is desirable for the community to come to
an agreement about the correct choice to take at any given decision point within the
project. However, this is not always possible and conflicts within the community are
bound to occur. It is in the resolution of these conflicts that the differences in governance
models beomce important. In a benevolent dictatorship conflict resolution is easy. The
decision of the benevolent dictator is final. All members of the community must choose
to respect that decision, or leave the community. The benevolent dictatorship model
ensures that there is no possibilty of the project being driven in the wrong direction as
it concentrates all decision making powers in a single central figure. Still, the dictator
in charge is bound to consult with the wider community and should try to ensure that a
fully informed decision is made. Failing to so would mean that the project community
will simply leave and set up a new project with a different leader or leadership model.
In contrast, in an Apache-like meritocracy conflicts are resolved by a vote. Voting rights
are awarded to those who are recognised as community members whose objectives and
understanding of the project are sufficient to allow them to make the ”right” decision
for the project as a whole. A meritocratic model allows for a number of leaders to
collectively make decisions in a democratic way. Thus it allows the skills required to run
a project to be spread across a number of individuals.
In practice there are many other governance models available besides the Apache
meritocracy and benevolent dictator model of the Linux Kernel Project. What they all
share, however, is the need to develop, support, and follow the wishes of the community
that makes up the project. Indeed, the sustainability of any of these projects may
depend on nothing less. In case of e-research and e-infrastructure projects, life might
be complicated by the fact that these projects have been created in interaction with
funders. This interaction can be a problem in sofar as it leads the people in charge of
the project to spend too much time trying to meet predefined milestones without enough
time to engage with potential end-users early on and without enough leeway to steer
away from the preconceived plan as the needs arises. Moreover, the interaction can pose
a problem in sofar as people feel the need to make sure that their own contribution is
accounted for and eshew situations where the contribution is dilluted or were posible
mistakes would be exposed. Still, we feel that a number of successful open source
projects could serve as a valuable example to the e-research community as it tries to
encourage collaboration, manage the relationship between various stakeholders, tries
to find the approriate tools, matches the falicilities with particular user-groups, tries
to find opportunities for commercial development and tries to promote and support
sustainability.
2
Download