Older blog entries for louie (starting at number 660)

A note on 2011

The best thing I did for myself in 2011 was to get back on a bicycle after not being on one for 15+ years, and after never actually being comfortable on one. I’m not going to be racing any time soon, but I now really look forward to a bike ride as part of the average weekend and even the average vacation.

image

Yesterday was a nice punctuation mark to that, featuring a long ride down to the ocean, a great view, and a very satisfying fish and chips.

I am definitely enjoying some time out of the office and looking forward to a great 2012- hope my friends are too. Now I just need to figure out what life improvement can trump “get back on a bike.” Suggestions welcome :)

Syndicated 2011-12-29 18:31:55 from Luis Villa » Blog Posts

San Francisco Recommended Reading

When I moved into San Francisco, I asked some folks about books I should read to get a sense of the history of the city. Here’s a sampling of the books that I’ve read since then, gathered in one place for the next time someone asks me the question. I’m still open to more suggestions, and suggestions need not be about the city as a whole- for example, my favorite book about New York was in large part about traffic and my favorite book about Boston was about the river.

Actually publishing this post, moons after writing it, is mostly in honor of today’s spectacular weather and my first ever bike ride across the Golden Gate. (And yes, the photo is cliched and I don’t care ;)

Imperial San Francisco: Urban Power, Earthly Ruin: Gray Brechin: This book opens with a slightly bizarre conspiracy theory about the role of mining in history, and keeps going with a lot of implied “the rich are trying to keep us down” without much evidence. Not that the folks he’s chronicling are particularly nice folks, but that’s easy enough to prove without going off the deep end about it. Despite this unfortunate tendency, this book has lots of great stories and background about how the San Francisco power brokers of the late 19th century interrelated with the city, the state, and the rest of the country, including some great background on the history of water and mining in the region. Recommended reading for someone trying to get a grasp on the early history of SF, albeit to be taken with a side order of salt.

Golden Gate: The Life and Times of America’s Greatest Bridge, Kevin Starr: Starr is a great historian (his more serious California history books are terrific), and this book has a lot of great stories. Unfortunately, it also has a lot of filler to make it “book length.” (In the future, books like this will be about 1/2 the length and sold purely as ebooks.) I recommend it, if you’re interested in the bridge and have time to wade through some fairly purple and extraneous prose. If you’re just looking for any one particular book about the city, this one isn’t it.

Making San Francisco American: Cultural Frontiers in the Urban West, 1846-1906, Barbara Berglund: This started as a PhD thesis, and reads like one. But if you’re the kind of person who can plunge through that (and I am), it’s a brilliant book, explaining how the racially mixed and roughly egalitarian culture of mining-era SF was gradually molded into something acceptable to “cultured” Americans – both to the nouveau riche of the West who wanted to build a city acceptable to the East, and to those from the East who were flooding into SF. Really fascinating read, and I think has some lessons applicable to the “uncultured” programmers who have to constantly resist cultural change imposed by more “refined” outsiders- still an ongoing theme in SF.

The Barbary Plague: The Black Death in Victorian San Francisco by Marilyn Chase: This book explores the history of the entry of the bubonic plague into the Americas via San Francisco. It’s a lighter and more thematically consistent book than Making San Francisco American, but covers overlapping time periods and explores some similar themes, like early anti-Chinese racism, and the relationship of early San Francisco with the Eastern US. If you’re looking for something less serious, and not at all about software, this is definitely the one book in this list to read.

Vanished Waters: A History of San Francisco’s Mission Bay, Nancy Olmsted: I live on land reclaimed from Mission Bay, so this has resonance for me that it probably won’t for others. But I think it’s a brilliant, brief book that anyone who lives near modern Caltrain should benefit from reading, since it will help you understand the geography and history of your own neighborhood.

What the Dormouse Said: How the Sixties Counterculture Shaped the Personal Computer, by John Markoff; and Regional Advantage: Culture and Competition in Silicon Valley and Route 128, AnnaLee Saxenian: I think of these as a pair, because while very different books they are also both about the culture of computing innovation and networking in the Valley. Dormouse is really very anecdotal (a little birdie once told me that even the author admits it was basically an excuse to string together a bunch of great stories he’d heard over the years), but they are great anecdotes and give a lot to chew over, especially in light of the success of the iPhone and iPad after the writing of the book, and the continued tension between personalized and centralized computing. Regional Advantage is an even older book, but critical to understanding the larger, structural causes of Silicon Valley’s success, showing that it was increased interpersonal and intercorporate sharing that made Silicon Valley continue to succeed after the shocks of the ’80s hammered both Silicon Valley and Boston’s Route 128.

