Re: git as an sfc member project

On Fri, Oct 22, 2010 at 11:30 AM, Jeff King [off-list ref] wrote:

There is one slight caveat, which is that JGit was not accepted, due to
the complexity of their ties with the Eclipse Foundation.

Yup.  Anytime you say "Eclipse Foundation", make sure you put
"complexity" into the same sentence.  Its required to make the
sentence accurate.  :-)

In practice, I
don't think this will matter much at all. The only way that Git operates
in any legal capacity as a group is when we do Summer of Code. This
could impact us, e.g., if were to have a JGit-specific SoC project.

We had a GSoC project, but through the Eclipse Foundation
participation in GSoC, not Git.  So the Eclipse Foundation received
our mentor stipend for us, and will spend it in some way that is
unknown to me.  Yay?

The decision to do JGit GSoC through Eclipse and not through Git this
year wasn't really mine.  I just didn't disagree loud enough to change
things.

Probably the money that goes to the organization for such a project
should _not_ go through the SFC, and would have to be handled
separately. Which is no worse than JGit has it today; they just can't
receive the SFC services as regular git can.

This is fine with the JGit folks, for now anyway.  We may revisit this
and have JGit join SFC at some point in the future.  We might not.

Basically what we need to decide on before signing is:

 1. Who should sign? These people are basically speaking for git as a
    community. Related to (2) below.

The people listed in 2 as the leadership structure of git.

 2. What is the leadership structure of git as a legal entity? In other
    words, if we get some money that goes to the SFC (from SoC or from
    donations), who should have authority to tell the SFC to do
    something with it?

    The obvious choices (to me) are:

      a. Junio as benevolent dictator^W maintainer.

      b. Somebody else as benevolent SFC liaison.

      c. Some committee of core people (I'd say no more than 3-5) who
         would all need to agree (or perhaps some majority).

...

    Personally, I favor a small group which can approve new people to
    join, and which can leave at will. Having more than one person
    avoids hit-by-bus problems (or even just dropped-off-net problems).
    There is little enough power in such a position that I'm not too
    worried about some crazed egomaniac becoming the Git-SFC liaison.

I agree.

I think a committee of at least 3 people and at most 5, any of whom
can be a benevolent SFC liasion, is fine.  As far as selection goes,
the committee can elect or remove a member through a majority vote,
and should base its decisions based on surviving contributions to the
code base, but shouldn't be tied to that (just in case someone
contributes a lot of good code and then becomes a jerk).

But as you point out, there isn't much power involved here, so there
isn't a lot of concern of it being abused.  The important thing (the
copyright on the code) is still held by individual contributors, so
there is very little value involved (just the handful of GSoC dollars
each year).

 3. How much money should we give to the SFC?

    A big chunk of their budget comes from taking a percentage of
    member project money. As a project, we set the percentage we give
    them. So we can give them nothing if we want. But they do provide
    useful services, and even without direct benefit to git, the SFC is
    promoting free software. So probably it makes sense to choose some
    non-zero number.

I agree, a non-zero number.  2-5%?  Any idea what is typical?

-- 
Shawn.