Search Results: "will"

4 September 2006

Benjamin Mako Hill: Upcoming Talk at CEOS

In a few weeks, I'm going to be giving the keynote address at the the Conference on Engaging in Open Source at Dalhousie University in Halifax, Nova Scotia. The conference is organized by the student chapter of the ACM at Dalhousie and looks like a unique, and very interesting, gathering. My talk will build on some of my previous critical analyses of the unique process of principle-setting in the free and open source software communities and will try to introduce some new and challenging concepts while framing the broader discussion that will continue in the rest of the conference. The conference will be held on June 1 & 2, 2006. Ping me if you're in the area and would like to meet up.

Benjamin Mako Hill: Defective By Design

I was very happy to see that the anti-DRM protest that I suggested people go to seemed like it was a success!
/copyrighteous/images/drm_protest_seattle.jpg
It would have been nicer if even more people had gone out for it but I guess that's just one of the problems with organizing such a thing on short notice. Given the time from announcement to protest, I think it went pretty well. It seems like there were definitely enough people to make it work. Of course the Defective By Design folks let you sign up now so you won't miss the next one if its in your town. If DRM is going to be successfully opposed this decade, it will be through education and activism in the next months and year. I think that it is very important that people get involved.

Benjamin Mako Hill: More Defective By Design!

As part of the Defective By Design anti-DRM campaign which I've been rabble-rousing for recently, there are going to be a series of protests at Apple Stores across the United States Saturday, June 10th. Events will be in New York, Boston, Chicago, San Francisco, Seattle, and Plano. There will be costumes and cameras and plenty of people attempting to warn Apple customers about the dangers of DRM in iTunes and Apple hardware and software. If you are going to come to any of the events, you can find more information on the Defective By Design website and you can RSVP by mailing appleflash@defectivebydesign.org. If you are coming to Boston, there's a tentatively planned after party at the Acetarium. If you have an iPod or other DAP with DRM, we can attempt to liberate your iPod with RockBox there. If you live in or near any of these places, you should come. If we don't win some serious mindshare in the next year and before the next holiday season, it will become much more difficult. As consumers of technology, we have a lot to lose to inaction right now.

Benjamin Mako Hill: Stepping Down From Software in the Public Interest, Inc.

