Posted by mady | Posted in Open Source Development vs. Traditional Processes | Posted on 12:43 AM
Once the originator is ready to invite others into the project he
makes the code base available to others and development proceeds.
Typically, anyone may contribute towards the development of the
system, but the originator/owner is free to decide which contributions
may or may not become part of the official release. The open source
development (OSD) model is different from traditional in-house
commercial development processes in several fundamental ways. First,
the usual goal of an open source project is to create a system that is
useful or interesting to those who are working on it, not to fill an
commercial void.
Developers are often unpaid volunteers, who contribute towards the
project as a hobby; in return, they receive peer recognition and
whatever personal satisfaction their efforts bring to them. Sometimes
this means that much of the effort on an OSD project concentrates on
what part-time programmers find interesting, rather than on what might
be more essential. It can be difficult to direct development toward
particular goals, since the project owner holds little power over the
contributing developers. This freedom also means that it can be
difficult to convince developers to perform essential tasks, such as
systematic testing or code restructuring that are not as exciting as
writing new code.
makes the code base available to others and development proceeds.
Typically, anyone may contribute towards the development of the
system, but the originator/owner is free to decide which contributions
may or may not become part of the official release. The open source
development (OSD) model is different from traditional in-house
commercial development processes in several fundamental ways. First,
the usual goal of an open source project is to create a system that is
useful or interesting to those who are working on it, not to fill an
commercial void.
Developers are often unpaid volunteers, who contribute towards the
project as a hobby; in return, they receive peer recognition and
whatever personal satisfaction their efforts bring to them. Sometimes
this means that much of the effort on an OSD project concentrates on
what part-time programmers find interesting, rather than on what might
be more essential. It can be difficult to direct development toward
particular goals, since the project owner holds little power over the
contributing developers. This freedom also means that it can be
difficult to convince developers to perform essential tasks, such as
systematic testing or code restructuring that are not as exciting as
writing new code.
