Hi Marc, Michael,
Calm it down a bit.
Marc A. Lehmann wrote:
> On Tue, Sep 16, 2003 at 10:33:39AM -0500, "Michael J. Hammel" <[EMAIL PROTECTED]>
> Obviously I did my homework better than you for example. No, I don't hate
> boards. I hate people who argue unfarily (like you, this is not the first
> ad hominem argument). Can't you just keep to non-personal arguments?
I think that you're probably more guilty of going ad hominem in
here Marc. That said, both of ye are going to wake the children.
> > No one is going to get the "rights" to the code if its under the GPL.
> It's called "copyright", and the GPL is based on it. Please do a little
> research on that topic and you'll see that you are wrong.
It was made clear at camp that many coders weren't prepared to
hand over copyright, no-one can force them to, I wouldn't ask
them to. And having a steering committee or a board or whatever
you want to call it wouldn't change that.
> > This sounds like FUD.
> Yes, because you don't understand the GPL and how it works, it seems.
> Also, it's not me who is constantly spreading FUD here, but you :(
Actually, it did sound like fud. The implication was "Board =>
you sign over copyright on your code". This is not the case.
You now seem to be saying "Board + GPL => you sign over your
copyright", and that's incorrect too. Perhaps I'm
misunderstanding you though.
> Well, you are mixing up "board", "foundation", "central authority" all the
> time. It's difficult to argue with somebody who constantly changes his
> propositions. "central authority" is quite a different concept as "board"
> is, for example.
Actually, Michale seems to be implying that a board/steering
committee would be a central authority and a face on the project.
I think this is correct. You are saying that this type of central
authority might not be desirable. I think you're probably right
too, certainly with respect to several of the current developers.
For me, foundation and board are the same thing - the foundation
is the organisation, the board are its elected representatives.
That board can have as much or as little responsibility as its
members decide. It can also evolve to fill needs as they arise.
That is why we decided to create the gimp foundation and elect a
board (as a public face to the gimp), while at the same time
having rules sufficiently wide that the board could eventually,
if it were felt reasonable, be a steering committee for the
project, or ake release schedules, etc. But that was not the
intention when creating the foundation, and any such change would
probably need to be debated at a conference. I'll bring the
> > By lighting the fire of interest in the non-technical community that
> > often sparks motivation and interest in the project itself.
> Well, at least in the case of the gimp, interest is extremely high in the
> non-technical community, in case you missed that. And again: how does
> that help the developers?
As you said earlier, Marc, XFree is losing developers, and new
ones aren't coming in. I think that a few of the ideas we had at
camp which are now being put in place will help with that, but we
also need more people involved in the project. More non-technical
people means more time for the technical people to do other
stuff. It also means more future technical people, as the
non-techs start working and get a bit braver :)
> Well, that works fine. Remember the big discussion about the 2.0 version
> number exactly because directions and plans on development _have_ been
> known outside the dveeloper community?
Actually, most of that discussion stayed inside the developer
community. The fact that there was a fight was bigger news than
the version change itself.
> This is exactly what is wrong about the idea. A foundation (like the
> one that is planned), as a mere instrument to collect money, maybe do
> publicity or similar tasks, is quite fine.
> It's when people want to take the power away from the developers where I
> say no.
A steering committee (which is what we all seem to be talking
about, albeit with different names) is usually developer driven.
It would not make sense to have it any other way, as you rightly
If we look at gnome, there are several committees - the
foundation board, the release team, the web team, the i18n
project, the bugsquad, all of whom have their own domain of
knowledge and competency The foundation board benefits developers
by keeping all the organisational crap out of their way, the
release team by creating and sticking to a release schedule, and
forcing all the sub-projects to do the same, and so on.
In each of these teams, people come and go, but the team goes on.
That's the benefit of a team. Perhaps if the GIMP oriented itself a
little more towards this idea of sub-teams with responsibility,
we would not have so much reliance on one or two core
individuals. And perhaps that would benefit the developers.
E-Mail: [EMAIL PROTECTED]
Gimp-user mailing list