Three years ago, I was elected to the board of directors of Software in the Public Interest, Inc. About halfway through my three year term, I was elected by the board to the (largely ceremonial?) role of Vice President of the organization. This month, my term is up and after a good deal of soul searching over the last weeks, I've decided to not run again. With time, I've become busy with other projects including work and graduate school at the MIT Media Lab, Debian, Ubuntu, One Laptop per Child, several book projects and more. Recently, I've found that I've simply had less time to put toward SPI than I have had in the past. Of course, I continue to care very much about SPI and its mission and feel that I done a good job of fulfilling my responsibilities throughout my term. The real reason I'd like to step aside to let some new blood and energy take a more active role and to let SPI take off in new directions. Since I've served a full term, I thought I would take the opportunity to look back at my work with SPI over the last three years and to the future. SPI's Recent Past Three years ago, I ran for the SPI board on a platform that I would like to see SPI work more like a real pro-active non-profit organization and less like Debian's legal shell. SPI was at at transition point then and the board spent a lot of time thinking about it was that SPI should do and what role it should fill in the free software community. Many of these questions are still open but the following is my round up. There are two types of non-profit organizations in the free/open source community. The first is the large-project foundation. Example are the GNOME Foundation, KDE Foundation, and Plone Foundation. These support and work closely with one large and otherwise institutionally independent project. The second type is concerned with advocacy or issues of concern to many or all free software projects. The FSG/LSB, Open Source Initiative, Software Freedom International, Linux International, and the Free Software Foundation are all examples of this type (although the FSF also supports the GNU Project so can be put into both camps). Three years ago, SPI was basically the Debian Foundation under a different name. However, SPI also supported a handful of other medium-sized projects (at the time, this included Berlin and OFTC). In this way, SPI provided some of the benefits of a 501(c)(3) non-profit organization to groups that were large and important enough to care about issues like the tax-deductability of donations, but small enough that starting their own foundation didn't quite make sense. This, I am convinced, is SPI's niche and its where the organization can make the greatest difference. While Debian continues to be the driving force behind SPI, this mirrors Debian close relationship with other free software projects as a downstream and a distribution. Debian may ultimately decide its has outgrown SPI and wants its own foundation but it's role in providing an umbrella for other free software project also makes a lot of sense. Over the last years, SPI has added several new member projects including GNUStep, Drupal and PostgreSQL and members of these projects have played an increasingly important role in SPI. OFTC members including SPI secretary David Graham have continued to drive the organization. I am thrilled to see that PostgreSQL's Josh Berkus is running for a seat on the board and wish him the best of luck. He has put a huge amount of effort into SPI in the past several months and I believe he would make a great board member. Of course, not everything has been rosy. While our organization is in slightly better shape than it has been in the past, SPI still suffers from a lack of interest and activity by participants in its member projects. SPI handles Debian's money and every Debian developer should be interested and involved in SPI; yet only a relatively small percentage are. I've run SPI sessions, talks, and BOFs at three of the last four Debian conferences but haven't been able to make a satisfactory dent in either the Debian community or SPI. The next board of directors will need to work actively and creatively to help do what the last board did not accomplish. While things are currently much better than they have been in the past, SPI has continued to be mired in a number of bureaucratic issues. Simple issues like accurate, timely and transparent bookkeeping have proved more difficult than the board or those brave (or foolhardy) enough to take on the treasurer position seem to have thought. I worked with the treasurer and our lawyer to meet with a bookkeeping service in New York City. The Future In the future, I'd like see to more members projects and more active participants from all members projects. I'd like to see a more active organization in general but am beginning to conclude that a fully volunteer "staff" is only going to be able to do so much. In terms of bureaucratic issues, several board members have lobbied hard to spend money to hire full or part time help either in an administrative capacity or as some sort of combination administrator/executive director. For a number of reasons, the board has been reticent to do this but I think it's become increasingly clear that our growth and relevance as an organization is going to require this. I think hiring the bookkeeping service was a good first step. I think at the very least, SPI should "outsource" most of the non-fun administrative work to others so that the board can focus on the important work of advocating free software and helping our member projects. I'm famously concerned with introducing paid labor into voluntary free software projects but I think that, if done right, this could be a very good step. In terms of my own involvement, I'm planning to stay involved as a contributing member or perhaps even as an adviser if the board will have me. I'd like to continue work on the SPI-Trademark committee and look forward to the day that we can create a general policy for helping folks use and license the Debian mark (and other trademark SPI may hold in the future) as permissively as possible. I'd also like to see a better documented process for becoming an SPI member project. This should explain to projects what SPI expects from them (e.g., democratic decision making, an active representative to SPI, etc), what they will get from SPI, and what is necessary to make it all happen. I'd like to work with some of the recent member projects to help document their experience and make easier for the next batch. I'm looking forward to taking some time off and look forward to the possibility of running for a seat on the SPI board again at some point in the future.

Benjamin Mako Hill: The Official Ubuntu Book

Any Day Now, The Official Ubuntu Book will show up in stores. I have a rubber-banded-together copy of the folded and gathered sheets and the the first batch of books should be bound (or being bound) right now. Those who have pre-ordered it from Amazon or elsewhere should have it in their hands quickly. In addition to my own name on the author page is (future Ubuntu Community Manager) Jono Bacon, Corey Burger, Jonathan Jesse, and Ivan Krsti . Many more members of the Ubuntu community and many editors at Prentice Hall deserve credit as well. I'm proud of the book. I sense that it's more consistent, better organized, and of a higher overall quality than my last book. Even better though, is the fact that the book is released under a Creative Commons Attribution-ShareAlike license. Several chapters are already being shipped by default on the Ubuntu desktop and several translations are underway. You can read more about the book on the publishers site and order it from any number of places online. Books under such licenses are economically risky for publishers so please support the project by buying it if you end up finding the text useful!

Benjamin Mako Hill: Vegetable Museums

In my mailbox today (links are added):
Dear Boston Vegetarian Society List, The curator of the World Carrot Museum will be joining us at Happy Buddha on a visit from the UK!
I've never met anyone who has created a museum about a vegetable but I'm intrigued. I'm also pleased to see that similar ventures exist for vegetables that I enjoy even more than carrots.

