Hardware Reference
In-Depth Information
Task
Description and Evidence Sources
Release new versions
of the product
Release processes in Open Source often include the crea-
tion of a number of alpha, beta and release-candidate
versions that are delivered by the developers in order to
obtain feedback from the community (active users of an
OSS system are often willing to test these versions and
report about problems they may find). Release processes
also often include running a test suite or performing other
forms of formal testing.
This process can be followed by looking at release an-
nouncements for preliminary versions in a project's mail-
ing lists or forums. Actual releases can be easily found in
software download repositories.
Backport corrections
in the current release
to previous stable
releases
When a stable and an unstable (development) branch of a
project are maintained simultaneously, so-called
back-
ports
are often necessary that move corrections or se-
lected improvements made to the development branch
into the stable branch.
Backports are often announced in project mailing lists
or forums.
5 Initial Experience with the QualOSS Process Evaluation
To this date, our experience with the QualOSS process evaluation is still quite limited,
since we have applied it to only a handful of projects so far. A larger number of full
QualOSS OSS assessments—which include the process assessment—is planned for
the final, evaluation phase of the QualOSS project. We expect this effort to result in
significant adjustments to the process assessment framework, as we better understand
its limitations and improve it accordingly.
Nonetheless, our current experience has already taught us some valuable lessons:
In its current form, the QualOSS process evaluation can be applied to small to me-
dium OSS projects in about six hours of work. This makes its costs reasonable for
a number of purposes, including comparison when selecting between OSS alterna-
tives. A caveat here is that, so far, evaluations have been conducted exclusively by
an OSS and process expert. We still have to evaluate our approach when applied
by other assessors who may lack this expertise. This includes, among other aspects,
studying inter-rater reliability in this context.
−
−
The time box limitation of 30 minutes of searching may lead to important informa-
tion being missed. One alternative for handling the collection of information about
a task would be to ask the community directly, for example, by writing to an ap-
propriate mailing list. This would not only make this aspect of the process evalua-
tion fairer, but would potentially create opportunities for the community to learn
from the evaluation and improve based upon it.
