After a semi-recent thread on debian-devel, I poked around and realized that I'd never actually gotten around to formally announcing the release of source code for Selectricity, a piece of web-based election software designed to allow for preferential decision-making and to provide "election machinery for the masses." Selectricity is useful for a range of decisions but it targets all those quick little decisions that we might want to decide preferentially but where running a vote would be overkill. Things were delayed through a drawn out set of negotiations with the MIT Technology Licensing Office over how to release the code under a free software license of my choosing. I was swamped when things finally came through. Over time, I managed to forget that I never did a formal announcement, never setup a mailing list, and never did all those things that I have tried to teach other people in the Free Software Project Management HOWTO. Code just sort of appeared on my website under the GNU Affero General Public License. It was until the debian-devel thread that I remembered I'd never made a formal announcement. Sorry about that! The git repository has been online and accessible through searches for more than a year now. Most folks who wanted the code seem to have been able to find it there. Indeed, a number of people have set up their own instances and a few have submitted patches to the code! But more visibility for the source means more empowered users, more visibility for free software, and more developers. So I've shipped all the code into a project in Gitorious (its like GitHub, except free), announced things on the Selectricity Blog, changed the Selectricity footer of to include a prominent link to the source. I've also created a mailing list. The Gitorious project page includes a wiki. I also want to mention this all here because the attention of the current development team seems mostly to have moved on to other projects. The current team seems able to keep the hosted version up and running, and even gets around to little improvements now and then, but there's definitely room for new life and new leadership. There are some nearly-complete and "complete minus further testing" features in the development tree that might provide low hanging fruit for folks interested in elections and decision-making who might want to get involved in Selectricity development. If you're interested and know (or want to learn) Rails, feel free to check out the code, introduce yourself on the list or contact team@selectricity.org to coordinate.

I finally finished an article I've had in one form or another for years about on the use of proprietary tools in the creation of free software. From BitKeeper to SourceForge to Google Code to GitHub, non-free tools and services have played an important role in free software development over the past decade and, I argue, continue to create a number of important, if sometimes subtle, problems for our community. The article was published in the Spring 2010 FSF Bulletin which was mailed to all FSF associate members. I've also posted the article on my website and in PDF form as well.

Due to a variety of people and places we want to see, Mika and I have regrouped around a more ambitious travel schedule in Italy for the next week or so. Our new plan is:

• August 23-27: Florence
• August 27-29: Verona
• August 29-31: Bologna
• August 31-September 1: Siena
• September 1-3: Rome

I know we'll have an organized LUG meeting in Siena. The rest of the period is a little more open. As always, if other free software, wikimedian, or like-minded folks are around and would like to meet up in any of those places, don't hesitate to get in contact. In related news, inspired by Florence and by Mika's domo-kun purse, I made a duomo-kun today.

I've got a pretty packed August. I just wrapped the Open and User Innovation Conference at MIT -- the academic conference on user and open innovation connected to my research. I organized the program and was MC for the 120+(!) talks and research updates on the program so it's a huge relief to see it come off successfully. On Thursday, August 5th (at 14:30 UTC) I'll be giving a talk on antifeatures at DebConf (the Annual Debian conference). It was accidentally listed as "Revealing Errors" until a few minutes ago -- sorry about that! It will be streamed live (details on the DC site) for those outside of New York City who might want to follow it. As soon as DebConf is done on August 8th, I'm going to head to Kor ula in Croatia to relax, read, and hopefully get a bit of research done, before I head off to Outlaws and Inlaws in Split on the 19th, a sort of piracy and (vs?) free software summit put on by mi2 connected to the recurring Nothing Will Happen where, from what I hear, quite a lot does. I'm going to have to leave Nothing Will Happen a little early to head to FrOSCon on the 21st where I'll be doing an antifeatures keynote again on the 22nd. I tend not to like to do the same talk too many times, or for more than a year, so this might be one of the last times I present on antifeatures in this form. After that, I'm going to head to Italy where I'll be between the 23rd and the 3rd of September. I'll fly and in and out of Rome and plan to spend some time in Rome, Tuscany, and Florence, but don't have a lot of set plans and might travel to Bologna or elsewhere. My schedule is pretty open. As always, I'm interested in meeting up for coffee or a drink with like-minded hackers, Wikipedians, researchers, activists, etc. If folks are interested in organizing talks or presentations, that sounds fun too. I'm keeping a brief description of my schedule updated alongside a bunch of ways to get in touch with me on my contact page. Don't hesitate to drop me a line!