Benjamin Mako Hill: New Creative Commons Licenses

In the last couple years, I've earned something of a reputation for giving Creative Commons a hard time. This fact hit home a few weeks ago when a reporter for the San Antonio Current called me up to get "the other side" on a story he was doing on CC. Apparently, the journalist had found my name in the criticism section of Wikipedia's Creative Commons article. Now, while I'm not happy with CC's reticence to take a normative stance of any kind and I'm not thrilled with many CC licenses that don't respect what I believe are essential freedoms, I should give credit to CC where credit is due. Over the past half year or so, I've had the pleasure of helping represent Debian in conversations between a Debian team and folks at CC to help iron out a number of nits with the CC licenses that seemed to be (unnecessarily) creating barriers to Debian blessing some more permissive licenses as DFSG free. Throughout this process, folks at CC have been helpful, responsive, flexible, and seriously willing to make changes based on our suggestions. The first and hardest stage of this work culminated with CC's release of the discussion draft of their 3.0 licenses. Evan Prodromou published a great in-depth report on the talks between Debian and CC that helped shape these drafts. While we didn't get 100% of what we were asking, I'm personally quite confident that we have or will get all of what is necessary to ensure that the licenses are DFSG free both in letter and spirit. Not only does CC build several great licenses, they are willing to work with the community in difficult meaningful ways. When we build a real social movement around calls for essential freedom of culture and content, we'll be lucky to have CC writing some of the licenses that help make it happen.

Benjamin Mako Hill: Defining Free Content and Expression

(This is mostly reposted from an Advogato article I just submitted).
About a year ago, I posted an article on Advogato entitled, Towards a Standard of Freedom: Creative Commons and the Free Software Movement. In it, I argued that Creative Commons and the free culture movement were struggling to build a cohesive freedom movement in the way that free and open source software had succeeded in doing by never stopping to define the ground rules of the commons movement. I argued that Free Software built a movement around calls for essential freedoms and against the actions of software producers who failed to live up to this standard. On the other hand, Creative Commons has argued for "some rights reserved" but never explained which rights were unreservable. In the process, they've done the invaluable service of creating a stable of powerful, internationalized licenses. But they failed to build the type social movement that some of us wanted. While this was never their goal, it left some people unsatisfied. In a later version of the essay published in Mute Magazine, I concluded by stating:
Whether in unison or cooperating in separate groups, it is time for those those of us that feel strongly about freedom to discuss, decide, and move forward with our own free information movement built upon a standard of freedom. When we have defined free information in terms of essential freedoms, a subset of Creative Commons works and a subset of Creative Commons licenses will provide tools and texts through which a social movement can be built.
I'm thrilled to say that that day is now within sight. A few weeks ago, Larry Lessig introduced me to Erik M ller, a Wikipedian who had read my article and was planning on launching the same project that I had been planning. It only seemed sensible to collaborate. Today, we have launched a draft of a Free Content and Expression Definition online at freedomdefined.org. The website is a wiki and we welcome feedback, suggestions, and alternative versions of the document. So far, we've have decided to stick closely to the freedoms of free software but are actively interested in updating these to be more relevant for other types of creative works. Of course, anything, even the name, can be changed at this point. To guide us through the project of debating and further refining a definition are four moderators who will ultimately be called upon to resolve disputes and disagreements about what the definition should and will say. These moderators are myself, Erik M ller, Creative Commons General Counsel Mia Garlick, and Wikimedia Foundation Trustee Angela Beesley. You can view the announcement of the definition, please take a look at: To view the definition itself, please visit:

Benjamin Mako Hill: Controversy

