Search Results: "Ben Collins"

23 June 2013

Gregor Herrmann: RC bugs 2013/24-25

thanks to lucas & his trainees, we're seeing archive rebuilds & tons of new RC bugs again. besides that, there are still some patches in the BTS. here goes my list of recently worked on bugs; most of them in the pkg-perl group

24 May 2011

Russell Coker: Are Assholes Essential to a Free Software Project?

What do Assholes do? Rusty just wrote a post titled If you didn t run code written by assholes, your machine wouldn t boot [1] about some of the anti-social tendencies demonstrated by programmers, including some that are implied to be fairly important. His post seems to imply that there are really great programmers who are anti-social and that we should just put up with it because of their great code. One of the problems with his post is that he doesn t define asshole . Holocaust deniers and all other Nazi supporters seem to clearly by assholes by any definition. People who have silly ideas about medicine and tell others seem to be merely misguided (although my dictionary gives stupid or irritating or ridiculous in the definition of asshole so technically they can meet the criteria). In the comments Rusty states that nuttiness is relative . While that is correct it doesn t seem to have much bearing on whether someone is an asshole. For example I know some very nice people who are utterly convinced by creationism. Is Anyone Essential to Free Software? Most projects have one person or several people in leadership positions, usually there seems to be a combination of project management and lead-programmer positions. Such people are obviously quite important to a project. But we have seen examples of people dying, being employed by Microsoft, retiring, relicensing the source in a bad way, and just losing interest without the project ceasing. It seems clear that in most cases when a project which has a significant amount of use has significant bugs and no maintainer then someone will step in. The cases where no-one takes over the project are often resolved by someone creating a competing project. If no-one takes over an abandoned Free Software project then it s a strong indication that the project wasn t particularly important anyway. I have no doubt that if any bug or missing feature made Linux systems stop booting then someone would fix it quite quickly. In a more general sense it seems that every time someone takes a position in a project that is of wide interest they are displacing someone else who might have done the job. When you volunteer to do significant work for a project you may be displacing someone who is more skillful than you this isn t necessarily a bad thing as there are plenty of other projects to work on, some of which require more skill. Growing More Programmers It seems to me that a large part of becoming a great programmer is facing great challenges. People who could be described as optimistic or arrogant will tend to take on more challenging tasks and therefore learn more. I m sure that there are a lot of people out there who have the potential to be great programmers apart from not taking on the challenging work, this seems to be an unfortunate waste of talent. Given a large enough population if someone leaves a senior position there should be someone else who can obtain the skills needed to take over. One advantage of this for Free Software development is that even if the best person to take on the challenge isn t living in the most convenient continent that won t be an obstacle, while with proprietary software development projects the teams are small and it s common that no-one else is capable of stepping up to a lead position. Another advantage is that when the lead developer leaves there are generally many candidates to replace them, all of whom can start work and be judged on the work that they do. I think that the best claims that can be made regarding essential people are not in regard to technical skill alone but to a combination of technical and people skills. Getting a group of programmers to work together is really hard but it s something that needs to be done for any significant project. Also the larger projects tend not to stand alone, being able to get changes included in other projects requires some skill. Ben Collins-Sussman and Brian Fitzpatrick gave an insightful talk at Google IO 2008 titled How to Protect Your Open Source Project From Poisonous People [2]. The first half of their talk is mostly about people who are misguided or difficult rather than what most people would consider poisonous and the second half is more about people who are actively poisonous and need to be removed. They advocate a community based on Politeness, Respect, Trust, and Humility. They describe in detail how the methods they advocate result in the members of their community being more productive, it seems obvious that those principles will lead to better career growth for people within the community and more friendly people wanting to join. When is being an Asshole OK? I once worked for a company that apparently had a team consisting solely of assholes. Apparently one asshole got promoted to management and after some internal transfers they ended up with all the assholes in the company on one team. I guess that when someone has negative interactions with everyone they won t notice the difference if they are put in a team where everyone is difficult. For a corporate environment that lacks a no jerks hiring policy this is probably a good way of improving productivity overall. I am not aware of any significant Free Software project that was comprised of mostly jerks although I have seen a few with dysfunctional environments that encourage the worst behavior from their members. The smaller Free Software projects have less need for people who can relate to other people. There are many useful Free Software projects which have only one developer, in most cases anyone can take the source code and use it without dealing with the author. But even for a single-developer project an asshole can cause some serious problems. One example I know of concerns a developer who had unclear licenses and started making legal threats in response to a request for a clear license. Another example is of a developer who released code that was designed to not work when one particular user compiled it and redistributed the binaries. Both of them caused some significant amounts of time to be wasted by people who were unfortunate enough to develop systems that interacted with the code in question, and even more time was wasted when some misguided people defended them in the inevitable flame-wars. Even for a project with only one developer it s still better for everyone if that developer isn t an asshole. One comment I ve seen related to this issue suggesting that some types of asshole behavior shouldn t be a problem an example that was cited is a colleague who cheats on a romantic partner. Jeremy Clyman (who is currently doing a Ph.D in Psychology) has written an interesting article about this for Psychology Today [3]. He reviews the movie The Dilemma which deals with someone catching their colleague s wife cheating. Jeremy analyses the psychological issues involved and how they can (among other things) impact the ability for such people to work. I once worked in an office where two married employees were very open about having an affair and we were all apparently expected to lie on their behalf if necessary, it really affected the quality of the working environment. Extreme Assholes There are lots of people involved in Free Software development who are difficult and many who are to some extent assholes. But some of them take being an asshole to the extreme, such as Holocaust deniers (an example which Rusty used). In the comments on his post the Westboro Baptist Church is also mentioned. It is possible to entirely disagree with someone on a contentious issue such as abortion but still be able to get along with them. But when someone supports a hate-based organisation such as the WBC or supports Nazis in any way then there will be many people who just can t tolerate them and no-one should be expected to tolerate such people. I have seen two instances where Free Software developers advocated pro-Nazi positions (one had an archive of neo-Nazi propaganda and the other claimed that Nazis were not responsible for the Holocaust). Neither of the pro-Nazi programmers was evicted for defending Nazis, but both of them ended up leaving the community in adverse ways after causing other damage in the mean time. I don t think it takes any great ability to predict the future to determine that someone who defends Nazis will eventually end up doing something that requires expulsion and drive away users and developers in the mean-time. There is no possibility that someone can support the Nazi or WBC ideology only when not associated with your project, it will affect all aspects of their life. When a Holocaust denier is allowed to be a member of a community it also sends out a message that members of the groups which were persecuted by Nazis aren t particularly welcome in the community. Helping Minor Assholes There are a lot of people who don t have malevolent aims but who unintentionally cause some difficulty (it seems that the truly malicious are a tiny minority). I don t think that excusing the bad things that they do on the basis of writing good code helps them in the long term. Many of the suggestions that Ben Collins-Sussman and Brian Fitzpatrick make seem likely to help people who don t want to be assholes and direct them towards positive involvement in the community. One trend that seems apparent is the non-linear response to certain types of bad behavior. There is often little difference in severity between something that gets almost no attention and something that results in a large and extremely hostile reaction. If someone persists in acting like an asshole for long enough it seems to be inevitable that they will eventually exceed some threshold for what is tolerated and get a very significant negative response. It would be good if things didn t need to get to that stage. I think that the most unfortunate aspect of Rusty s blog post is that most people will probably interpret it as encouragement to write better code as a way of getting a free pass for being an asshole. I know that this isn t what Rusty intended, but most people on the Internet don t know Rusty as well as I do. Conclusion Ben Collins-Sussman and Brian Fitzpatrick seem to have some of the best ideas for how to deal with these issues when you control a project, but most of us aren t in that position. Everyone can advocate better behavior. Extreme assholes need to be removed quickly and without a great debate about their contributions, freedom of speech, or other issues. Since considering this issue I ve been wondering about when one should avoid the lesser assholes and asshole-positive environments. People tend to adapt to their environment, so if you associate with assholes a lot then there s a good chance you will start to become like them. Is