Over the last couple years, I have begun teaching. At first just a reading group or seminar with a handful of attendees. Last term I helped teach two large lecture classes. I know that, compared to some of my colleagues, I spend an enormous amount of time assessing and evaluating students' assignments. I try very hard to give detailed, substantive, feedback on each piece of student work. At the end of the day, however -- at my school at least -- there's always a grade. For someone who went well out of his way to go to a college with no grades, there's a tragic irony to the whole situation: I think grades mean little and are often worth much less. Today I am forced to to inflict them on people who, almost universally, do not.

Today I started to tell a friend about something from dinner the night before. Except that she was at the dinner. And sitting at the same table! Even when prompted, I couldn't really remember! This does not warrant a blog post. Anybody who knows me well knows that my memory for these kinds of more mundane details is pretty porous. This kind of thing happens all the time. I'm writing this so that when I'm much older, and still forgetting things all the time, folks can use this as a reference point before concluding that senility is setting in. I'm afraid that everyone else will forget my forgetfulness!

Folks at last year's Wikimania may remember the presentation I gave there. It was essentially a literature review of Wikipedia and Wikimedia scholarship from the previous year. The idea was to give a bird's-eye-view as well a series of highlights -- all aimed at Wikimedians. Apparently somebody found it useful because I've been asked to do it again! I'm going to be paired up in a longer session with Felipe Ortega -- whose excellent dissertation I summarized as part of my talk last year -- and Mayo Fuster Morell has also agreed to help out. Felipe is program chair for WikiSym this year and will be focusing on providing folks with a summary of the papers published at that conference. It will be held immediately before Wikimania in Gdansk. For my part, I'm going to be focusing more broadly and talking about papers published, well, anywhere else. And this is where you come in! With search engines and all, I've got a pretty good idea of breadth of the work that's out there. I also "just know" stuff from my own areas of interest and study. That said, I don't have as strong of an idea of what's good and what's relevant beyond what I can grok from citation counts. And after one year (or less!), that's clearly not very much information. As a result, I'm looking for suggestions or recommendations from anybody on interesting, useful, important, or otherwise noteworthy scholarly papers on or about Wikipedia or other Wikimedia projects published in the last year. Feel free to leave a comment, email mako@atdot.cc, or edit this page.

On probably a dozen occasions, I've had people in cars taunt me by yelling some version of "Lance!", "Hey Lance!" or "Go Lance!" at me while I am riding my bike. It seems to be particularly likely if I'm wearing spandex. Indeed, the "verb" to Lance has an Urban Dictionary entry and there is a Facebook group for Yelling "Hey Lance!" when you see someone riding their bike. My friend Seth pointed out -- after we were (collectively?) called "Lance" in California -- that it's pretty strange to insult somebody by comparing them to a man who is nearly guaranteed to be on any list of greatest living athletes, in any sport.

Hello The GSoC project Krzysztof and I are working aims to facilitate configuration upgrade during package upgrades. Most of the cases, this upgrade should not require any input from the user, even if the user had previously customized his configuration file. Currently configuration upgrade may ask questions to the user which may be hard to answer for most non-technical users. For more details see PackageConfigUpgrade on Debian wiki. (If you are not familiar with upgrade issues, you might want to read this page.) At the 2 extremes of upgrade tools, we have:

• tools based on diff3 (like ucf)
• Config::Model based upgrades

Each tool has its own advantages and drawbacks. On the plus side of diff3 tools :

• minimal work required on upstream or packager

On the other hand, here are the issues with diff3 based tools:

• may produce syntactically wrong files
• may leave conflicts unresolved
• may leave duplicated (and conflicting) statements
• may loose user data

For more details on diff3 issues, see Benjamin Pierce s paper (thanks to David Lutterkort from Augeas for the info) On the other end of the spectrum, Config::Model pros are:

• Very robust, should work in most cases
• Can be set up to migrate user data from old config format to new format
• Leave upstream more room to change their project

But, Config::Model main problem is:

• Lot of work required from upstream or packager to create models