Several days ago, I got a message from David G. Reichert, my representative in the U.S. House of Representatives (and the incumbent candidate in one of the New York Time's "Races to Watch"). His letter started out:
As your Representative in Congress, I want to share with you some of the work I have been doing to assist orphans in underdeveloped countries.
I grew up in a family that adopted several orphans from underdeveloped countries so I'm glad to see this happening -- I really am. But what really makes me happy is that I get to hear from my elected representative unsolicited -- for the first time, no less -- advertising his work on such a controversial subject. He seems perfectly willing to stand up for what he believes in, even if it means that he loses the crucial anti-developing-nation-orphan vote.

Benjamin Mako Hill: Rhyme Time

Who would design consumer electronic products around technological necessity when they could design them around clever bits of word play? I came up with the idea for an "iPod Tripod" -- if you will, a "TriPod" -- and was thrilled to see that someone else had already (a) stumbled upon the same little rhyme and (b) followed through on the idea and was already selling a product! The review I read seemed to indicate that the execution was not quite as good as the name. But then again, how could it be?

Benjamin Mako Hill: Calling All Seattlites

If you're in the Seattle area and are concerned about DRM, you should be at a "flash" protest against DRM tomorrow (Tuesday May, 23) before work (8-9AM) to kick off a major anti-DRM campaign. There will be costumes and fun to be had by all. These sorts of things are great if a bunch of people participate and just seem impotent if not enough do. This is important enough that I would consider flying back to Seattle for it if I had a little more time and money to do so. It's worth it to make sure this campaign starts off on the right foot. We have a lot to lose if it doesn't. If you are in the area and can possible spare an hour or two and be in downtown Seattle tomorrow morning, I think it is really important that you do so. You can get more information from someone at the FSF by emailing action@defectivebydesign.org and announcing that you want to participate.

Benjamin Mako Hill: Hitler Mustache Video

In my infinite spare time, I think it would be fun to make a parody of an MTV style "documentary" about one day in the life a person with a Hitler mustache to show ridiculous that genre has become. The video will be done with 15 second cuts and and with a bumping soundtrack by an eclectic selection of artists from the full spectrum of popular music. It will follow around a person for one day as they have a barber chisel out a Hitler mustache and then spend one day in that form. These scenes will, of course, be interspersed up with snippets from interviews with vapid onlookers, fashion gurus, and celebrities weighing in on all sides of the many "issues" that wearing a Hitler mustache raises. These issues might include:
  • Is it now or will it ever been long enough to make the Hitler mustache OK again? Did Hitler really ruin that mustache for ever and for everybody? Do fashionistas believe that this is that a good or a bad thing?
  • What about Charlie Chaplin and others who wore similar mustaches before or concurrent with Hitler?
  • In what sense does living with a Hitler mustache teach either the wearer or the public that "it's what inside that really counts."
If you would like to donate resources or time to this project, please let me know.

Isaac Jones: Announcing Haskell'

let haskell' = succ haskell98 in
Announcing the Haskell' ("Haskell-Prime") process.  A short time ago,
I asked for volunteers to help with the next Haskell standard.  A
brave group has spoken up, and we've organized ourselves into a
committee in order to coordinate the community's work.  It will be the
committee's task to bring together the very best ideas and work of the
broader community in an "open-source" way, and to fill in any gaps in
order to make Haskell' as coherent and elegant as Haskell 98.
Our task is broadly defined by our mission statement:
    The Haskell programming language is more-or-less divided into two
    "branches".  The Haskell 98 standard is the "stable" branch of the
    language, and that has been a big success.  A lot of progress has been
    made over the last few years in the "research" branch of the Haskell
    language.  It is constantly advancing, and we feel that it is time for
    a new standard which reflects those advancements.
    Haskell' will be a conservative refinement of Haskell 98. It will
    be the work of this committee to adopt a set of language
    extensions and modifications and to standardize a new set of
    libraries.
    We will strive to only include tried-and-true language features,
    and to define them at least as rigorously as Haskell 98 was
    defined. This standard will reflect the realities of developing
    practical applications in the Haskell language. We will work closely
    with the rest of the Haskell community to create this standard.
Your Haskell' Committee is as follows (slightly munged email addresses
follow):
 * Manuel M T Chakravarty <chak at cse.unsw.edu.au>
 * John Goerzen <jgoerzen at complete.org>
 * Bastiaan Heeren <bastiaan at cs.uu.nl>
 * Isaac Jones <ijones at galois.com>
 * John Launchbury <john at galois.com>
 * Andres Loeh <loeh at iai.uni-bonn.de>
 * Simon Marlow <simonmar at microsoft.com>
 * John Meacham <john at repetae.net>
 * Ravi Nanavati <ravi at bluespec.com>
 * Henrik Nilsson <nhn at cs.nott.ac.uk>
 * Ross Paterson <ross at soi.city.ac.uk>
 * Simon Peyton-Jones <simonpj at microsoft.com>
 * Don Stewart <dons at cse.unsw.edu.au>
 * Audrey Tang <autrijus at gmail.com>
 * Simon J. Thompson <S.J.Thompson at kent.ac.uk>
 * Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk>
 * Stephanie Weirich <sweirich at cis.upenn.edu>
