Re: [ox-en] Re: Cooperation in Free Projects
- From: Stefan Merten <smerten oekonux.de>
- Date: Wed, 09 May 2007 15:05:22 +0200
Hi StefanS and all!
I'll quote a lot because this is a bit long ago ;-) .
5 months (161 days) ago Stefan Seefeld wrote:
Stefan Merten wrote:
3 weeks (22 days) ago Stefan Seefeld wrote:
Stefan Merten wrote:
There are projects that emerge from people that try to solve their own (little)
problem, and there are projects way too big to be worked on on such a scale.
How projects are managed, i.e. whether there *is* any form of formal management,
also depends on the project's size (how many contributors there are, how the code
is structured, how the user community(ies) look like, etc.)
It seems to me that our main disagreement is about the term 'formal'.
May be we can try to explain what we mean by that term. In fact I'm
not denying that there is management in Free Software projects - in
the contrary. For instance if you check the slide "Keyword: Maintainer
model"
[http://en.wiki.oekonux.org/Oekonux/Introduction/SlideKeywordMaintainerModel]
then you can see that I'm actively saying that there is some
management. Would you think that the things said on this slide are
more or less correct?
Probably: a) 'in general', and b) when talking about 'Doubly Free Software projects'.
(which, again, is quite a restriction)
When I said 'informal' I tried to outline what I mean. May be we can
go through this and see where it is flawed.
OK.
No fixed roles
When I think longer about what I actually meant is that the roles are
not bound to certain persons or formal qualifications. In principal
everybody can become a maintainer or something else. She doesn't need
any formal qualification for this.
Again, what does 'formal' mean in this context ? How specific is this
to Free Software, rather than some other cultural background ?
(I'm living in Canada, being formally trained as a physicist, but not
in computer science, yet I'm a professional programmer. Am I 'formally
qualified' ? I'm saying this because it seems 'formal qualification'
is much more a question of local culture than of Open vs. Proprietary
development.)
With formal I meant some formal education, indeed. Though I don't know
from personal experience I can easily imagine that the meaning and
value of formal education is considered different in different
cultures.
Well, in Germany there are also a lot of "non-educated" professional
programmers. However, if the labor market gets tighter they are more
in danger than those with a formal qualification. At least this is
what I learned. This is certainly different in Free Software.
But yes, I agree that in the realm of computers it is more normal in
the industry that non-educated people have jobs. However, I think this
is so due to the fact that too less well-educated people existed at
some point and I'm rather sure that this will change over time and
formal qualification is a requirement. Not so for Free Software.
As far as the definition of roles are concerned I'd agree with you
that there can be and sometimes are roles with a rather clear
definition. This involves more technical roles as well as governance
roles such as a maintainer. However, it seems to me that they are not
fixed but come into being as each projects needs them.
Right. But again: how different is that from the rest of 'the industry' ?
Again this may be a cultural thing as well. What I experience is that
exactly this doesn't happen - at least not in bigger corporations.
Instead you have departments which spend a lot of time and energy
fighting each other. Doing the job and creating necessary roles is
often so much subsumed to this permanent war that it simply comes not
about. (This is the point when I usually say (cynically): "In a free
market this would not be possible.")
I'd improve this into
Roles suited to the project's need rather than a fixed set of roles
No formal qualification needed
Would this make sense to you?
Yes, though, as I said, I can't see anything specific to FLOSS in
these points.
No appointed persons
Do you agree with that? What I read and see is that official
appointments are rare. And if there are such appointments then they
are usually only publicly acknowledging something which is already a
practical fact in the project. For instance I understood that Linus
appoints lieutenants after they are already doing the job. I'd see
this as a major difference to comemrcial jobs where the hierarchy
often is coming from outside the respective corporation and receives
their positions by appointment through higher management positions.
Yes, appointments are rare in Free Software.
For founders there even can not be some appointment procedure - they
appoint themselves by doing things and by living to a role in
practice. It seems to me that this is a general tendency.
I'd improve this to
Self-appointment as a general tendency
Official appointment as acknowledgment of a existing practice
Would this make sense to you?
OK.
While I'm thinking about it: I think the reason for this is that by
turning an existing practice into an official role you make such a
decision most transparent. A maintainer who only acknowledges an
existing practice she sees is already working is on the safe side. If
- as the other extreme - a maintainer appoints a stranger she takes
the risk that this decision is highly controversial.
Yes, if anything, transparency is certainly a quality of Open Source
projects. (Open == transparent, mostly)
No votes on people
Though there are a few exceptions such as a few roles in Debian
statistically this seems to be simply true to me.
Hmm, we may look at what 'vote' actually means. Does it refer to a
specific formal practice of counting how much support a single person
would have in a particular role ? Or does 'to vote' mean support
(even moral one) in general ?
I meant the formal procedure.
If many people contribute to a project, this may be counted as a form
of 'vote', too.
Well, if we understand everything under a certain concept, then we
understand nothing.
There are certainly a lot of cases between fully proprietary and fully Free, where
business models have adapted to take advantage of Free Software, yet are firmly
rooted in modern capitalism with everything that entails.
I'd find it useful to distinguish between Single and Doubly Free
Projects here.
Indeed.
To give a concrete example:
Thanks for this.
The GNU Compiler Collection (http://gcc.gnu.org/) is a huge project, with many
participating commercial entities, and a lot of commercial
end-users.
As such I think this is a not too typical Free Software project.
I agree. Nonetheless highly interesting to study the dynamics at the boundary
between Free/Open and proprietary/commercial projects.
Certainly.
The heterogeneity
of the involved interests, as well as the sheer size of the projects requires good
project management.
Certainly.
Thus, there is
* a steering comittee, which tries to coordinate all the involved interests
(http://gcc.gnu.org/steering.html)
Very interesting indeed. Some points I'd like to highlight.
All quotes from this page:
The steering committee was founded in 1998 with the intent of
preventing any particular individual, group or organization from
getting control over the project. Its primary purpose is to make
major decisions in the best interests of the GCC project and to
ensure that the project adheres to its fundamental principles found
in the project's mission statement.
This is a good example for a role which has been invented for a very
particular problem of this particular project. People perceived the
project as being in danger to be overtaken by interests alienated to
the project and so they created a role to prevent this and to ensure
that the goals of the project are adhered to.
Exactly.
Also very interesting is the part from the official announcement of
this steering committee dating November 1998:
From its initial conception, the egcs project [now GCC] has strived
to organize itself in a manner which prevents any particular
individual or company from having control over the project.
To that end, when the project was formed several individuals were
contacted to make decisions for the GCC project. These individuals
come from a variety of backgrounds and represent various groups with
an interest in the long term health of GCC.
We feel it is in the best interest of the GCC project at this time
to turn this informal group into an official steering committee, and
to make public its membership.
This is a perfect example of the self-appointment procedure I
mentioned above.
Yes.
And the official acknowledgment is also present:
In April 1999 the steering committee was appointed by the FSF as the
official GNU maintainer for GCC and changed its name to GCC steering
committee.
Half a year later this step was officially acknowledged by the FSF.
They acknowledged a practice already tested in practice.
* a release manager, who sets up a release schedule, and generally, a formal
development plan (http://gcc.gnu.org/develop.html)
* a list of 'maintainers' for the various modules, with various responsabilities
and rights.
Yes, there are a couple of more technical roles which turned out to
make sense during the course of the project.
Could you give us an idea how the release manager is selected?
I shall ask him. :-)
There are a number of commercial entities involved in the development of GCC
(such as Apple, CodeSourcery, Google, IBM, RedHat), but there are also a substantial
number of contributors who work on it in their spare time.
I think this is a rather unusual Free Software project indeed. AFAICS
Free Software projects tend to be either Doubly Free or Single Free.
I.e. there is either a non-commercial community with a contributor
from a certain corporation here and there (the vast majority of
projects) or there is a Free Software project by a corporation with
some Free contributors here and there (OpenOffice.org and Mozilla come
to mind).
FWIW, the reason I'm so keen on this topic is that I feel the role Free Software
plays in 'the industry' has changed considerably over the last couple of years.
Definitely. 15 years ago Free Software was what some server
administrator ran without telling anybody - besides his technical
colleagues may be. Today Free Software is used by the software
industry and sometimes the software industry even engages in this or
that project.
Let's not stick to an image that might have been true 15 years ago. In particular,
if we are interested in an understanding of how FS transforms our society at large.
Yep.
However, AFAICS if we are talking about cooperation in Free Software
projects the main change is that now corporations more or less
officially engage in Free Software projects - and inject their
alienated goals - for which you gave a very illustrating example.
6 days ago Stefan Seefeld wrote:
When you are talking about cooperation, using items such as 'informal',
'no fixed boundaries', etc., you seem to think of a very particular
(and in my opinion only minor) type of (small scale) OSS projects.
Most projects I'm working on are simply too big not to require
additional organizational structure.
Well, I said a lot about the 'informal' topic.
As far as the 'no fixed boundaries' is concerned I'd say that even in
huge projects for the vast majority of single contributors there are
no fixed boundaries. Years ago even myself submitted a bug report to
GCC (erm - that was even before EGCS forked ;-) ). So I'm certainly
not a member of the GCC project in any way making sense. Yet I
contributed something to the project. If you say that 'no fixed
boundaries' is wrong where would you see the boundary then?
For example: write permission to projects is often given only after there is
a certain amount of trust in you. Then, there may be restrictions about
what portions of the project you are 'allowed' to make changes to, or
who you should ask for patch reviews, etc., etc.
I agree that this is a clearly visible boundary. However, it seems not
very fixed to me - as you explain.
There is no black and white, and, as you say, those boundaries exist
to make the development of the project more efficient, not because of
whatever 'external' economical or social reasons.
Yes, in reality there is never black and white. Instead there is
always fog. The problem with fog is, that you can't see anything. The
purpose of a theory IMHO is to make interesting structures visible in
this fog of reality. And - especially if done in a short way like in
this example - to reduce to the interesting structures.
Mit Freien Grüßen
Stefan
--
Please note this message is written on an offline laptop
and send out in the evening of the day it is written. It
does not take any information into account which may have
reached my mailbox since yesterday evening.
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de