Result for Question 3

Show All Relevant Data (Sort by Controversy)

Show Only Top Ten
Show Only Numerical Data
Show All Relevant Data (Sort by Rating)

Go to Question 2
Go back to the List of Questions
Go to Question 4

3.

What work practices and culture should be promoted?

Average
Totally
Irrelevant
Extremely
Relevant
No. of
Votes

3.25 Avoid force
  4.0
8
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Brendan avoid force
Comment made in round 2
Chris This is good in general, but like 3.13, you have to give up at some point. If a project leader is being an idiot, try to work it out peacefully, but if it doesn't, then doing something forceful like forking the project or asking him out might be required to keep the levels of fun and interest up.
Neil eh?
Relevant Glossary
fork, or forking of a project
3.7  
9

3.34 The practices of Extreme Programming
  4.3
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Noah Development practices along the lines of Extreme Programming.
Comment made in round 2
Chris While I practice XP myself and think it would apply well to a good number of projects, I don't think it would apply to *all* projects. The creators of XP are the first to admit this.
Neil This is very cool. Most sites do not help pair programming and refactoring, and it's necessary
Relevant Glossary
Extreme Programming
3.5  
10

3.18 The value of heterogeneity, differences as assets
2.8  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Schulhoff Acknowledgement of developers different cultural and technical backgrounds as a positive element - very different from corporate monocultures.
Alvin They shouldn't promote any particular practice. The heterogeneity of approaches is one of the strengths of the way things are done without these infrastructure sites.
2.6  
10

3.19 Nothing should be 'promoted'.
  4.6
9
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Alvin They shouldn't promote any particular practice. The heterogeneity of approaches is one of the strengths of the way things are done without these infrastructure sites.
Comment made in round 2
Garrett Hosting sites are great places to promote projects which are successful, so that others will learn about them. Lack of knowledge about what quality projects exist is one of the great faults of the Free Software/Open Source community today.
  5.0
9

3.2 Measurement of quality of code
3.4  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Terence There should be objective measures of code maturity, and specific
prioritization for new features, etc.
Comment made in round 2
Chris Conventional measurements (LOCs, function points and so on) are not interesting. Open source software is partly about a kind of natural selection of code. Bad code causes crashes, which annoys people, hopefully including some developer that will fix it. You also have subjective measurement of code quality by the contributing developers: if your code is poor quality, people will not contribute to it. Having everything done in the open imposes a self-enforced level of code quality that is higher than what would have been done in private (or in a closed source project).
Comment made in round 3
Garrett Measuring the quality of code? You've got to be kidding me. It's hard enough deciding what "quality code" even is.
Relevant Glossary
Software Measurements (LOC, Function Points)
3.1  
10

3.32 A system to attribute credit
2.8  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Luke Credit: There must be a kudo system to credit active contributors
Comment made in round 2
Chris One of the motivation of open source is getting credit and recognition (instead of money), so there should definitely be a way to get "paid". But at the same time, systematizing this kind of thing could seem wrong and counter to some programming practices (egoless programming, extreme programming).
Neil USeful for those who wish to brag, or more important when a projects copyright is being tested
Comment made in round 3
Garrett Since many of us aren't being paid, it helps a lot if we get credit in the 'noosphere', as ERS has written about.
Relevant Glossary
Egoless Programming
3.0  
10

3.4 Reinforcing explicit development roles
  4.2
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Terence Explicit descriptions (suggestions?) of development roles needed
to fill for project development.
Comment made in round 2
Chris Hackers are often jacks-of-all-trades. Pigeon-holing them is bad. But you will sometimes see one say that he won't do web site work and will have someone else maintain a web site for example.
Comment made in round 3
Garrett It's good for 'roles' to not be taken too stringently in FS/OS. Many of us are 'all-purpose' developers. The diversity we are exposed to can't let us get stuck in one 'role'.
  4.9
10