Reclaiming San Francisco: Brook, Carlsson, and Peters: Not actually read yet, but am excited to find time for it. It’s a series of essays.

Syndicated 2011-09-19 02:21:11 from Luis Villa » Blog Posts

Making HTML Legal Documents (Like MPL) Look Good

A few months ago I bought “Typography for Lawyers” (TFL), an excellent book that I would recommend to all lawyers. And since the biggest document I was working on at the timeis, of course, published in HTML, I started spending a few minutes here and there on learning enough CSS to make the license look better. (Understandably, the book’s very pragmatic advice is focused on Word and Pages, not HTML.)

Fine Print Fine Print by CJ Sorg, used under CC-BY 2.0

I’ve published the experiment (Compare with the plain-jane HTML MPL 1.1). This is just an experiment and a personal hack, but I’m happy to hear more suggestions and improvements, and if the final result works, I’ll suggest we use it instead of the traditional plain HTML version. Some notes on the process, including links to the (abbreviated) blog posts at the TFL website (for much more thought and detail, buy the book):

  • Fonts: This was hard. The author of Typography for Lawyers is himself a former font designer, and (correctly, I think) a font snob. Given that I was not going to splurge for fancy webfonts just for this project, I spent a lot of time browsing and playing with Google Web Fonts. This is clearly not ideal (for example, it has only one monospace option for Exhibits A and B, and I’d like a slightly more subtle serif for the titles) but I think I found a decent combination of fonts – or at least an improvement on the system fonts. Presumably, if this became Official, some better font choices could be used.
  • Small Caps: I’d never given small caps much thought until reading TFL. The book is quite positive on them under certain circumstances, and that led me to experiment and eventually to use them as headers. Unfortunately, Google Web Fonts is limited here – none of the Google Web Fonts appear to have true small caps. TFL recommends strongly against fake smallcaps, but I think these look decent so I’ve used them; I’d be happy to replace with a better one if that was available.
  • Hyphenation and Justification: TFL does not necessarily recommend full justification, but demands hyphenation if you do fully justify. Since Mozilla just added support for hyphenation, I turned on hyphenation and justification, and I think it looks good (if you’re using a recent build.) In production, it would probably be better to either use something like hyphenator that works cross-browser, or use some sort of browser feature detection to turn off justification for browsers that don’t also support hyphenation.
  • Line length: TFL recommends something between 45 and 90 characters per line. (The Supreme Court’s well-designed documents are about 65 characters per line.) Unfortunately, as best as this CSS newbie can tell, there is no good way to do this simply in CSS. I ended up with a total hack, using the “alphabet trick” described in  TFL to estimate the right width.
  • ALL CAPS: TFL IS AGAINST ALL CAPS FOR ENTIRE PARAGRAPHS. My experimental HTML version uses some gross CSS to create a highlighting box around the two traditionally all-caps blocks in the text.
  • “smart” quotes: We know that people copy and paste from the HTML version of the license into plain text files, even though (with MPL 2) we’re going to provide a very nicely formatted plain text version of the license. And of course, copying and pasting curly quotes into plain text gets… messy. And so, I am conflicted about this. The HTML linked above uses smart quotes, while the plain text uses straight quotes. Inevitably that will lead to some problems; suggestions on how best to fix (use javascript to modify what is copy-and-pasted if someone does that?) are welcome.

Of course, I’m still very bad with CSS and HTML, so I’m sure this document can be improved, and I’m happy to take suggestions and fixes. Regardless, it has been an educational experience for me and I’m glad I toyed with it.

Syndicated 2011-08-22 14:02:01 from Luis Villa » Blog Posts

Donated to the Ada Initiative

I’m excited to say that (with Krissa’s support and approval) I donated today to the Ada Initiative’s Seed 100 Campaign.

The Ada Initiative Seed 100 campaign: donate in June to support women in open technology and cultureFree and open software and culture have been very good to me, and I’m glad that the Mary and Val (and hopefully soon a fleet of others) will be working to make it more accessible to women and girls. As big a force for change as this movement has been in the past two decades, things can only improve when we consciously work on being accessible to the 50% of the population that is currently all too often excluded.

Syndicated 2011-06-23 02:33:45 from Luis Villa » Blog Posts

Regular internet detox tips?

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.

Small waterfall on the side of a trail off Skyline Drive, Virginia, May 2011

 

 

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.

Syndicated 2011-05-13 19:28:29 from Luis Villa » Blog Posts

looking for a programming analogy- if there is one