The editors are Isaac Jones and John Launchbury.
Feel free to contact any of us with any concerns or questions.  If you
don't know who to direct your questions to, email Isaac Jones
ijones at syntaxpolice.org.
Community involvement is vital to our task, and there will be a way
for members of the community to make formal proposals.  In the opening
phases, please use these more informal resources to help us coordinate
Haskell':
 * The haskell-prime mailing list.  All technical discussion will take
   place here, or (if other meetings take place) be reported here.  Anyone
   can subscribe, and any subscriber can post questions and comments,
   and participate in discussions.  Anyone can read the list archives.
   http://haskell.org/mailman/listinfo/haskell-prime
 * A wiki / issue tracking system to document consensus and to track
   ongoing tasks.  This system is publicly readable, but only
   committee writable so that we may present it as the "official"
   output of the committee.  If you ever feel that the wiki is not
   accurate as to the consensus, please alert the committee!
   http://hackage.haskell.org/trac/haskell-prime
 * A darcs code repository for experiments, proposed libraries,and
   complex examples.  darcs is a decentralized system, so anyone can use
   it, but patches should be sent to Isaac Jones:
   http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode
Please join us in making Haskell' a success.

Isaac Jones: Who will be at ICFP 2006?

Greetings! You may know that ICFP 2006 will be in Portland, OR where I live. I'm wondering who will be there. If you know / have met me / chat w/ me on IRC, please drop me a line and let me know you'll be in town. peace.

Isaac Jones: How to get involved in Free Software (the bug method)