13 March 2011

Lars Wirzenius: DPL elections: candidate counts

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.
Year Count Names
1999 4 Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000 4 Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001 4 Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002 3 Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003 4 Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004 3 Martin Michlmayr, Gergely Nagy, Branden Robinson
2005 6 Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006 7 Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007 8 Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008 3 Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009 2 Stefano Zacchiroli, Steve McIntyre
2010 4 Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011 1 Stefano Zacchiroli (no vote yet)
Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

6 March 2008

Anthony Towns: The second half...

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:
Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey
I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…
Geez, this was meant to be briefer...

14 March 2007

Felipe Augusto van de Wiel: 14 Mar 2007

random(ideas);

Yes... we can too!
Recently I saw somewhere a link to Google Video about a very nice video: How Open Source Projects Survive Poisonous People (And You Can Too). So please, if you didn't see this go and watch it now: http://video.google.com/videoplay?docid=-4216011961522818645. It is a little bit large (~50 min) but I found some nice information from real experiences that could really help to improve our communication inside Debian. So, for the curious and impatient, it is a Google TechTalk with Ben Collins-Sussman & Brian W. Fitzpatrick, SubVersion Developers, based on their experiences they show situations that can drain Project resources and they gave valuable tips, ideas and directions on how to protect the "Attention and Focus" of the Project. It is very interesting to find a lot of factors and points that we can see from time to time on Debian. Don't get me wrong, I'm really not whining, I don't think that whining would solve any problem (except if you are a 6-month hungry child), but I would love if it could give us some momentum and maybe a starting point to leave aside some old unresolved issues, giving a chance to new ideas! Which basically means, keep working together to keep building the best Operating System. :-) (But doing that with even more fun for even more people). We can too! On a totally unrelated note: my primary MX is back for quite some time, I should report that earlier, anyway, sorry about the lack of posts, thanks for your attention and see you soon. Over.