diff3 tools is lackluster for users. While Config::Model puts too much strain on packagers because it requires configuration models where all parameters are defined and declared in the model. For fast evolving projects, this can be a huge recurrent task (been there, done that for Xorg) . (Well, this recurrent task is a problem until doc, implementation and config model can be extracted from a single meta-description But I digress, this may be a project for GSoC 2011 :-p ) So, this GSoC project (for 2010) aims to find a compromise between these 2 extreme cases. On Config::Model, I ve always had a drawer statement whenever I was asked why Config::Model does not handle unknown parameter:

a configuration file cannot be validated if an unknown parameter can t be distinguished from a user typo.

This stance is fine for casual user interaction on a stable system: an unknown parameter is most likely an error. And the user must be warned of his error as soon as possible. For a stable distro release, packagers should have the time to provide complete models, so basing upgrade on complete models should be possible (famous last words ?). On the other hand, a lot of configuration upgrades will be done on unstable systems where software evolve quite fast, where models will likely fall behind software evolutions. Another shorcoming of my drawer statement is that it assumes user interaction where erroneous input is more likely. In case of configuration upgrades, there should be no user interaction. And we can assume that the config file to be upgraded was used (and thus validated) by the old version of the software. So unknown parameters should be tolerated and managed as best as possible. Now, the big question is: how ? In all attempts I ve seen in managing upgrades that goes beyond diff3 tools, the configuration is stored as structured data. Sometimes this structure can be infered from the configuration file syntax (shell vars, INI files, YAML, XML), sometimes not (sshd config file). In the latter case, some structural knowledge must be built in the upgrade tool. Currently, Config::Model is designed to bring a complete description of the structure and semantics of a configuration file. This is perceived as bringing too much structural and semantic knowledge ( too semantic ). So the maintenance cost is perceived as too important. That may be right or wrong, but that does not matter. Perception is more important here. So, let s figure out a way to reduce the amount of work required to perform upgrades (you may want to read a little bit more on configuration model creation before going on ) One possibility would be to support configuration models that allow unknown leaves in nodes. Such a model would provide a kind of fallback leaf description. Something like: this parameter is unknown, let s assume it s a simple string value . Let s consider sshd_config example to see how such a behavior would pan out for some upgrade scenarios. sshd model is made of 2 main classes:
- Sshd
- SshdMatchElement The second one contains all parameters allowed in a Match class (in fact, Match parameter is the only one in sshd that defines a new hierarchical level. All other parameters are simple leaves). Now let s consider typical upgrade scenarios from old version (with old models) to a more modern version. Let s assume that the model is lagging behind and the model does not follow sshd evolutions. So Config::Model will face 3 upgrade cases (extracted from sshd config history):

1. Unexpected parameter that are actually simple leaf parameters. E.g. introduction of ClientAliveInterval.
2. Obsolete parameters that should be migrated. E.g KeepAlive is renamed into TCPKeepAlive
3. New structural parameters (introduction of Match element)

So what would happen with a model allowing unknown parameters but lacking specific instructions for these upgrades:

1. ClientAliveInterval value would be kept.
2. KeepAlive would be kept as is.TCPKeepAlive would also be kept. No migration is performed, but the configuration would be good. As long as sshd supports the old parameter, we re good. :-/
3. Without knowledge of the structure brought by Match parameters, Config::Model would consider that parameter in Match block would duplicate parameters in the main block and remove the duplicate. User data may be lost.

So, there s not silver bullet. Let s resume what we ve learnt:

• to perform upgrade, the structure of the configuration must be specified
• A minimal model that would perform upgrade for Sshd without any validation would require only knowledge of Match parameter

Next step is to figure out what would happen if the same strategy is applied to other types of configuration files. But that will be for another blog. All the best

Dear lazy web, How can I send a command when pressing a key? To make it more complex: I have two input devices A and B. The command should be only sent, when the keys of device A are pressed (and not device B). The devices A and B have the same key codes. For example, pressing the dot key on device A should run a command, but pressing the dot key on device B should just produce a dot. Is it possible to use device A as input device for lirc?

Dear lazy web, I want to control OpenOffice.org Impress through my remote control on Linux. Does OpenOffice.org Impress has a lirc plugin or is there another easy way to do it? The system that hosts the presentation is used for other things, too. Therefore the current active windows is not always Impress. Sending a key code to the active window won t work. Update: The computer has two screens: A TFT and a video projector. It is used for audio recording and hosting the presentation. The active window on the TFT is the audio recording application. The presenter can only see the video projector and should be able to control the presentation with a remote control that works with lirc.

