Message 03646 [Homepage] [Navigation]
Thread: oxenT03527 Message: 61/96 L5 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Re: [ox-en] Re: Cooperation in Free Projects

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.

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?

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
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?

When I said 'informal' I tried to outline what I mean. May be we can
go through this and see where it is flawed.

   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.

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.

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?

   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.

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?

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.

   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.

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.

To give a concrete example:

Thanks for this.

The GNU Compiler Collection ( is a huge project, with many
participating commercial entities, and a lot of commercial

As such I think this is a not too typical Free Software project.

The heterogeneity
of the involved interests, as well as the sheer size of the projects requires good
project management.


Thus, there is

* a steering comittee, which tries to coordinate all the involved interests

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.

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.

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

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 (
* 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?

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 ( and Mozilla come
to mind).

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?

						Mit Freien Grüßen


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.

Contact: projekt

Thread: oxenT03527 Message: 61/96 L5 [In index]
Message 03646 [Homepage] [Navigation]