free as in smokescreen

The web is full of headlines today like this one from MacRumors: “MPEG LA Declares H.264 Standard Permanently Royalty-Free”. It would be great if they were accurate, but unfortunately they very much are not.

What MPEG-LA announced is that their current moratorium on charging fees for the transmission of H.264 content, previously extended through 2015 for uses that don’t charge users, is now permanent. You still have to pay for a license for H.264 if you want to make things that create it, consume it, or your business model for distributing it is direct rather than indirect.

What they’ve made permanently free is distribution of content that people have already licensed to encode, and will need a license to decode. This is similar to Nikon announcing that they will not charge you if you put your pictures up on Flickr, or HP promising that they will never charge you additionally if you photocopy something that you printed on a LaserJet. (Nikon and HP are used in the preceding examples without their consent, and to my knowledge have never tried anything as ridiculous as trying to set license terms on what people create with their products.)

H.264 has not become materially more free in the past days. The promise made by the MPEG-LA was already in force until 2015, has no effect on those consuming or producing H.264 content, and is predicated on the notion that they should be controlling mere copying of bits at all! Unfortunately, H.264 is no more suitable as a foundational technology for the open web than it was last year. Perhaps it will become such in the future — Mozilla would very much welcome a real royalty-free promise for H.264 — but only the MPEG-LA can make that happen.

briefly

(Is it really true that I only blog what’s too long to tweet now? Need to think about what that means, but I’m already not sure I like it.)

From John, emphasis mine:

The reason we have a vibrant, open web today is because of millions of little decisions and contributions made by thousands of people in that timeframe — people who work on browsers, people who build web sites & applications, people who evangelize for standards, people who use the web and ask/demand that it be better.

From CNET:

Other questions from the audience ranged from what computer science professors should be teaching to whether Internet Explorer would support HTML 5. Ozzie said he had nothing to announce on the latter front, but added, “It is our commitment to be a world class Web browser, what our competitors like to call a modern web browser. I think you can expect us to do the right thing.”

Very much looking forward to it.

on newgroupery

Much pixel has been spilt over our recent newsgroup reorganization and new hosting infrastructure. The high-order bit is here: we have better project communication and discussion now than we’ve had at any time in my recollection, and we all owe Gerv a genuine debt for pushing it through so many false starts and obstacles. (We also owe the others who have laboured to get the mail pieces talking to the news pieces, and the news pieces talking to the web pieces, and the web pieces able to talk at all, but if I had to pick one person to laud…)

A lower-order, but also important, bit is outlined by fantasai here, and I have been meaning for some time to post at length about my feelings on the matter.

This is not that post; I have to go to sleep a few hours ago, such that I can drive to Ottawa tomorrow. But I do want to at least outline my core beliefs on this topic, to partially assuage my guilt as much as to inform anyone usefully.

I believe these things:

  • We should prefer fewer groups to more groups, where all else is equal. All else is never equal, so that’s sort of a cheap belief, but traffic/spam/etc. problems should first be attacked with techniques and tools that don’t require us to split a community, and especially those that don’t leave people confused about where a given discussion should or will happen.
  • We should not separate people who use a technology (CSS, JavaScript, the DOM, etc.) in web pages from those who use them in Mozilla products or extensions. Doing so works against our interests in helping web authors and developers learn about our capabilities, “grow” (or develop interest) into extension and application developers, or inform our technology direction. We need to hear more of “you could do that with HTML, except…” when we’re thinking about adding some capability to XUL, for example.
  • Where scale permits, and where there is a reasonable path from consumer to producer for the enthusiastic, we should keep discussion of the development of a piece of our technology alongside discussion of the use of that technology. AJAX toolkits and their mailing lists provide a good example of the value of this, though it may well be that for many of our technologies — especially those that implement widely used, standard APIs — the scale of the consumer community makes that impractical. Even where that happens, we should see the separation as a necessary compromise and not a goal with inherent value; in these cases we should strive to subdivide the community as little as possible, and with an eye towards helping people mix with and learn from their “betters”.
  • Gecko “internals” discussion probably needs a group focused on those implementation details and design decisions, but it almost certainly does not need a set of such groups, each devoted to a different portion of layout (style, dom, parser, etc.).
  • I was one of the people involved in the re-re-organization, and I erred significantly in not raising my objections and making my demands in a more public forum. I have no defense here but the goodness of my intentions, and please rest assured that the bitter irony of a private discussion undertaken to improve the quality of our public communication is not lost on me.