27 October 2006

Sven Mueller: Debian and Dunc-Tank

Well, this really is a controversal topic to say the least. While having the RMs get paid to get Etch out might be a good thing, the big problem I see with dunctank is that it is initiated by people very prominent inside Debian and moreover by people perceived as friends of th RMs in question. Though dunctank says that is distinct from Debian, due to the high profile the people involved have inside the Debian community, this distinction might not be recognized by less careful observers. The second problem is that the payment the RMs get is not connected to well specified tasks, but they are for “working on the release of Debian “Etch”. And finally, there is the problem that this is said to be an experiment. However, a good experiment has well defined objectives and well defined boundary conditions. In other words: Regarding Dunc-Tank, it is unclear to me what the experiment is trying to achieve. I admit I voted as much in favor of the experiment as the GR allowed, but in the meantime, I regret doing so. My vote was because my impression was that Dunc-Tank would pay just enough to pay rent, food and the other usual expenses (insurances, debts etc.). But now each of the two RMs is supposed to receive 6k$. This surely is less than they could earn working as IT freelancers, but it sure exceeds their pure living expenses. While just covering their living expenses would be OK for me (in the sense that I could live with it, not in the sense of being happy about it), paying substantially more isn’t, but that’s just me. A DPL collecting money to pay certain DDs is always going to ask for trouble. Or as Ben collins put it back in 2001:
… use Debian money to pay developers. It can never be done fairly, or in a way so as not to piss someone off. It will always be susceptible to political gains and/or favoritism. This subject caused a lot of hatred, and in my opinion, the experiment is a failure. Though it might help to get Etch out in time, it caused many DDs to cut down on the time they spend on Debian, among them people like the DWN editor, who used to invest a lot of time. And this effect will not go away when Etch is released and is thus hurting Debian in the long run. The whole thing might have been a lot different if some random, mostly unknown DD (or even better: non-DD) had started dunc-tank, collecting money and finally paying some DDs to work on some specific tasks. But the fact that the DPL started it makes it so controversial. But on the other hand, it would have been less likely that dunc-tank collected enough money to do so in that case. Honestly, if I were to decide, I would drop dunc-tank completely once Etch has been released (it’s too late to do it now, it would just deprive Debian of the benefits and still cause all the negative side effects). The people who thought (and think) dunc-tank was a good idea could then restart it later under some different name and without involvement of the DPL. There is only one position in Debian I could see reasons why the person occupying it should receive some sort of compensation: The DPL. The reason I see here is that this position requires a lot of time if taken seriously. This also means that many people can’t reasonably apply for it since they would need to resign from their “real world” job.