3.37 Fun and good spirit and hope
2.1  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Leslie Fun and good spirit and hope
Comment made in round 2
Chris We're not being paid for this, remember? If it's not fun, nobody will do it. Now, it sure helps that some people have twisted and sicks ideas of what is fun, that is one of the things that the sheer numbers of open source helps... :-)
Neil If you don't like it, don't do it.
2.1  
10

3.13 Tolerance, respect and patience
2.7  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Joanne The culture would have to be one of tolerance. Most open source software is still done by volunteers (who have other jobs). Deadlines must remain flexible. Teleconferencing must be at a mutually agreed upon time (people could be and probably will be in different time zones). Also, the more people working on a project, the more ideas will be generated. All participant's should be listened to. You get a better product and happier participants.
Phil respect other people
Brendan tolerance toward others particularly across languages and cultures
Brendan patience but firmness
4 Responses
Comment made in round 2
Chris This is important, but the natural selection scheme of open source depends on the bad ideas being culled. Being too nice to someone that is an idiot and keep introducing bad ideas in a design is wrong. You give people a few chances when they mess things up, but at some point you have to say "stop".
2.1  
10

3.14 Awareness of different culture and language background
3.3  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Schulhoff Acknowledgement of developers different cultural and technical backgrounds as a positive element - very different from corporate monocultures.
Brendan tolerance toward others particularly across languages and cultures
2.9  
10

3.28 Using centralised repository for source code
2.0  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Dave Checking code into a common repository.
Comment made in round 2
Chris Sometimes, things that are too experimental are better run as a side project. For example, witness the "ac" series of Linux kernels, which have more leading edge things in it. The people using these kernels are aware that they are being guinea pigs, and the things deemed good and stable are then sent over to the mainline kernel tree.
1.9  
10

3.22 Cooperation and collaboration, encourage involvement of developers to share the load of development
2.8  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Jacob collborative and distribtuted software development
Patrick decentralised decision-making - necessary for scaling to large projects, but also important for encouraging developer involvement
Brendan cooperation
Brendan sharing the load
Luke Inviting environment: This means that the tools must be easy to use, not take too much time away from actual develpoment and allow for easy addition to becoming a project member.
5 Responses
Comment made in round 3
Garrett Very tough thing to do; I'm not sure how/if one should really go about this.
2.5  
10

3.11 Distributed style of development and decentralised decision-making
2.9  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Jacob collborative and distribtuted software development
Patrick decentralised decision-making - necessary for scaling to large projects, but also important for encouraging developer involvement
2.4  
10

3.20 Openness in attitude, no hidden agenda
2.4  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Phil everything should be open, no hidden agenda
Patrick transparency - openness about procedures and policies
2.3  
9

3.31 Flexibility in tools for rapid project administration
3.6  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Luke Flexibility: Open Source projects are dynamic and can be very fast moving and have the potential to break new ground. The tools must then be flexible and allow the project admins as much control over the tools as possible.
3.2  
9

3.6 Do not focus on the volume of software created, but usefulness
2.4  
9
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Mark reuse of existing code by developers! sourceforge in particular fails horribly to promote a culture of reuse, by collecting and "ranking" statistics on such misguided metrics as "number of new commits to CVS". since sourceforge is a commercial venture, they want to promote the multiplicity of projects, but this behaviour undermines the central benefit of free software: reuse and modification of others' code.

clarification: the "number of new commits to CVS" is a very sourceforge-specific example, and is meaningless as a general survey concept. they also, for example, have a "new projects this week" statistic which is troubling. what I really wanted to get at was: don't focus the site purely on the "creation of new software" (though this is perhaps the most fun part of programming) but rather on "finding software which solves your problem". e.g. make it easy for one project to depend on another (or several others), make it easy to cross-reference documentation between projects, etc.
Comment made in round 2
Neil All software is valuable, regardless of size or purpose. None should be discouraged.
Comment made in round 3
Garrett A lot of software is created merely to 'learn.'
Relevant Glossary
Concurrent Versions System , SourceForge
2.5  
10

