Re: [ox-en] Re: Cooperation in Free Projects
- From: Stefan Seefeld <seefeld sympatico.ca>
- Date: Wed, 29 Nov 2006 16:18:15 -0500
Stefan Merten wrote:
Hi StefanS and all!
Let me continue this in another sub-thread.
3 weeks (22 days) ago Stefan Seefeld wrote:
Stefan Merten wrote:
Well, sorry for the form. I'd be happy if there would be a more
complete text as well but I for one do not have the time for this
right now.
I don't think this is something that one can improve with more time.
Well, if I had more time I'd use the bullet points as headers under
which there is some text explaining the respective header more
thoroughly than in such an abridged form. Of course such an effort
could be done by everyone.
Yes, but it would still be a simple statement, no matter how thoroughly
explained. :-)
You seem to try to put something rather complex into simple terms,
and that leads to wrong statements.
With more text there would also be room for being more precise about
the borders. Don't you think this makes sense?
Yes, you could say "this simple statement applies under this and that
condition". But you wouldn't be talking about Free Software in general
any more. (And I thought our interest here was in the latter, not a
specific form of it.
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.)
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' ?
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 ?
If many people contribute to a project, this may be counted as a form
of 'vote', too.
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.
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.
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.
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.
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.
Best regards,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de