Re: Call for discussion: adding member projects?

Lately we've had two requests from projects - OpenC++ and the GNUStep
project - who are interested in joining SPI as member projects.

Traditionally, the board has alone approved or disapproved projects,
though in 1999 a committee was formed to handle member projects:
http://www.spi-inc.org/corporate/resolutions/resolution-1999-09-21.iwj

The now apparently defunct (did it ever actually exist?) Project Committee
did not handle researching or approving member projects, but I'd like to
propose that we recreate a Project Committee whose job it is to handle
applications for member projects as well as day-to-day affairs for these
projects, if applicable.

That said, a more important problem is setting out guidelines for what
projects are and are not eligible to become member projects on SPI.

As I see it, any free software or open source project that needs some form
of capabilities not available to non-incorporated projects is eligible to
join, but accepting every project out there would make us quite large,
quite fast.

What guidelines or even strict rules should we use in the acceptance or
rejection of member project requests?

---
David Graham, SPI Secretary
cdlu(at)spi-inc(dot)org D5F45889

Hi,

> What guidelines or even strict rules should we use in the acceptance or
> rejection of member project requests?

Just brainstorming:
* Projects should not be opposite competitors to current member
projects (e.g.: a redhat based distro - no, a debian basted distro that
cooperates with debian - yes)
* Project should have a focus that is more than just one package or
project (debian, gnome, gnustep, something-like-sourceforge - yes.
screen, wget, gnupg - no)
* Project having a certain significance in the Free Software world

Just thought that come to my mind, no opinion implicated (yet).

nomeata
--
Joachim Breitner
e-Mail: mail(at)joachim-breitner(dot)de
Homepage: http://www.joachim-breitner.de
ICQ#: 74513189
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html

Previously Joachim Breitner wrote:
> Just brainstorming:
> * Projects should not be opposite competitors to current member
> projects (e.g.: a redhat based distro - no, a debian basted distro that
> cooperates with debian - yes)

Why not? A bit of competition can't hurt.

> * Project should have a focus that is more than just one package or
> project (debian, gnome, gnustep, something-like-sourceforge - yes.
> screen, wget, gnupg - no)

Again, I disagree. The current member projects don' even fit that
profile.

Wichert.

--
Wichert Akkerman <wichert(at)wiggy(dot)net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

Hello,

please note that my ideas were meant to be contradicted :-)

Am Montag, den 01.11.2004, 09:56 +0100 schrieb Wichert Akkerman:
> Previously Joachim Breitner wrote:
> > Just brainstorming:
> > * Projects should not be opposite competitors to current member
> > projects (e.g.: a redhat based distro - no, a debian basted distro that
> > cooperates with debian - yes)
> Why not? A bit of competition can't hurt.
That is true.
I was about to propose that we could try to urge competing member
projects to cooperate (think freedesktop.org wrt Gnome and KDE). But
then I thought the projects should be independent and sovereign in what
the do. This leads to the questions: Should we consider criteria for
adding members that we don't plan on holding up for added members? Or
should we restrict ourselves to criteria that members should continue to
fulfill?

> > * Project should have a focus that is more than just one package or
> > project (debian, gnome, gnustep, something-like-sourceforge - yes.
> > screen, wget, gnupg - no)
> Again, I disagree. The current member projects don' even fit that
> profile.
I agree with your disagreement. But what other criteria should be
considered?

Only one I can think of is how much the project actually needs us, that
is, do they really expect donations, do they have finances to handle, is
there legal issues the project can't handle? While I think I like this
criteria, it can only be a guideline and we need a committee or
something that will have decide on a case to case basis.

Greetings,
nomeata
--
Joachim "nomeata" Breitner
Debian Developer
nomeata(at)debian(dot)org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: joachimbreitner(at)amessage(dot)de | http://people.debian.org/~nomeata