3. |
What work practices and culture should be promoted? |
Totally Irrelevant |
Extremely Relevant |
|
|
3.1
|
Sense of responsibility |
|
|
3.2
|
Measurement of quality of code
Comment: |
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).
|
|
|
|
3.3
|
Prioritization of new features |
|
|
3.4
|
Reinforcing explicit development roles
Comment: |
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.
|
|
|
|
3.5
|
Reuse of existing source code |
|
|
3.6
|
Do not focus on the volume of software created, but usefulness |
|
|
3.7
|
Emphasis on history, reuse old resources
Comment: |
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.8
|
Computer science/software engineering knowledge |
|
|
3.9
|
Creating a public library atomsphere, giving users as much freedom as possible and staying out of the users' way |
|
|
3.10
|
Documentation of source code and standards in writing style |
|
|
3.11
|
Distributed style of development and decentralised decision-making |
|
|
3.12
|
Welcome help from less skilled developers and understand their potential to become high skilled developers |
|
|
3.13
|
Tolerance, respect and patience
Comment: |
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".
|
|
|
|
3.14
|
Awareness of different culture and language background |
|
|
3.15
|
Awareness of different technology background |
|
|
3.16
|
Listening to others
Comment: |
Up to a point. See 3.13.
|
|
|
|
3.17
|
Flexibility towards volunteers |
|
|
3.18
|
The value of heterogeneity, differences as assets |
|
|
3.19
|
Nothing should be 'promoted'. |
|
|
3.20
|
Openness in attitude, no hidden agenda |
|
|
3.21
|
Openness in procedures and policies |
|
|
3.22
|
Cooperation and collaboration, encourage involvement of developers to share the load of development |
|
|
3.23
|
Firmness |
|
|
3.24
|
Keeping promises |
|
|
3.25
|
Avoid force
Comment: |
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.
|
|
|
|
3.26
|
Critique for the sake of the task |
|
|
3.27
|
Jane Jacob's systems of survival's commercial moral syndrome |
No Comment |
|
3.28
|
Using centralised repository for source code
Comment: |
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.
|
|
|
|
3.29
|
To include automated building and testing facilities in releases |
|
|
3.30
|
Easy to use, high usability |
|
|
3.31
|
Flexibility in tools for rapid project administration |
|
|
3.32
|
A system to attribute credit
Comment: |
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).
|
|
|
|
3.33
|
Standards in software design |
|
|
3.34
|
The practices of Extreme Programming
Comment: |
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.
|
|
|
|
3.35
|
Clarity, simpleness of code |
|
|
3.36
|
Standards coding style |
|
|
3.37
|
Fun and good spirit and hope
Comment: |
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... :-)
|
|
|
|
3.38
|
Frequent submissions of contributions |
|