With the exception of the last point, I could certainly be in error, but these are not beliefs that I have come casually to hold, and I genuinely believe that we will be better off if we are able to adhere to them.

(Dammit, this turned into that post. Ah well, I don’t need to be rested to drive!)

fertilizer

Mitchell posted earlier about my new focus: our developer ecosystem, and helping people produce great new tools and experiences on top of Firefox and the web both. It’s work that lets me combine technology, communication, and helping people solve their problems, and if I end up being even a fifth as good at it as I am excited about it — well, I’ll be really good, that’s what!

One important part of Mozilla’s support for developers in their work with Firefox and the web is the Mozilla Developer Centre Center, and I’ll be working with Deb and Eric to help MDC grow and thrive. In just over a year, MDC has developed a strong community of contributors and a great base of documentation, so I consider my job here to be helping Deb execute, and staying out of her way. (She is modest about it, and truly MDC is a fantastic example of the leverage that our community represents — and I include web developers in that community, very much — but Deb’s work to catalyze and guide and generally be MDC’s “guiding star” is not to be underestimated.) There are things to be fixed and problems to be solved, to be sure, and anyone who’s worked with me before knows that I can’t help but try to help when that’s the case, but the course we’re already on is very promising.

(As an aside of sorts, the recent newsgroup re-re-organization is a problem to which I owe a karmic debt, and I’ll post about that here and there this week, hopefully today.)

A bigger part of what I’m going to be working on, though, is what my favourite MBA calls “the extensions space” (my favourite trapeze artist would call it “the extensions piece”, I think). Working tirelessly, though again with an energetic and powerful community, Mike Morgan has been driving addons.mozilla.org through growing pains and scaling demands — popular stuff is hard! — and policy grey areas and likely some fire-breathing sharks or something too. He thinks deeply about the risks and hard decisions that we face as we try to make extensions — or, more broadly, a personalized web experience — attractive and appropriate for a broader portion of our users, and the users we don’t yet have. Working out a strategy for how to fit extensions into our product plans, how to help extension developers be even more productive and successful and happy, and how to maximally leverage the power of our platform, community, and brand to the benefit of the Web at large is an enormous and, I admit, somewhat daunting challenge. I look forward to drawing on my Mozilla knowledge, impeccable taste, and, especially, the experience and wisdom of people like morgamic to improve this part of our world materially. And I look forward to doing it very soon: while there are definitely long-term projects that deserve our attention, I’m starting to believe that there are some small (hopefully!) but significant changes that can make a positive change in the rather near future.

I’m trying to avoid letting “write a thorough and Frank-worthy post” be the enemy of “write a useful and, you know, posted post”, or something like that, so I think I’ll stop here. I want to thank everyone who has already sent me their (varied, and thought-provoking) thoughts on what’s good and bad today in with our world of extensions, and apologize pre-emptively for what will no doubt be rather tardy replies. I have a lot to absorb here, and nobody is bothering to ask easy questions.

echo reply

By now, everyone and their brother has reblogged Darin’s post about experimental support for <a ping>. And, as I think most people predicted, there was an outcry about privacy concerns, support for non-standard HTML extensions. Others have written lots about what the actual effect on the privacy landscape is (IMO, a slight improvement), so I won’t rehash that, and my feelings on the “divine right” of any one standards-for-a-living body to define the future of the web are pretty well-known among those who care, so you also won’t have to endure that.

What I‘m concerned about is that developers involved in this process were, in the words of at least one of them, “surprised” that there was controversy over implementation of this feature. I agree that, at least so far, the controversy seems to be based mostly on an incomplete understanding of how things are actually tracked on the web today. But there’s a difference between not thinking that the objections are valid and being surprised that people have a reaction to the proposal. The latter worries me a bit, because the emotional and social context in which we operate is pretty important to our success. We ignore that at our own peril, I think, though there would certainly also be peril in swaying with every wind. I guess this is why philosopher kings make the big bucks.

Also, somewhere between the initial bug filing, the trunk landing, the request that it go into the Firefox 2 branch, and Darin’s blog post, the original intent of this work seems to have become obscured, at least in our messaging: this is an experimental implementation to be used to gather feedback from implementors, web authors, users, and the rest of our huge world.

(Aside to the Slashdot submitter: when you link to a blog post that explicitly describes the feature and mentions that people might be nervous due to privacy fears, you might not want to say that it was “quietly” done. This was one of the louder landings for a change of its scale, IMO — which is as it should have been, also IMO.)