1.1 --- a/thesis/tex/2-FreeSoftwareProjects.tex	Thu Oct 09 20:59:49 2008 +0200
     1.2 +++ b/thesis/tex/2-FreeSoftwareProjects.tex	Fri Oct 10 18:18:34 2008 +0200
     1.3 @@ -37,9 +37,10 @@
     1.4  
     1.5  Eric S. Raymond discusses about these methods, which he named \name{the bazaar} and \name{the cathedral}. %FIXME: add reference
     1.6  
     1.7 +The following text will focus on the ``bazaar'' model.
     1.8 +
     1.9  
    1.10  \section{The role of the community}
    1.11 -%FIXME: this focuses on the ``bazaar'' way!!
    1.12  \freesw\ projects rise and fall with their community!
    1.13  
    1.14  Most \freesw\ programs are developed by a very small group of programmers, often only one person. But they are used by many people. In between the programmers and the users, are people located who are a bit of both. These are the ones that write documentation, find bugs and probably even fix it. They discuss on mailing lists, bulletin boards and \NAME{IRC} chats. The program is often spread by their ``advertising''.
    1.15 @@ -65,11 +66,23 @@
    1.16  
    1.17  \section{Creating a strong community}
    1.18  Building up a good community needs some effort of the main developers.
    1.19 +%TODO: search for documents about this topic
    1.20  
    1.21  First communication channels need to be set up, to enable the growth of a community.
    1.22  
    1.23 -Second, there is a rule of thumb that should be followed: ``Release early, release often!'' %FIXME: add reference
    1.24 -This means that development should be visible by everyone who is interested in it. Time between work done on the project and its visibility by the public should be kept short, too. This makes it interesting for other developers to join.
    1.25 -For users, (more) stable versions should be released, frequently. Hence they will more likely use the program.
    1.26 +Second, development should be visible by everyone who is interested in it. Time between work done on the project and its visibility to the public should be kept short. This makes it interesting for other developers to join. Developers are the core of a community.
    1.27  
    1.28 +Third, there is a rule of thumb that should be followed: ``Release early, release often!'' %FIXME: add reference
    1.29 +Releases are (more) stable versions, primary for users. They should be created, frequently. People will more likely use programs of active projects.
    1.30  
    1.31 +Fourth, the developers should try to get the users ``in the boat''. Good communities have a large group of users that do not only receive, but also give something back to the project. The project leaders should motivate users to contribute. This unlocks a big work force and gets lot of unexiting work done.
    1.32 +
    1.33 +Fifth, documentation matters. Good documentation makes it easy for users and developers to start. And it helps to avoid a lot of unsatisfaction. Documentation is something that shows quality and that people care about the project.
    1.34 +
    1.35 +And sixth, project leaders should be good %FIXME: ``herrscher''
    1.36 +. Never should they forget what %FIXME: who was it?
    1.37 +said: ``%FIXME: Die Könige sind die Sklaven des Volkes. (something like that)
    1.38 +''. They should try to be fair, to motivate, be visionaires and try to put power and work on many shoulders.
    1.39 +
    1.40 +Not to forget: Every work that was done, every contribution that was made and every idea received needs to be honored in an appropriate way! Voluntier %FIXME: how is it spelled?
    1.41 +work lives by acknowledgement of the effort spent.