[ox-en] Re: George Dafermos * An empirical study of division of labour in free software development

Hi George, hi list!

4 days ago Stefan Merten wrote:
> Below there is also a text representation which is useful
> for quoting.

I'll use this for some comments and questions on this very interesting
contribution.

> Forking
> =======
> 
> * Right to fork = Easy access to exit option
> 
> * Exit option dampens the emergence of conflicts

@George: Can you explain this a bit?

> * Forking is an extreme example of the exit option
> 
> * Conflicts are usually translated into parallel development lines
> 
> * Under which conditions does a project fork?

@George: Of course an interesting question - especially beacuse forks
are rare which is probably against expectations. Did you give any
answers in your talk?

> How-to become a committer
> =========================
> 
> ..
> 
>    If you submit enough useful and correct problem reports (PRs) [or
>    patches] eventually some committer will get sick of taking care of
>    your work and will ask you if you want to be able to commit them
>    yourself
> 
>    -- (M. Lucas, 2002)

May be the term "committer" needs a little explanation for the
non-technicians here. A committer is a person who has write access to
the code base. I.e. someone which has the power to do useful things
but also to do a lot of harm to the project. I.e.: a committer should
be a person who is responsible for her actions and acts in the best
interest of the project.

What the quote above says is that you become committer because you are
trusted enough by another committer. The trust is based on your
contributions in the past. I.e. you must have proven that you are

* able to make useful contributions

* take responsibility for the project

This is certainly not the we-are-all-equal thing - which would mean
that everyone has write access. I think this is a very important thing
to learn from peer production that if you get serious you need
regulations of who has write access.

The regulations here include ability and responsibility. So even if
you feel very responsible you may not have shown the abilities needed.
And you may have the abilities but did not show enough responsibility.

> Organisational structure
> ========================

The picture gives a nice impression of the hierarchy inside a project.
Again we do not have the we-are-all-equal logic but instead different
levels of contribution.

> Division of labour
> ==================
> 
> Division of labour is emergent: not dictated by the top but premised
> on self-selection of tasks.

I.e. the volunteers self-select from the necessary tasks. The job of a
maintainer is then to "define" tasks which someone can self-select
easily.

> Is the immediate result of the usual procedure by which one joins a
> project and advances from peripheral (yet necessary) activities such
> as defect reporting and fixing to the development of new
> functionality.
> 
> Participation asymmetry is explained by that participants contribute
> according to their abilities.

Which probably spells out to technical abilities and available time.

> Code ownership (Current branch, 2007)
> =====================================
> 
> * files with 1 committer: 31,831 = 47,4%
> 
> * files with 2 committers: 13,825 = 20,6%
> 
> * files with 3 committers: 5,577 = 8,3%
> 
> * files with >9 committers: 4,445 = 6,6%

May be some additional explanation for non-technicians is useful here,
too. On the level of a project a file is the atomic entity. Often
changes which add functionality or a fix need to be done on many files
at once.

What these numbers show is that in fact even in a big project like
FreeBSD half of the code is maintained by a single person and only
~25% have more than three committers. I think this is important to
know if people talk about cooperation in peer production. The
cooperation is often *not* on the level of the atomic entities but
rather on the level of cooperation between these atomic entities. In
fact that is something I see very similar in the Free Software
projects I participate in.


Seeing it this way a peer production project looks more like a group
of persons all doing their own, self-selected thing but collaborate
with others also doing their own, self-selected thing. They do this
because they and the project benefit from this type of collaboration.
In fact if I think a bit about it it seems like many modern projects
work this way.

I think it is important to understand that this type of collaboration
differs much from the type of collaboration which is usually
envisioned in movements with a stronger influence from capitalism -
like socialist movements of all brands. And of course in earlier
industry everyone *had* to do the same. They all were workers
basically being forced to literally do the same job.

This has changed to some degree already. There are many jobs which
need creativity and creativity is the opposite of everyone doing the
same. So peer production is the logical extension of this
inner-capitalist movement.

Though I always felt that there is a relationship between these
inner-capitalist movements and peer production I now think I
understand the structure of the relationship better. I think I learned
something new :-) .


						Grüße

						Stefan
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: [email protected]