Account created for myaddress<at>glandium.org with hg_mozilla and mg_mozsrc bits enabled.

Yes, this means I now have commit access on hg.mozilla.org. Thanks to those who vouched for me, namely Justin Wood, Christian Biesinger and Benjamin Smedberg. And thanks to the Mozilla governance for having changed the commit access requirements just in time for me to take advantage of the new ones: under the old rules, it was required that the vouching superreviewer had never reviewed a patch from the person applying for commit access. Of the 31 superreviewers, 14 (almost half of them) already had reviewed one or more patches from me (which is not really unexpected, considering the number of patches I sent in the past). One could wonder why I never applied for access earlier, though.

The entries matching /Debian, which you requested could not be found.
Do you want to go back to Benj's tavern?

We have a units policy in Ubuntu, which we have to implement in lucid+1 (Ubuntu 10.10). Correcting all applications to conform to this policy is not an easy task. The first attempt to patch glib, which provides the g_format_size_for_display() function, failed. We need a library that can handle input and output formatted sizes. Take transmission as example: I want to set the bandwidth limit in the same unit as it displays me the limit. We have to introduce a set of new functions. Should I create a new library (named libbyteunits or similar) or add a bunch of new functions to glib (as replacement for g_format_size_for_display)? Is glib the right place for ten or more functions handling units? Pros for a separate library:

• the library can be used by non-glib application without depending on glib
• it can be made user configurable (for example by an text file), because some user prefer base-10, others base-2.

Cons:

• one more dependency for glib applications

I like to hear as many opinions as possible. Please let me also know, if you are glib developer, a g_format_size_for_display() using developer, a developer, or a user.

I own a Samsung SGH-X160. It s just a mobile phone for telephoning and writing SMS messages. I was sitting in a train last weekend and wanted to add a note to my task list in T9, but the phone didn t know Eclipse. I wanted to add Eclipse to the dictionary, but instead the phone crashed (rebooted). I tried it multiple times and it s reproducible: Grab your SGH-X160, add a new task (Aufgabenliste -> Optionen -> Neu), type 3254, T9 will suggest Eckh, press zero to toggle T9 s suggestion until it gives you the option to add the word to the dictionary, press adding (Zuf gen), correct the word to Eclipse, press OK. Your phone will go blank and then present you the boot splash for a half minute. I want to file a bug and grab the source code to fix this bug. Oh, that is not possible, because the OS on the mobile phone is not free (libre) software.

We, the Debian Orbital Alignment Team (DOA team), have released eclipse 3.5.2-1 to Debian unstable today after nearly seven month of work and 612 commit to our git repository. Many thanks to our hero Niels Thykier (222 commits). Without him we wouldn t have eclipse in Debian now. Thanks to Pablo Duboue, Adnan Hodzic, and Adrian Perez for their work on the Debian package. Last but not least, I want to thank Alexander Kurtakov and Andrew Overholt for eclipse-build, which we use to build eclipse. You should have modern hardware, if you want to build eclipse. It will need three gigabytes free disk space, two gigabytes memory, and at least 12 minutes to build, but it can need hours (on old hardware or if you have not enough memory). Update: Four days later we released 3.5.2-2 to Debian unstable. Today eclipse 3.5.2-2 was synced to Ubuntu 10.04 (lucid).

The recordings for Linux Conf Australia 2010, held this year in Wellington, are finally online. The recordings include a video of my keynote on Antifeatures. I was deeply honored to be invited to give a keynote at LCA and, as a result, felt more pressure than usual to put together something that was novel, relevant and entertaining and that spoke to core issues and problems facing free software. Although it's always hard for me to watch myself speaking, I've made it through the video and am reasonably happy with the result. Although perhaps it's a minor distinction, I think this lecture is probably the best talk I've given given to date! I hope to give the talk again so, as always, I welcome comments and feedback. If you'd like to watch it, the talk is available in a number of free and non-free formats:

• Video in Ogg Theora -- Should "just work" in new versions of Firefox
• Audio in Ogg Vorbis
• New Zealand Mirror with media in Flash, Theora, Vorbis, and MP4/MP3 versions

I wrote this for the FSF's annual membership drive where it was originally published. I am reposting it here.

