Luis Villa: Open Tech and Policy
Software, law, and the spaces in between.
I’m celebrating the end of my portion of my trial by … spending all weekend in meetings, specifically the OSI’s annual face-to-face board meeting, which we’re holding this year in Chicago1. It’s been a very productive meeting so far, with lots of good discussion about both our vision and our plan for attacking the future. The organization still has a long way to go but there is a lot of potential here.
After the release of MPL 2, the first request for MPL 2.1 came from someone who didn’t want to put copyright headers in individual files. The issue has recently reared its head in Apache as well, and I recently was asked related questions by a GPL user as well.
The main reasons given for not using per-file headers are two-fold:
The case for per-file copyright headers is put well, and succinctly, by Larry Rosen:
“[O]ur goal is to pass on any important IP information that might be useful … in the place(s) [downstream licensees] are most likely to find it.”
Larry’s comment makes two assumptions that I want to flesh out and support.
First, Larry assumes that the place where people are “most likely to find” licensing information is in per-file headers. It is true that in the best case scenario in many modern languages/frameworks, library-level is a great place to put licenses – in normal use, they’ll get seen and understood. But lots of coding in the wild is not “normal use.” I review a lot of different codebases these days, and files get separated from their parent projects and directories all the time. And then you have to use fairly complex (and often expensive) tools to do what should be a simple task- figure out what the license is. So, yes, modern frameworks should in theory reduce the need for per-file licensing information – but in practice, that is often not the case.
Second, Larry assumes that you actually want people to use your code. Lots of publishers of open source code seem surprisingly unconcerned by this, unfortunately. The functional, practical benefits of open source all start with someone else reusing your code, so if you’re publishing open source code at all, you should be concerned about making it easy for people to use the code you publish. Again, putting licensing information in each file can help make this easier, by making it easier for people to figure out their rights and responsibilities. (This is particularly true if you want commercial uptake, since so many commercial users of open source are getting more conservative about using source code that is not properly labeled and licensed.)((Larry also perhaps assumes you want people to respect your license when using your code; that is a surprisingly complex topic that I will try to address some other day.))
So, yes: if you want people to find your licensing information, and to use your code, per-file headers are the way to go. They may not be ideal but they really are worth the effort.
Based on my series of MPL posts for opensource.com, I’ve been nominated for a “people’s choice award” as a top contributor to opensource.com. It’s a nice little honor. That said, there are lots of folks on the list of nominees who have written and thought far more than I have this year- so you should go check out the list and vote for one of them instead :)
Over the past few years I’ve heard a few friends talk about plans to get off the internet for one day a weekend, one weekend a month, etc. Each of the past two years I’ve tried to take 3-4 days off the internet, and both times it has been rejuvenating- I come back feeling pretty invigorated, focused, etc. But that feeling didn’t last too long last year and I doubt it will this year.
So … do any friends who have tried similar things have tips or thoughts on how to do an internet detox on a more regular basis and actually make it both effective and sustainable? I imagine that the “make it sustainable” part inevitably involves advice on how to handle email, work, twitter, etc. while you’re gone. Twitter and greader I’m actually pretty good with just “mark it read and move on” but that’s much harder with email for me.
Saw this for the first time on my drive to work yesterday:
Congrats to all my friends on a very solid release and on reinvigorating their important message of public service.
So… I’m in the market for a way to read RSS feeds offline, with no keyboard; i.e., some sort of tablet or kindle-like device. Ideally it should be cheap and reliable (reliable in the sense that I can pick it up every morning while still groggy, take it to a concrete bunker with no wifi, and fully expect that I will have 45-60 minutes worth of reading on it- something should download feeds overnight without me thinking much about it after initial setup. ) Other features (ebooks, app stores, what have you) are a plus but not necessary. Ideally would sync with Google Reader, but am willing to compromise on that check here.
Options I’m looking at right now:
Are there other options I’m missing? Less popular/more hackable e-reader devices? Other tools?
Some things that aren’t options:
Thanks in advance, oh broad intarwebs…
Tim Lee is quite close to something very smart here, I think, and related to something I’ve been pondering for a while: why are so many open source software UIs typically bad?
Tim’s primary answer, I think, not wrong: good design generally results from having a strong vision of what good design for a particular piece of software should be. “Cult-like” may be overstating it, but good software does need a strong vision, and the holders of the vision need the means to get developers to buy into, execute on, and stick with that vision.
So Tim gets the answer right- but I think his framing of the question is actually a little off, in a way that merits discussion.
The first mistake Tim makes is that when he says “open UIs suck.” This is not false, but it is misleading. The more general rule is that most UIs suck; open UIs are just a subset of that. So implicitly contrasting open and non-open UIs is not necessarily very informative. Plenty of proprietary companies and proprietary design models create and implement lousy designs. Microsoft, of course, was historically the canonical example of this (though Office 2007 and Windows 7 are great strides in the right direction) but Android, which Tim picks a bit on, is perhaps an even better example- nothing about Android’s design and development process is open in any meaningful sense, and… the UI is pretty bad. So Tim’s post would have been much more useful as an analytical tool if he asked “why do most UIs suck?” and then concluded “lack of vision,” instead of asking “why do open UIs suck.”1
The second mistake Tim makes is the assumption that open projects can’t have strong, coherent vision- that “[t]he decentralized nature of open source development means that there’s always a bias toward feature bloat.” There is a long tradition of the benevolent but strong dictator who is willing to say no in open projects, and typically a strong correlation between that sort of leadership and technical success. (Linux without Linus would be Hurd.) It is true that historically these BDFLs have strong technology and implementation vision, but pretty poor UI design vision.2 There are a couple of reasons for this: hackers outnumber designers everywhere by a large number, not just in open source; hackers aren’t taught design principles in school; in the open source meritocracy, people who can implement almost always outrank people who can’t; and finally that many hackers just aren’t good at putting themselves in someone else’s shoes. But the fact that many BDFLs exist suggests that “open” doesn’t have to mean “no vision and leadership”- those can be compatible, just as “proprietary” and “essentially without vision or leadership” can also be compatible.
This isn’t to say that open development communities are going to suddenly become bastions of good design any time soon; they are more likely to be “bottom up” and therefore less vision-centered, for a number of reasons. Besides the problems I’ve already listed, there are also problems on the design side- several of the design texts I’ve read perpetuate an “us v. them” mentality about designers v. developers, and I’ve met several designers who buy deeply into that model. Anyone who is trained to believe that there must be antagonism between designers and developers won’t have the leadership skills to become a healthy BDFL; whereas they’ll be reasonably comfortable in a command-and-control traditional corporation (even if, as is often the case, salespeople and engineering in the end trump design.) There is also a platform competition problem- given that there is a (relatively) limited number of people who care about software design, and that those people exclusively use Macs, the application ecosystem around Macs is going to be better than other platforms (Linux, Android, Windows, etc.) because all the right people are already there. This is a very virtuous cycle for Apple, and a vicious one for most free platforms. But this isn’t really an open v. closed thing- this is a case of “one platform took a huge lead in usability and thereby attracted a critical mass of usability-oriented designers” rather than “open platforms can’t attract a critical mass of usability-oriented designers”. (Microsoft, RIM, and Palm are all proof points here- they had closed platforms whose applications mostly sucked.) Finally, of course, there isn’t just the problem of getting vision- there is the problem of execution. Manpower is always hard, especially when you can’t really fire people, but I think Firefox and GNOME (among other projects) have proven that you can motivate volunteers and companies to contribute to well-thought-out projects once a vision is articulated. It definitely isn’t easy, though!
Tim is not the first or the last person to say “open” when they mean “disorganized,” particularly in the context of UI. It is an easy mistake to make when, well, free software generally feels very rough compared to the alternatives. Free software communities that want to appeal to a broader set of people are going to have to do a better job of rising to the challenge of this problem, and create circumstances where designers not only feel welcome, but feel empowered to create a vision and feel supported in their implementation.
High on the list of things I really enjoy doing is thanking people who contribute to free software. Also high on the list is using software that works well.
So I just wanted to combine the two and say a public thanks to GP Halkes, for writing and maintaing dwdiff. I’ve been using dwdiff since early on in the MPL process, and thanks to two recent changes GP made at my request, it now works even better for my needs (and hopefully better for most people’s needs.) Thanks, GP!
I’ve been trying to get back to living my life in a task-centric manner, and Firefox Panorama, without necessarily being designed for those goals, is perfect for it. Someone else put the words in my mouth: when you’re trying to do task-centric computing, what you need is not just a place to dump tasks (a task organizer) but also a good task switcher. Virtual desktops (in either Linux or OSX) can be used to dump tasks, but they lack effective visual task switchers. Once you get used to Tab Candy, in contrast, it is an effective way to give you an overview of the tasks you’re handling and move between them in a quick, fairly non-distracting manner.
Unfortunately, it also drives me nuts, because it isn’t comprehensive. I’m very rarely using new desktop apps these days, but I’m still stuck with a lot of old ones (particularly until there is a competent, secure, self-hosted web-based word processor) and not being able to interact with them through panorama is driving me insane; it means switching back and forth between two different mental models on a regular basis, and that is painful. I’ve literally found myself trying to drag application windows into my Panorama desktop. That’s just not good, and I really hope someone uses the Panorama idea for a complete desktop soon.
(Note that despite the original name of tab candy, I don’t think ‘tabs’ is really the important thing here- the important thing is grouping data/applications together, and then having a good high-level overview of the groups when switching between them. That clicking on a collection-task brings up a ffox window with a bunch of tabs, rather than a desktop with a bunch of windows, is (I think) an implementation detail; I’d be happy with a similar organization for ‘traditional’ desktops without tabs as a starting place.)
Diaspora came to lunch at Mozilla today. Some notes.
Anyway, interesting stuff- I continue to wish them well.
You must be logged in to post a comment.