Are you a software developer? Are you graduating soon? Maybe you should get involved in free software projects! There are any number of reasons people get involved, from altruistic reasons to selfish reasons. Let's approach it from a "selfish" point of view. I assert that involvement in free software projects looks really good on a resume, and is an excellent way to "network". Networking isn't all about schmoozing at job fairs; it's about building a reputation with professionals in your field. There are very few fields where a huge number of professionals are so very accessible. Software developers are very lucky in this sense. Common wisdom seems to indicate that the job market for software developers is very competitive, and it's going to continue to be competitive for a while yet. Any edge you can get over your classmates is going to help. There is plenty of opportunity to contribute, no matter what your skill level. There is documentation to write and there are translations to perform. There are bugs to fix, and packages to create. Of course there are projects that need more "serious" development as well. You don't have to start your own open-source project, and you don't have to learn to hack on the Linux kernel to add something very attractive to your resume. When people ask me how to get involved in free software, I usually recommend that they start out reporting bugs in the open-source software they use frequently. You might install a version of GNU/Linux, or if you want to stick with Windows or MacOS, you should browse around to find out what free software is available. I think you'll be pleasantly surprised. Let's use "Gaim", a multi-protocol IM client, as an example of how this might proceed. Gaim runs on Windows, GNU/Linux variants, and I'd expect MacOS X, and Unix. It's open source and free: http://gaim.sourceforge.net/. Download Gaim and the Gaim source code. Build it for your machine if you want. Notice what language it's written in. Do you know this language? If not, can you understand it (if you know Java, you can probably understand a lot of C, for instance). Try out Gaim, set up your AOL Instant Messenger and your IRC channels. Visit some open source channels. See any problems? Check the bug reports to see if anyone else has seen that problem. If not, report it as a bug (you might want to google for "how to report a bug" first). Now check out the "bug reports" for Gaim. Pick a bug and try to reproduce it. Why are bug reports the first step in improving your resume?
  • Reporting a bug is a half-hour task.
  • Fixing a bug is often (not always) a small, weekend-sized task.
  • Bugs introduce you to the source code on a level where you don't have to understand everything (hopefully).
  • You will build familiarity with debugging tools which are invaluable for a developer.
  • You will start to build a reputation with the authors of the software, and in the free software community.
  • And because developers are always very happy to get bug fixes that they didn't have to work on themselves. Let's take a look at the bug list for Gaim again. Different ways to contribute to fixing a bug:
  • If you can reproduce the bug, you might add more information to the bug report: What steps did take to reproduce it? Is there a unique combination of features you need to be using to cause the bug?
  • If you can't reproduce the bug, maybe it's fixed in the version you're using! Maybe you should add that to the report (better read and understand it very carefully first). Pick another bug, repeat.
  • Depending on your skill level, you might try to fix this bug, or at least isolate where the bug came from. If you manage to fix it, read about the "diff" and "patch" utilities. Send the author a patch, or attach the patch to the bug report. Here is a bug that looks pretty easy, and it doesn't look like the developer is particularly thrilled to spend time on it: "Buddy Pounce does not get removed when user is deleted". I'm going to take a wild stab at how you might fix this bug: most probably, there's a "list" of "pounces" that has a data-structure which contains both the buddy's name, and the pounce action, whatever that is. Find the code where the buddy is deleted from the buddy list (a different list). Add code to search through the "pounces" list to delete that buddy from the pounces list as well. Compile, test, and run diff to create a patch, attach it to the bug report, take a bow. Now add this to your resume. You are now 50% more interesting to me, as someone who reads resumes, than your classmates who have never taken on a project outside of school. You've shown initiative, skill, and maybe even teamwork. Higher levels of commitment If there's a piece of software that you love, that you think is really important, then you might try adding features to that software and joining the development effort. Lots of projects have a page dedicated to information about how to help out. Here is one for the Mozilla project, for instance. If you want to lead a development project, you might adopt one that has been orphaned. Many people recommend against starting your own project off the bat. I've presented you with a method to increase your skill and reputation, and to add something interesting to your resume. Try it out. You might find out why so many software professionals work on free software projects. It's tons of fun! Feel free to send me comments on this document, or to tell me whether this advice has effected you.

    • Isaac Jones: So Much Writing!

    I have not been doing enough hacking, or blogging lately in part because I've been doing so much other writing. I've got one paper and one demo at the upcoming ICFP-related workshops in Estonia. The demo is at the Haskell Workshop, and is a presentation on the filesystem I've been working on at Galois; it's written in Haskell. The paper is at Trends in Functional Programming and it's on The Haskell Cabal. I also have been doing book reviews. I mentioned a review on a book called Codex recently, and I wrote a review for The Journal of Functional Programming but it hasn't been published yet, and I'm writing on for Matt Curtin's new book, Brute Force but I'm not quite done with that one. Of course linkage will be forthcoming when it's available. Also my damn gateway laptop is having screen flicker again. It's already been fixed 4 times for this same issue. That is very lame.

    John Goerzen: Lazy big-O and Haskell Answers

    First, Evan has a host of interesting articles about Haskell, and I found his lazy big-O article particulary interesting.

    Next, Eric Warmenhoven has recently taken up Haskell and posted some Haskell questions on his blog. Eric, here are some answers for you.

    First, regarding shared libraries. While Haskell can be compiled to machine code, and GHC is a popular way to do that, a standard C way of representing information about a library (.h and .so files) is not really rich enough for Haskell. Consider, for instance, that functions may accept arguments of a wide range of types (or even things such as lists of any type). Haskell also performs type checking, and thus must know the type of arguments a function expects, as well as its return type, at compile time. So you do not generally compile Haskell code directly to .so files, but rather use the compiler's module or package support to do that. See Cabal for more information on packages. Through the FFI (Foreign Function Interface), it is possible to both call into C and be called from C with Haskell code, if that's where you want to go. It is actually easier in Haskell than in any other high-level language I've dealt with before.

    Regarding circular module deps -- I've never used them and can't really comment. I can say, though, that the .boot files are internal files created by GHC.

    Regarding practical stuff in tutorials -- I share your complaint there. I have found a few that are better than the others: Yet Another Haskell Tutorial, and Haskell: The Craft of Functional Programming, 2nd ed., by Simon Thompson. Several of us are working intermittently on a project called Haskell V8 -- take a look and darcs send me patches! I would say that Haskell's I/O system is the most powerful I've seen in many ways -- especially with regard to laziness -- and in the upcoming GHC 6.6 release, it will be both lazy *and* blazingly fast. Very nice.

    There isn't much Debian-specific documentation, but there is a draft policy and a mailing list (link to it is in the policy doc).

    Hope this helps!

    Marco d'Itri: I like receiving (some) bug reports

    I suddenly realised that I like receiving bug reports. In a recent bout of structured procrastination I fixed more or less all the bugs I could fix in my packages (except ppp. I don't feel like working on ppp right now, does anybody want to help me?) and now this is a quiet period. Obsessively checking the bugs mailbox for new messages is a clear withdrawal symptom. I am addicted to bugs for a very simple reason: they are a challenge. I stopped working on mutt because it was not interesting anymore to me and then I adopted ppp and packaged udev because I tough that maintaining them would require solving many interesting problems. It's too bad that solving some needs the collaboration of other developers, but this will be the topic of a different rant. But not all bugs are an interesting challenge. Some are just a total waste of my time, which usually is much more valuable than the time of the submitter. I will show some examples. So, if you can follow these simple rules I will probably not flame you to ashes the next time you will report a bug on one of my packages.

    3 September 2006

    Jonathan McDowell: Please look after this geek

    I have been abandoned. Just over a week ago Kathy was offered a job at the University of Ulster, in particular on their Coleraine campus. She starts tomorrow (they wanted her to start last Friday) as a Lecturer in English, so yesterday she flew back to Northern Ireland. Leaving me in Norwich (well, actually I was in Cambridge, but I'm back in Norwich now and will continuing to live here). We've done the long distance relationship thing before, while at university. It wasn't particularly fun and I'm not really looking forward to doing it again, but her contract is only for 9 months and as such it doesn't make sense to have a massive upheaval for what's a relatively short period of time. If she gets extended then we'll need to rethink, but at present that doesn't look that likely given that it's maternity leave cover. One thing is that I'm a bit worried I'm going to become very strange. Working from home will mean I'll not see anyone during the working day and there won't be anyone else around in the evening. I'm going to need to make more of an effort to seek out human contact otherwise I'll turn into an odd hermit. Especially given the fact I've a whole bunch of tech toys to play with (more on which later). Overall I'm very glad Kathy's got a job; it may be in a bloody inconvenient location, but she was understandbly getting a bit down about the lack of English lecturing jobs that are out there. Hopefully now she's had one the next will be easier to get hold of...

    Rapha&#235;l Hertzog: Steering committee or board?

    There’s a new idea floating around: creating a steering committee for Debian. I like the principle but I think we should aim for a broader change in the constitution. I don’t think creating a new separate structure is a good idea, because in my opinion the DPL should be the steering committee. Of course a single individual can’t play that role. And in fact, this is true for almost any task that the DPL currently has to handle. So we need to get rid of the DPL and to replace it with a board. And that board would be the steering committee and would also have the responsibilities that come currently with the DPL hat. Why? First of all, the role of DPL is to provide a vision but most recent leaders have not been able to do that as they tend to get overwhelmed by simple administrative work. If you remove the hope to effectively lead Debian by giving that power to a committee, then you scare everybody that wanted to be DPL because it effectively become an administrative position with no interest. Then, in recent years, the DPL position tended to become a multi-person thingie, first with the DPL team idea and this year with the 2IC (sort of a “DPL assistant”). So it looks like we’re ready to switch to a fully multi-personal leadership: one of an elected board. And last point, since the DPL tends to be active only on internal organizational issues, for most persons he’s only working on “political” stuff and he’s not valued as contributor leading the distribution where it needs to be lead: to the next release. That’s why I suggest that the board should be elected for an entire release with a maximum of 21 months. After each release we elect a new board and it should be in place for 18 months ideally. Tying the term to a release seems like the right approach to me: at the beginning the board is effectively doing most of its work as steering committee (setting/approving release goals) and at the end, during the period where we’re freezing it has more time to concentrate on organizational issues. The questions is now: how is that going to work with the release managers? Will that position become only an administrative work of low-level coordination without any influence on the whole distribution?

    Next.

    Previous.