2 January 2006

Manoj Srivastava: In vain, the sage, with retrospective eye &#8211;Pope

It has been a tumultuous decade of involvement with Debian for me. I had been on the mailing list since mid 1994, but I was reasonably happy with my SLS system (installed using 40 floppies, including about a dozen for just X11 alone), and while I found Debian intriguing, I was not about to go through the pain of a brand new install until I felt that the new project was viable in the long term :-) I actually jumped ship in the spring of ‘95 and installed 0.93R5. The next step came with Bug 1766, my very first bug report: Bug in script checksecurity in package cron, on 25 Oct 1995. Once in, I rapidly went to the next phase: Here is the sum toto of the NM process I went through: my Hello, World mail. Those were the days :-). There was nothing between my ITP and the upload. My first significant package was kernel-package, since I was always missing something in the series of steps needed to build a kernel, and I started getting into it in the summer of ‘96. This is where the second part of my apprenticeship started – even though I had 3-4 packages in the archive, my kernel images were not yet trusted; so I sent my images to my sponsor (Hi Simon), who then uploaded the images to master. Somewhat later, I also was involved in the early design stages of apt, and the dependency sorting algorithms. While I was fairly silent during the whole DFSG/SC debates (to the extent I was labelled a mindless follower of Bruce –heh), I took an active part in the constitution debates (possibly due to the fallout of the beach story. Anyway, I seemed to want to get us a constitution, after it had seemed stalled for months. It is interesting to note how the technical committee was initially setup, there was a proposal, and then Ian Jackson responded by saying he wanted to appoint the ctte members, since he had been around for a while and was also the DPL. The earliest data I can find is from June of ‘98, as seen in a mail later that year, when the initial list of committee members was created (I also seem to recall I was not on the list initially, but I was added in the early days, before the committee was actually formed). I was interested in the technical policy fairly early, taking a stance that policy was more than just a bunch of ignorable guidelines. Eventually, a [thread that tried to reach a compromise][other] gave us something like the views we (well, I) hold today – including what happens when packages do not follow policy, and about policy editors. And abuse of power. About this time, the policy Czar resigned, burned out, and hounded by accusations of delusion of power. So I first proposed the whole policy editor and consensus approach to letting policy evolve, which eventually led to a formal delegation recently. Brian Basset was our very first secretary. My first involvement with things that would lead on to the secretaries job started with trying to do voting for policy. Then, around 2000, our the secretary and treasurer Darren Benham went MIA, and Raul, as the chair of the technical committee, had to take over and run the DPL election for 2001 – and forgot that DPL elections are supposed to be secret ballots. Ben Collins tapped me for the secretaries position mid-2001, as I recall. It is hard, in a decade or so, to find anything I have not touched – but NM is one such area. Apart from an early pre-current-NM mail, I have not been very involved in NM. Or the Debian installer. Or Debconf. Hmm. I seem to have drifted away from things that Joey Hess is involved in, which is a pity, he is high on the list of people I respect in the project, and this lack of interaction with as time goes on irks me.