As I’ve mentioned before, there are a lot of analogies between programming and legal work.

I’m working on an upcoming post to explain a specific application of a legal concept. Unfortunately, I think this is one of those few concepts where there is not a ready programming analogy. I’d love for someone to prove me wrong, since the programming side of my brain is slowly going to pot. Here goes:

In law, there is the concept of “rules” and “standards.” Basically, rules are precise- they allow a judge to simply look at the facts, apply the rule, and voila- you know whether the rule was violated. An example would be “The speed limit is 55.” If you’re driving 56, you’re in violation- even if, say, you’re speeding to the hospital with your pregnant wife. Alternately, if you’re driving 54 you’re fine- even if it is pouring rain. Rules are good because they are easy for the public to understand (no need to consult with a lawyer) and because their application (should be) very evenhanded, but good, fair rules are very hard (in many cases essentially impossible) to write.

A standard, on the other hand, is more vague- something like “The speed limit is whatever speed is safe to drive at under the circumstances.” This might not allow you to go 56 to the hospital, but would definitely not allow 54 in the rain. These are bad in some ways because they are trickier, case-by-case, hard to predict the outcome of beforehand, and involves judgment on the part of all parties, but (arguably) produces better outcomes a lot of the time- assuming you can trust the parties doing the judging, and you can put up with the cost of taking the time to make the decision.

So… for those of you who have lasted this long: are there analogies to this in software? The closest thing I can think of is strong typing vs. weak typing, but generally, since computers are incapable of dealing with standards, there aren’t many examples I can think of. Am I missing/forgetting something?

Syndicated 2011-04-17 16:43:47 from Luis Villa » Blog Posts

Brilliant.

Saw this for the first time on my drive to work yesterday:

Not every venture is about capital, by Fligtar, used under CC-BY-NC-SA

Congrats to all my friends on a very solid release and on reinvigorating their important message of public service.

Syndicated 2011-04-01 14:57:57 from Luis Villa » Blog Posts

MPL Beta 2- as FAQ

I’m still working, albeit sometimes slowly, on the new MPL. Two days ago we announced the release of Beta 2- you should go read it :)

FAQ, by photosteve101/planetofsuccess.com, used under CC-BY

Besides the usual (small tweaks to some language in a further attempt to get it Just Right; improvements to the GPL language; etc.) I also published a bit of an experiment: a draft of the license which replaces the traditional section headers with FAQ questions, like so:

Traditional:

2.2. Grants.

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: . . .

FAQ-style:

2. What rights are granted to me by this license? Who are these rights granted by?

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: . . .

The inspiration for this came from the apartment lease I signed in December, which was done in this style and (oddly) almost a pleasure to read.

This approach has two advantages. First, it helps you draft and organize things more clearly. Since every paragraph was the answer to a question, things were broken up into what normal human beings would consider more logical units, instead of the giant blocks of text legal documents sometimes sprawl into.  Preparing the FAQified version of Beta 2 made us aware of some MPL sections that had this problem, and it helped us reorder and reorganize text as a result- something which you can see in (for example) the new Section 8 of MPL 2 Beta 2, which is part of the old Section 9 broken out so that it makes more sense independently. Because of this, these changes will help every reader of the license, even if we never publish another “FAQified” version.

Second, the questions clue a reader in to the key concepts of a section. It is important that people still read everything. We’ve tried to ensure that the questions do not change the meaning of the “answers;” i.e., the body of the text, both by ensuring that the “answer” or body text is the same between both versions and by disclaiming any changes in the license itself. In other words, this will help non-lawyers understand- but if for some reason, you need to be absolutely sure, you (and possibly your lawyer) need to read the whole thing carefully and without reference to the questions.

We’re looking forward to feedback on this, both from non-lawyers (does this help you understand?) and from lawyers (this is an unusual technique, and so suggestions on how to do it better are welcome). So download it, read it, and let us know what you think.

[postscript: The first comment reminds me that this is only one of the steps we've taken to simplify and clarify the license. Most notably, Beta 2 is almost exactly 1/2 the length of  MPL 1.1, but we've also worked with Mozilla folks to simplify requirements where the old license was over-specific, and with lawyers with a reputation for good writing on how to simplify language and remove redundancy. But there is still time to make it even better, so please continue reading and giving feedback!]

Syndicated 2011-03-31 13:42:17 from Luis Villa » Blog Posts

Joining W3C PSIG as an Invited Expert