At its core, I think of free software as about the ability of computer users to take control of their technology. Insofar as our software defines our experience of the world and each other, software freedom is an important part of what allows us to determine the way we live, work, and communicate. Free software is not really about software in this fundamental sense; it's about bringing freedom to users through software. In free software's incredible success over the last two decades, many people have lost sight of this simple fact. We have created an incredible array of applications, libraries, and tools. We have created vibrant development and support communities. We have created new development methodologies, powerful copyleft licenses, and massive collaborative projects. But these are all how we give users freedom. They are not freedom itself. They are not what we were trying to achieve. They are our instruments, not our goal. This distinction becomes central in a world where technology is in flux. Indeed, we live in such a world. We can see signs of this in how, as most users' primary computers become mobile phones and new types of network services make up most of many users' interactions with computers, the free software movement's old applications, communities, development methodologies, and licenses can become ill-suited to, or ineffective at, protecting user freedoms. And indeed, in the next few years, bringing freedom to computer users will need to involve new software and new forms of advocacy. It will need to involve new licenses and new techniques for their enforcement. It will need to involve new forms of collaboration and organization. If the free software movement is to succeed, it must stay focused on computer users' freedom -- on the question of why we do what we do -- and then work creatively on how to best respect and protect the freedom we are working toward. If we are overly focused on how we've done things in the past, we may lose sight of the most fundamental goal of supporting users' control over their technology in general. There are many organizations that support the how of today's free software in various ways -- they are law firms and companies and nonprofit organizations supporting various free software projects. The Free Software Foundation is, by far, the most important organization focused on why --- on the underlying principle of software freedom. As such, it plays an essential role in keeping our broader community focused on the key issues, threats, and challenges that will affect the success of every free software project, and every computer user, in the present and in the future. In this period of rapid change in computer technology, its role is more vital than ever. The consequence of any failure is more dire. Here are some of the ways that I will be encouraging the FSF to serve the free software movement in the coming year: Mobile Phones In a short essay I wrote earlier this year, I pointed out that there are now billions of mobile phones and that, although these phones are increasingly powerful computers, they represent one of the most locked-down, proprietary, and unfree technologies in wide use. The implications of this fact for users' control over their technology are dire. Although some widely used phones make extensive use of free software, most free phones are locked down and Tivoized and their users remain fettered, divided, and helpless. We must raise awareness of free software issues among users of phones, communicate to users that phones are powerful general purpose computers, and explain that control over these devices has critical implications for individual autonomy in the future. Toward this end, the FSF staff will launch an advocacy campaign around mobile phones and software freedom in the coming year. Network Services As network services -- like those built by Facebook, Google, and others -- have continued to grow both in scope and penetration over the last year, the importance of a meaningful free software responses grows as well. The launch of products like Google's network-centric ChromeOS offers one glimpse of what a future computing platform may look like. The implications for user freedom, and for the effectiveness of traditional free software approaches, are frightening. The fact that many network services are built using free software does not make the effect of these services on users' autonomy and freedom any less catastrophic. In the next year, the FSF is planning to release the first of what I hope will be several statements on software freedom and network services. Building off the work of the FSF-supported group Autonomous, the Foundation will help provide guidelines for those implementing network services, for users deciding whether to use services, and for developers trying to build services that go further to respect their users' freedom. Reaching beyond our traditional communities Successfully fighting for user freedom is going to mean successfully reaching out to users outside the FSF's historical base . The FSF continues to do so with its Defective By Design anti-DRM campaign and its End Software Patents work. In the last year, the FSF has also reached out to younger users through its "GNU Generation" campaign run by and for high school students. Additionally, the FSF convened a summit this year on women in free software. The FSF plans to build on these successes in the coming year and to expand similar outreach projects. Of course, fighting for and promoting software freedom is more work than today's FSF has the resources to accomplish. Each of my three points above represents an ambitious undertaking, and yet just a portion of the items on the plate of the FSF's small but dedicated staff. Even just continuing its existing projects will require that the FSF adds hundreds of new members by the end of this period. Your membership and donations help make goals like this possible. A strong free software movement focused on the principled issues of software freedom -- and a strong FSF in particular -- will determine what freedoms the next generation of computer users will enjoy. At stake is no less than that next generation's autonomy. I know that this is not the first fundraising appeal you've read this season and I know that the weakened economy makes giving difficult for many. I understand that the cost of a membership or donation may be less easy to afford this year. But we also cannot afford a weakened FSF at this important point of technological transition. If you are not an FSF associate member, now is the time to become one. If you've read my appeal the last two years and decided to wait, now is the time to take the plunge. Membership is $120 per year ($60 for students) and payable monthly. If you are already a member, please join me in giving generously through a tax-deductible donation, or encourage a friend to sign up. The FSF is a small, humble organization of passionate individuals working tirelessly for our software freedom. I've seen firsthand that even small gifts make a difference.

