On Fri, Mar 02, 2007 at 06:57:01PM +0100, Pierre Habouzit wrote:
> You forgot a single damn point: in debian, like in many projects, the
> one that "do" things is often the guy that "decide" things because he's
> the one there. If you put people that work 5 times more as me because
> they have the time to do that, I will obviously feel they took my
> place. I'm not sure what I would do in those cases. Obviously not
> refusing the help and people that have the time to do this, but I would
> obviously lessen my implication and work for other teams where I've a
> single damn chance to see my contribution to be compareable to the
> others.
The principle you stated obviously tends to be the case in volunteer
organizations, true. It does not have to be the case of a paid
employee, but yes, even if the maintainer team sets the general policy
and gives direction to the employee, there will be a lot of
hour-to-hour operational control which you will be ceding to the
employee (unless you want to be one of those awful micro-managing
managers --- but that's not a path to productivity, either for the
manager or the managee! :-)
> I would feel bad to impose my views to a person that has huges amounts
> of time to work in the team. And necessarily (because of human nature)
> a decision will happen that I would not like or would have made
> differently, and at that point I guess that I would just leave.
Well, anytime we have people working on a package with team
maintenance, there are bound to be disagreements. If we all left the
moment a decision was made that we didn't agree with, Debian would be
empty.
I can't read your mind, of course, but it may be that the harder
psychological hurdle is the one where a DD realizes that (say) 10
hours a week of volunteer labor is no longer enough to be one of the
primary contributors on a package team. That is a real issue, and
perhaps maybe _the_ major issue.
> Whereas in balanced teams where every contributor has the same level
> of contribution, I would have argued my point, or tried to make the
> proposal better, or discussed it or... whichever adequate behaviour in a
> team where every single member is equal to the other.
Although this may be a great platonic ideal, the reality is that no
team is going to be completely balanced. First of all, not everyone
does _can_ contribute at the same level. Some people have jobs that
cause them to work very long hours, for example. (And of these, some
of them would like to be able to help Debian, and one of the ways they
might be willing and able do so is via contributing money, not time.)
Secondly, even if assume that everyone could give the same number of
hours of contribution, the reality is that different people have
different levels of talent --- and it is still the case in the
programming world that differences in talent can account for 2+ orders
of magnitude in productivity. So in the end, talent will probably
still dominate far more than whether someone can work 10 hours as a
volunteer versus 40 hours as a paid employee. (This I think is one of
the ways that an examples of paid versus volunteer firemen may not be
applicable for Debian.)
> Money introduces bias. OK you were talking about bug triaging, and bug
> triaging is not necessarily a big decision making place, I agree. Though
> it will depend a lot of the kind of people you want to recruit:
> * if those are already contributors they will want to take more and
> more decisions, and won't only do bug triaging: if you do bug
> triaging you begin to know packages a lot, and become skilled
> enough to take decisions, and so on. Then commits rights are
> granted, and you take more and more responsibilities. That's good,
> it's indeed what is often suggested to newcomers. Though we end up
> in the not-so-nice situation I described.
Money introduces bias; no question. But it also does introduce a
certain amount of control. For example, suppose we only paid people
to do bug triaging. If they want to do more, that's great but it will
be on their own time. Would something like this magically make all of
the problems go away? Of course not, but I think it shows that with
the right amount of thoughtfulness, it's possible to make the benefits
outweight the costs.
> but please, I'm not sure there is a damn single maintainer in a big
> team that will refuse help, paid or not. I don't really understand how
> that mythical maintainer in a big team that refuses help has emerged in
> the discussions, but I'd really like names here. In fact, that seems
> pretty contradictory with the very notion of a team. Of course, there is
> teams with 1 single member in it in debian, but that's not a "large
> team" and is out of the scope if I'm not mistaken.
Well, Josselin has been very negative about the whole concept of
paying volunteers, and given that he was asking for help, and saying
that his GNOME team was drowning under bug reports, I couldn't help
but reply that if he really was serious about wanting help, would it
extend to accepting paid help ---- since many people have asserted
that they would leave the project if some of the contributors to
debian were paid, in effect trying to hold the project hostage against
paying developers. Part of the reason why I suspect they are doing
this is specifically because of some of the fears which you outlined
above, and which I acknowledge are real ones and ones which are
legitimate.
Speaking personally, although I was the first North American kernel
developer, I lost a lot of influence when the Linux kernel moved from
being purely developed by volunteers, to when people like Alan Cox got
gired by Red Hat to work full time on making the linux kernel better.
But that was also partially a choice on my part; I chose not to try to
make Linux kernel development a full-time carreer back in 1995-1996.
So I do know what it's like to have that happen; but I think I can
also assert that the Linux kernel got a heck of a lot better because
many third party organizations, some of them corporate, decided to
fund Linux kernel developers to work full-time on it, even if it did
cause people like me to lose a lot of stature and "power". But it was
still a good thing for the project, and so I don't regret what
happened to me. And a few years later, I did start working for Linux
companies full time --- first VA Linux Systems, and now at IBM. But
I'm no longer considered one of Linus's chief "lieutenants", and I'm
at peace with both my choices and what Linux-the-kernel has been able
to achieve precisely because it have a lot of people working on it
full-time.
So I understand where people are coming from when they say that they
want Debian to remain 100% fully volunteer. But first of all, that
isn't even true even now; HP is funding some DD's to work mostly on
Debian-related projects, and certainly some DD's are being paid by
Cannonical, for example. But secondly and more importantly, there
people withour community that have aspirations to be better than what
we can currently offer to our users now, and this includes responding
to bug reports in a timely fashion, and for some people at least,
getting releases out on time and with stable not being quite so
embarassingly out-of-date for quite as long before we can get the next
release of stable out.
It seems to me that we can either give up on some of these aspirations
(and some have suggested maybe the right solution is to give up the
goal of Debian on the desktop, and only focus on Debian on servers,
and some have suggested maybe users shouldn't expect to get timely
responses from a human for bug reports). The other choice is for us
to try to be better, but you can't do this by just punishing
volunteers by not letting their packages enter testing. You can't
force volunteers to do anything, and not letting their packages enter
testing and forcing them to work on bug triaging could just as easily
cause them to give up in disgust. But while it is true that you can't
force volunteers to do anything, one option is that you can always
hire employees or contractors to work on specific specified tasks.
And this is something which I believe we need to consider very
carefully.
Regards,
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