3.24 Keeping promises
3.4  
8
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Brendan fulfilling contracts

clarification: doing what you say that you will do and expecting others to do what they say they will do
Comment made in round 2
Neil If a site agrees to make their CVS server stable, it should be stable. :-)
Relevant Glossary
Concurrent Versions System
3.1  
8

3.8 Computer science/software engineering knowledge
3.2  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Mark a respect for theoretical CS. there is essentially zero theoretical learning material on most infrastructure sites. any documents they collect are of the ground level, "how to" sort, possibly in cookbook or "code fragment" form. it is implied that all one needs to learn is "how to write C, and how to use CVS" and everything else is boring or unimportant.
Joanne What 'should be' promoted? All good software engineering techniques: requirements elicitation and specification, design, coding, testing.
Comment made in round 3
Garrett Helps a great deal, but is not necessary.
Relevant Glossary
Concurrent Versions System
2.9  
10

3.7 Emphasis on history, reuse old resources
2.9  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Mark in general, "history" rather than "the future". too many documents are lost in obscure FTP archives. too many new projects are founded to produce programs which have been made already. nowhere near enough emphasis is placed on "reading and learning from the past". free software is as relevant as an academic tradition as it is as a commercial force, if not moreso.
Comment made in round 2
Chris There is a part about reusing old resources, but if something becomes irrelevant, it is replaced with extreme prejudice. There is no place for legacy code in open source, which is both a quality and a problem. The code is clearer and more stable (in medium and long term) because of this, but it might be less stable at short term (while change is ongoing) and backward compatibility suffers ("upgrade or die" seems to be the motto of library developers).
3.1  
10

3.15 Awareness of different technology background
3.7  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Schulhoff Acknowledgement of developers different cultural and technical backgrounds as a positive element - very different from corporate monocultures.
Comment made in round 3
Garrett FS/OS is a good deal about learning, and being aware of different technologies helps learning a lot.
3.5  
10

3.30 Easy to use, high usability
2.6  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Luke Inviting environment: This means that the tools must be easy to use, not take too much time away from actual develpoment and allow for easy addition to becoming a project member.
Noah Usability.
2.2  
10

3.33 Standards in software design
3.0  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Noah Software Design Patterns.
2.6  
10

3.21 Openness in procedures and policies
2.5  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Patrick transparency - openness about procedures and policies
2.1  
10

3.36 Standards coding style
3.1  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Noah Strict adherence to the selecetd style for the programming language used.
Gabriel Adhere to commonly agreed upon coding and writing standards
Comment made in round 2
Neil K&R is Evil(tm). The "GNU Coding Standards" are wrong and lead directly to lesser quality code.
Relevant Glossary
GNU Coding Standards , K&R
3.0  
9

3.23 Firmness
  4.7
7
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Brendan patience but firmness
Comment made in round 2
Neil eh? No one likes a flabby arse.
Comment made in round 3
Garrett Too much firmness can cause objects to 'shatter' (fork)
  4.9
8

3.16 Listening to others
2.3  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Joanne The culture would have to be one of tolerance. Most open source software is still done by volunteers (who have other jobs). Deadlines must remain flexible. Teleconferencing must be at a mutually agreed upon time (people could be and probably will be in different time zones). Also, the more people working on a project, the more ideas will be generated. All participant's should be listened to. You get a better product and happier participants.
Comment made in round 2
Chris Up to a point. See 3.13.
2.2  
9

3.9 Creating a public library atomsphere, giving users as much freedom as possible and staying out of the users' way
2.0  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Mark staying out of the user's way. nothing is more annoying than a paternalistic site that tries to impose the "right" process on its users. an infrasturcture site ideally resembles a public library or community center: lots to read, see and do, minimal procedure required for just browsing. all facilities should be linked off the first page, accessible through email-only or shell-only interfaces, and require no "registration" or special click-through paths to operate.

