Older blog entries for louie (starting at number 651)

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

Changing Jobs

Today was my last day as an employee of the Mozilla Corporation. I’m leaving to work at the law firm of Greenberg, Traurig. This was not an easy decision for me to make, but I’m pretty sure that it is the right one, both for me and for Mozilla.

Why?

Mozilla has been terrific for me. Working with happy, dedicated, passionate people is always a joy, and I’ve learned a ton from my teammates in legal and from Mitchell. I particularly can’t say enough good things about my boss, Harvey- he’s been a tremendous mentor to me. And of course Mozilla is exactly the kind of job I went to law school to get- directly helping hackers ship world-class software. Leaving today was hard- I’ll miss my coworkers, and I realized over the past few days that some of them may even miss me ;)

So why am I leaving? It’s because I want to continue to improve as a lawyer, and for a variety of reasons, the time-tested route for that is through a law firm. I’ve been learning a lot at Mozilla, but I will have even more opportunities to gain experience and improve my skills at Greenberg. Eventually, this will make me a better lawyer for any client I will have in the future.

What does this mean for the MPL?

We will still ship the new MPL in a reasonably short time frame, for two reasons. First, we’re almost done- go check out the beta, and/or read lwn’s solid article on the process. Second, our primary outside counsel on the project (Heather Meeker) will be my new boss at Greenberg. Both Heather and I are deeply invested in the new MPL, and we want to see it done (and done right!). So we will continue to work with Harvey and Mitchell to complete the new license, and my new address won’t change our focus or the license’s priorities.

What does this mean for this blog?

The blog has been quiet-ish in the past year, and will likely remain so, with more of a focus on personal life and technical questions than legal questions. This isn’t because Greenberg has put any pressure on me, but because I expect to have less time to write, and because some of the lawyerly virtues I’m working on are discretion and brevity… neither of which work together too well with the blog :) But hopefully I’ll still have interesting things to say from time to time.

Contacting Me

As usual, if you’ve got any questions – particularly about the MPL – let me know. My new email address will be [click here]@gtlaw.com, and my personal email address ([click here]@tieguy.org) will continue to work too.

Syndicated 2011-01-07 04:01:00 from Luis Villa » Blog Posts

offline no-keyboard rss reader?

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.

Options I’m looking at right now:

  • wifi-only ipad + reeder: $499+$5. Biggest downside: Apple. Also size: not sure that my intended use case will really work well with the weight of the iPad.
  • Samsung Galaxy Tab + google reader app: $599 + free. Downsides: $100 more than ipad + 3″ less screen + OS everyone admits is not ready for tablets. Will make me less likely to buy an actually good 2nd gen Android tablet. Upside: Google Reader app looks solid; Android is (relatively) the Good Guys in this OS battle.
  • nook ($149/$249) or kindle ($139): would be ideal-ish (less weight, more readability), except I don’t see any great rss reading options. Any suggestions on that?

Are there other options I’m missing? Less popular/more hackable e-reader devices? Other tools?

Some things that aren’t options:

  • phone: I read a lot on my phone already, I don’t want to add to that and screw up my eyes even more.
  • instapaper -> (kindle|ipad): instapaper is slick, but to go through a lot of feeds quickly, not a handful of lovingly pre-selected content slowly.

Thanks in advance, oh broad intarwebs…

Syndicated 2010-12-08 04:59:39 from Luis Villa » Blog Posts

do “open UIs suck”? or do “UIs without vision suck”?

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.

  1. Tim doesn’t help his analytical problem here by not defining what he means by “open UIs”; given that he uses Droid as an example, what he is discussing are “source-available UIs” but given this tweet what he may mean to discuss is “UIs designed from the bottom up”, which are, I believe, a related but analytically distinct thing.
  2. The best current example I can think of as a design BDFL is Jon McCann in the context of gnome-shell.

Syndicated 2010-11-16 05:32:57 from Luis Villa » Blog Posts

Wikipedia hiring for Bugmaster! (only 24 hours left!)

Because I know a fair number of QA-oriented people (for some reason) still read this blog, I thought it might be worth pointing out that you still have 24 hours to apply for the bugmaster position at Wikipedia. Sounds like a cool gig for the right person, in a growing organization.

Syndicated 2010-10-21 23:05:52 from Luis Villa » Blog Posts

reading recommendation on American political multilingualism?

I’m trying to find a book on the political history of multilingualism in the US; in other words, of why/when it started becoming acceptable (and in some cases required) for government works, electoral ballots, etc., to be written and printed in multiple languages. This is related to some of the talk about mozilla-as-social-movement that a variety of Mozilla folks have been talking and blogging about lately; I’m curious if some of the rationales and arguments used by supporters of multilingualism would be applicable to software. Anyone have any pointers? Thanks!

Syndicated 2010-09-07 04:13:57 from Luis Villa » Blog Posts

publicly thanking dwdiff

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!

Syndicated 2010-08-25 18:21:04 from Luis Villa » Blog Posts

Why I love (and hate) Panorama

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.)

Syndicated 2010-08-25 05:03:36 from Luis Villa » Blog Posts

Notes on Diaspora Talk

Diaspora came to lunch at Mozilla today. Some notes.

  • They gave me a nice shoutout. ;)
  • They’re doing pair-programming and test-driven development this summer, which I think is great. Sounds like they’re getting some great guidance from Pivotal Labs.
  • Very explicitly trying to focus on things everyone can use, rather than something for geeks.
  • Are trying to do micro-networks, rather than ‘everyone on the same plane’; I’m curious to see where that goes.
  • They’ll have single-user ‘seeds’ or multi-user ‘pods’ for servers. Push-driven, like email.
  • They’re doing Rails and Mongo, and even Websockets; they’re having problems between Websockets and Rails.
  • Planning on doing a code release by ‘flipping the github bit’ on September 15th, but will continue hacking after that, since they have a ‘low burn rate.’
  • Seem a bit worried about the community management problem once they go live.
  • Have a slide describing feature set for beta; focus on easy group management for you and close friends; private broadcasting to those friends; full data exportability.
  • Longer term: work with ostatus/other stuff to work closely with other distributed technologies; plugin and application infrastructure; build community and focus on design.
  • Anonymity is not currently a design goal, but still thinking about basic crypto and heavy focus on privacy (including privacy expectations-setting.)
  • In the move to california, they appear to have abandoned arepas for tacos. Bad news.
  • I admit I’m troubled that there is lots of talk about technology, and not much talk about UI/HCI/design, but in response to my question they say they mostly didn’t talk about it because it is still very much in flux. They’re talking with others about the problem, which is good to hear.

Anyway, interesting stuff- I continue to wish them well.

Syndicated 2010-08-20 20:24:10 from Luis Villa » Blog Posts

A must-read on google

In the same vein as my earlier commentaries on Google comes this piece by James Grimmelman. He doesn’t comment on the actual substance of the net neutrality announcement. Instead he focuses on process, and his description of how google does things seem so dead on to me into how google that I think I’ll be citing repeatedly in the future. I won’t quote; it is worth reading the whole, fairly brief thing.

The one thing I’d add to what James says is that Google’s process actually usually works quite well; for every Wave, Buzz, and verizon deal, there are several things that work well. When it works poorly, we should generally allow the market to discipline them, as it has with Wave. The reason the net neutrality issue is so important is that it could represent a new barrier to entry, making those market mechanisms less effective and leaving us more at google’s mercy when their processes go bad in the way James describes.

Syndicated 2010-08-12 19:26:27 from Luis Villa » Blog Posts

642 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!