Hello there, and good luck for your project...
I am not an expert on this, but I want ot give a few ideas:
PS: I am not a debian devleoper, I simply contribute.
From: Astrid Karin Furre
Sent: 1/27/03 12:41 PM
We are two girls studying at Stavanger University College,computer
We are now working on a project,where we want to do some researh and
develop an open-source-code-solution on an already existing program..
We need some help with our research,and have some theoretical questions
we want to answer.
Company-internal use of the open source-code concepts.
Which benefits and risks are there for a large corporation in applying
theseconcepts in web-solution development? (Sharing and collaboration
between several business units in the corporation.) How does this relate
to a "buy, not build" policy, used by many large corporations? Suggest
how to apply these concepts in sharing, maintaining and further
developing, a small existing web-solution.
* What are the concepts used in open source-code systems development?
I think the concepts used in open source development are not fundamentally
fifferent from concepts used in "closed-source" development. There are
possiobly two exceptions:
a) You will not use code/concepts that are licensed under a non-free
b) Since you are usually devleoping in a team, clear/legible code as well as
good documentation are key factors. But you'll do that anyway, I guess.
* How are these projects/developments being managed?
Usually a project leader is assigned, and code is developed in a
collaborative manner, usually with tools like cvs helping development.
* Cooperation tools used?
I'd say the use of cvs (http://cvshome.org) is rather widespread. In the
case of the debian project, packages are also digitally signed with gnupg
(http://www.gnupg.org). Mailinglists are also often used, with either
Mailman (http://www.list.org) or majordomo being used.
* How are version control and quality assurance taken care of?
VC see above, quality control: Debian has a quality control team.
* Identify strengths and weaknesses of these concepts.
- Incentives to develop/improve software can be non-moetary/non-commercial
(the simple fact that I have contributed to that program or found a bug in
- Since the collaboration is usually informal, quite a lot depends on the
leadership skill of the project leader(s). There are quite a few mismanaged
open-source projects. Also the term 'free software' is controversial to
neophytes (esp. that 'free' does not apply 'absence of cost, more on this on
the fsfeurope website (www.fsfeurope.org))
* Compare with "buy, not build" policy and the rationale behind
Does anyone of you know something about this stuff? We are really
thankful if you send us an e-mail as soon as possible.
Astrid Karin Furre and May Elin Fjelde
Ny versjon av Yahoo! Messenger
Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så