expansion: "public library atmosphere". anonymous, focused on research, browsable (sourceforge has got the browsable code portion right, but for example there is no automatic facility for formatting a project's documentation for the web, so a visitor is unlikely to read it)
Relevant Glossary
SourceForge
2.1  
10

3.12 Welcome help from less skilled developers and understand their potential to become high skilled developers
3.1  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Schulhoff Legitimate Peripheral Participation - Less skilled developers must be allowed to participate at their own level. Less skilled developers must be viewed as potential high skilled developers, given the time to evolve.
Brendan openness as to skills and time commitments
Comment made in round 3
Garrett Without this, we end up with the cathedral mentality.
2.8  
10

3.17 Flexibility towards volunteers
2.1  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Joanne The culture would have to be one of tolerance. Most open source software is still done by volunteers (who have other jobs). Deadlines must remain flexible. Teleconferencing must be at a mutually agreed upon time (people could be and probably will be in different time zones). Also, the more people working on a project, the more ideas will be generated. All participant's should be listened to. You get a better product and happier participants.
Brendan openness as to skills and time commitments
1.7  
10

3.5 Reuse of existing source code
2.1  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Mark reuse of existing code by developers! sourceforge in particular fails horribly to promote a culture of reuse, by collecting and "ranking" statistics on such misguided metrics as "number of new commits to CVS". since sourceforge is a commercial venture, they want to promote the multiplicity of projects, but this behaviour undermines the central benefit of free software: reuse and modification of others' code.

clarification: the "number of new commits to CVS" is a very sourceforge-specific example, and is meaningless as a general survey concept. they also, for example, have a "new projects this week" statistic which is troubling. what I really wanted to get at was: don't focus the site purely on the "creation of new software" (though this is perhaps the most fun part of programming) but rather on "finding software which solves your problem". e.g. make it easy for one project to depend on another (or several others), make it easy to cross-reference documentation between projects, etc.
Relevant Glossary
Concurrent Versions System , SourceForge
2.4  
10

3.10 Documentation of source code and standards in writing style
2.7  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Joseph commenting source code
Gabriel Adhere to commonly agreed upon coding and writing standards
2.6  
10

3.26 Critique for the sake of the task
2.9  
10
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Brendan critique for the sake of the task

clarification: (previous answer: critique for the same of the task) mistyping on my part. should be critique for the sake of the task. that is being constructively critical of products, procedures and people including task leaders
3.3  
10

3.35 Clarity, simpleness of code
2.1  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Noah Clarity, simpleness of code.
1.7  
10

3.3 Prioritization of new features
3.2  
9
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Terence There should be objective measures of code maturity, and specific
prioritization for new features, etc.
2.6  
9

3.29 To include automated building and testing facilities in releases
2.5  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Mark to provide automated building and testing facilities
Dave Providing release build testing.
1.8  
10

3.38 Frequent submissions of contributions
2.3  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Gabriel Frequent submissions of contributions
Comment made in round 2
Neil Speed of projects is irrelevant - particularly volunteer led ones.
Comment made in round 3
Garrett Having things move fast is one of the things that people like about FS/OS. Without it, users lose interest in projects, and following that, developers also lose interest.
2.5  
10

3.1 Sense of responsibility
2.5  
11
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Terence There should be a chain of responsibility for each addition to the
code
2.6  
10

3.27 Jane Jacob's systems of survival's commercial moral syndrome
1.5  
2
Details
Answer from Previous Round
This sub-question is summarised from the following answer(s) from round 1
Brendan jane jacob's systems of survival's commercial moral syndrome
Comment made in round 2
Neil Provide a hyperlink to what you mean here. http://www.grist.org/articles/2000/00.10.19_Systems_of_Survival.html
Relevant Glossary
Jane Jacobs' Systems of Survival - Commercial Moral Syndrome
2.0  
2

Show Only Top Ten
Show Only Numerical Data
Show All Relevant Data (Sort by Rating)

Go to Question 2
Go back to the List of Questions
Go to Question 4

Generated On: 25 Oct 2002