Join now with a $10 monthly donation

Over the summer, there was a bit of a tussle at the highest level of Ubuntu governance over whether or not Canonical Ltd., the company that funds the majority of work done directly in Ubuntu, should name its file syncing and backup service Ubuntu One. Canonical's service involved a freely licensed client included in the Ubuntu distribution but, as a network service running on Canonical servers, it was not clearly a part of Ubuntu (the GNU/Linux distribution) or Ubuntu (the community) in the way the term was usually used within the community. Although the network service itself was not Franklin Street Statement free, this was not the most important issue for everyone who objected to the name. The major issue for many seemed to boil down to the fact that, free or not, Ubuntu One is a service run entirely by Canonical outside the reaches of the Ubuntu governance structures. Decisions were made and not everybody -- and maybe not anybody -- was absolutely happy with the outcome. My goal is not try to revive old arguments here. As far as I'm concerned, the issues are settled and the service is called Ubuntu One. That said, the questions raised during the episode are fundamental to Ubuntu and to other firm-sponsored FLOSS projects. Now that the dust has settled, they are worth reflecting on. From a legal perspective, there never was any ambiguity. Canonical "owns" the Ubuntu trademark. In this important sense, "Ubuntu" means whatever Canonical says it means. This is hardly new. As just one example, the Official Ubuntu Book (of which I am an author) was written by community members but became official because Canonical blessed it. But despite the fact that they don't need to, Canonical has often consulted with the community and its governance structures about trademark licensing policy. This was also not a case of Canonical not listening to the community. Canonical employees approached the Ubuntu Community Council (Ubuntu's highest governance board of which I am a member), listened carefully to concerns, and responded thoughtfully. The question was not even about a clash between what Canonical and the CC thought about the issue. An unambiguous majority of the board, including all the Canonical employees and several of the community members, supported the idea of Canonical using the trademark. The question was one about who gets to make the decisions about the Ubuntu name and about what role the community and Canonical would each play. Despite the fact that a majority of the Ubuntu community council was likely to support the proposed name, the CC was told by Canonical CEO Mark Shuttleworth that a vote was irrelevant. Canonical made it clear that decisions about the Ubuntu trademark were simply not in the CC's purview. The decision on how the name was to be used was something that Canonical was not willing to delegate to an "outside" (the firm) governance body. Few businesses would. And although I don't agree with the decision as a community representative, I might have even made the same call from Canonical's shoes. In traditional firms, it's usually pretty clear where the organization's boundary lies. In FLOSS projects -- and especially in FLOSS project like Ubuntu who are sponsored in very large part by a single for-profit company -- boundaries are fuzzier. The conversation about "Ubuntu One" can be seen as a fight over what "Ubuntu" refers to, and, more importantly, who gets to answer that question. In deciding whether to call a service "Ubuntu", a decision is made on what Ubuntu is. Names are powerful. Is Ubuntu just a Canonical project? Are Ubuntu's contributors really just Canonical contributors by proxy? I think the answer to both questions is "no" but the boundary issues involved are complicated and under constant negotiation. Every time Canonical uses the Ubuntu name itself or grants others the ability to do so, these boundary issues are negotiated, one way or another. This boundary setting work reveals an important tension that firms releasing FLOSS must all struggle with. To what extent and in what ways do communities get to decide what a FLOSS project is and to what extent do sponsoring firms get to do so? How should projects and firms do this most effectively? What should we even be optimizing for? I think that any resulting balance has a huge effect on whether a FLOSS project is, on one hand, released under a free license but run like any old corporate project or, on the other, a true "bazaar" style project where no single firm dominates -- or where they fall on that spectrum. Names and trademarks are one way that projects define their own identities and act as an important frontier in this balancing act. As every firm/project negotiates their own answers to questions of names and boundaries, there are important implications for the project's ability to attract volunteers, solicit contributions from other firms, and more. The confusion around conversations about Ubuntu One shows that we still have a lot to learn.

My sister just got a lower back tattoo that says "No Regrets." She does not seem to appreciate the potential for irony. That's too bad. In my book, that potential is the best reason to get such a tattoo.