Just a note to say that I’ve been invited to join the W3C‘s Patents and Standards Interest Group as an Invited Expert. I’m pretty pleased by this and am looking forward to contributing immediately. Invited Experts speak for themselves, not other organizations, so I will not be representing Mozilla or anyone else, but hopefully I’ll be able to add something to the discussion on my own and help move W3C and the open web forward.

Syndicated 2011-03-25 04:31:13 from Luis Villa » Blog Posts

Other Ways to Slice Revenue Pies

A large company with a distribution network, and a little guy with something nifty to distribute walk into a bar…



Step 18 / Rex Roof / CC BY 2.0

[NB: Nothing here is legal advice; just business advice. I do not represent either the GNOME Foundation or Canonical, and have not talked to either one of them about this, though I have had a brief email exchange with the Banshee guys.]

There are a lot of ways to figure out how to slice revenue pies, but you wouldn’t know it from watching people talk about Banshee and Canonical. The options discussed seem to be all, nothing, or some percentage in between. This post will discuss one alternative, and hopefully provide food for thought when people are making their own revenue arrangements.

We can start by taking a step back and looking at factors besides labor and power, which seems to be what lots of folks have tried to boil this particular situation down to. Each situation has unique issues, but two which I’ll talk about here are what the money involved means to the various parties, and where else value is being created.

On “what the money means”: sometimes money is just money. But more frequently money has different meanings to different groups, depending on how big they are, where they are in life (as a person or organization), etc. So $10K may mean very little to a big company, but it might mean the difference between college and no college for an individual coder, or between an event and no event for a small non-profit. On the flipside, the difference between $1M and $2M might not mean much to an individual (diminishing marginal utility ahoy!) but it might mean the difference between growth and layoffs for a small-to-medium company. I can’t speak with any certainty here, but my guess is that $10K can easily be a big deal (like a hackfest) for GNOME, and … well, I really hope for their sake that $10K doesn’t make much difference to Canonical :) On the flip side, $1M might be more money than GNOME is ready to handle, while $1M would likely be a significant help to Canonical as it seeks to become a stable, sustainable business.

On “where the value is being created”: This is not a simple question. But when you’re talking about people who distribute a good, it is usually fair to consider not just what they are doing to distribute the good (which might be minimal, particularly if the good is digital) but what they’ve done to build their distribution network and make it popular with consumers (which might represent a lot of work.) At the same time, creators haven’t just created something- they’ve also passed up other opportunities and taken risks to do whatever it is they do. By that token, it is safe to say that without the Banshee team there would be no Banshee to distribute. No one has anything if they didn’t do that work. At the same time, Ubuntu multiplies the value they did create by working to increase the number of people who use desktop Linux- and therefore who can use Banshee. So both of them have created some value here- maybe that balance isn’t 75-25, but it isn’t 100-0 like some folks seem to be suggesting either.1

So how do these factors affect the deal itself? The critical point to take away from the examples above is that one number doesn’t fit all- what might be the right percentage for the first dollar might not be the right percentage  of the millionth dollar. A sliding scale for revenue sharing can address this by giving one party a lot of the early, smaller revenue, and the other party a lot of the later, larger revenue. In this example, you could set it up so that of the first ____ dollars, Banshee/GNOME gets the (vast?) majority; they split the next ____,  and then anything past that- the big bucks that result at least in part from Ubuntu’s big audience- Canonical gets the lion’s share.

Take your pick for the exact numbers, of course- the point being that this more flexible framework, instead of a straight 25-75 split, might leave all parties with a better chance of meeting their goals. While the money is small, GNOME gets what to it is important revenue, while Canonical loses out, but only on (probably) pocket change. If the money involved ends up being really large, GNOME still benefits a lot (having gotten a large share of the early money), but Canonical gets a revenue stream that will help it build a sustainable business. This kind of split also better reflects where value is being created- the Banshee guys get lots of immediate revenue for having created great software, and (if a huge number of people use it to buy music) then Ubuntu gets value for having done the hard work to make the platform as a whole accessible to those huge numbers of people.

Again, I haven’t really talked to the parties involved, so take this with a grain of salt- it might not fit this example, and it almost certainly won’t fit your situation without more thinking, tweaking, and perhaps use of a different tool for splitting revenue. But as more FOSS projects and the companies that deal with them start to have these sorts of revenue streams, it will be increasingly important to get creative about how to distribute that money. I hope this post can help remind people to think beyond a simplistic X/Y split, because being creative about this sort of thing can help everyone build sustainable models that help finance good software for more people.

  1. If you don’t like this, I suggest channeling your energy into writing a true cross-distro Linux build and installation process.

Syndicated 2011-02-28 06:25:41 from Luis Villa » Blog Posts

651 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!