oh snapdragon

I’m late to this particular announcement, as I didn’t really have useful internet during the critical period last week, but that hasn’t dampened my enthusiasm one bit.

The Open Komodo/Snapdragon announcement is very exciting for me, and I suspect for many others in the Mozilla community. Having a basic, extensible IDE built on the same technology as Firefox (and therefore the web) will provide a great focal point for many of the IDE efforts that have been mooted around Mozilla technology over the years. People will be able to focus their energies on the specific tasks they wish to enable or improve, taking advantage of the incredible base that ActiveState has built.

I was lucky enough to be involved in the discussions and planning leading up to this announcement, and I think the most exciting thing about it wasn’t the prospect of the source release, though I am indeed eager to get that technology into the hands of the Mozilla developer community. The most exciting thing for me was seeing the depth of ActiveState’s commitment to the open web, and how enthused they are about helping to create a new open source community. This is a huge, huge investment in the open web by a small, small company, and I can’t wait to see where it’s going to take us — where we’re all going to take each other, in fact.

So thank you to Bart and Shane and David and Erin and all the others at ActiveState who had the vision and courage to make Open Komodo a reality, and to everyone who has already expressed their interest and support for the project. It’s going to be a blast.

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.

GDC

As vlad posted, some of us are at GDC this year. I really enjoy GDC, and every year dread that it’ll have jumped the shark. There’s a little more navel-gazing stuff this year than when I first started coming, but not an unhealthy amount IMO. (Coming from the Mozilla community as I do, I probably have a higher tolerance for that stuff than most.)

Someone asked me the other day “man, why do you go to GDC?” He was asking because he wanted me to do something this week, and my schedule is pretty constrained, but I thought it was worth talking about anyway.

I’m here because:

  1. I like a lot of different things about software, and there are lots of different software aspects represented here. Performance and concurrency. Graphics and art processing. Test automation and tools. Artificial intelligence and simulation. User interface and visualization. Networking and protocols. Design and team structure. Internationalization and modularity. Languages and APIs.
  2. Games are fun, and fun is important. People here spend a lot of time thinking about what makes things fun, how you can map that fun into software and have it reach people. Making tasks fun is a noble and wonderful goal, and software — being involved in so many parts of people’s lives, and being so fluid — is a great thing to be working on if you want to help there.
  3. There are a lot of people here who are dealing with things that touch real people. Sure, it’s “only entertainment” — though sometimes things are pretty serious — but the interaction can be powerful and the focus on the user can sometimes approach the intensity of our own.
  4. Even though there’s a lot of focus on the “triple-A” megatitles and their movie-scale budgets, a lot of interesting things are still being done by small teams, and I am a big fan of small teams. Big fan, I tell you.
  5. And at the other end of the scale, there are very interesting things being done with or by huge communities, interacting at various levels of cohesion and co-operation and competition and shared creation. The relevance to our Mozilla world here is obvious, I think, and I even think that the game world (creators and players alike) could learn some things from our experiences. Not to say that the could just copy what we do, or that we did everything right, but whether it’s a good example or a cautionary tale, they might pick up a trick or two.
  6. Over the last few years, the games industry has started to adopt and investigate techniques and tools to improve “software engineering” practices. Agile development, version control (!), test automation, design methodologies, usability analysis techniques, generation of content and tools and meta-languages and domain languages and tools and components and reuse and APIs and extensibility, whee. People fit those things into their own worlds, against the constraints of history and tradition and culture and budget and schedule, which is the case everywhere, but I’ve especially enjoyed watching the games industry grow into these things.
  7. Shiny! There’s some really plain-old-neato stuff here every year, pretty and fast and small and creative and awesome. (And some stuff that isn’t so neato, and since I just have to talk about things and not build them, I get to be sarcastic for my own entertainment.)

I learn a lot here every year, and come back to “real life” energized about software and fun and reaching people and trying new stuff and selling all my Mozilla stock to fund a game company. I’ll write more about the stuff I see here, and maybe summarize some talks, but I probably won’t syndicate it to Planet Mozilla so as to avoid the flooding effect.

the maturity of writing your own

Daniel Glazman has written about the pain he’s experienced trying to update his splinter NVu tree to track the significant Gecko development. It’s a very difficult task, and not one that I would have signed up for. There are a number of suggestions that others have made that might have made the task easier, but that’s for another post. To be perfectly frank, I have little personal interest in making the “maintain a fork of Gecko in another CVS repository” use case materially easier, let alone adding cost to already-difficult Gecko development to support it.

(I had a huge section here about the details of internals-vs-platform and some excellent responses that others have made to the post, but I just moved it to another draft because this post is about something else, dammit.)

What I really want to write about is this passage in Daniel’s latest post on the topic:

Let me first give you an example : suppose you are an experienced c++ coder but a true beginner in Mozilla, and you need to build a xul standalone front-end for an app of yours; you can’t rely on xulrunner yet, because it’s said to a bit immature for the time being. So you want to build a standalone toolkit-based app like Nvu, Firefox or Thunderbird… You start looking at mozilla/browser, mozilla/mail and then you cry. The makefiles are incredibly complex and almost not commented, most of the files in app directory are hard to understand so you don’t really know how to tweak them[...]

If you are a software developer faced with the choice between

  • a piece of software that is designed to solve your exact problem, which is not yet release-quality, but is already being used by other people for their projects in exactly this way; and
  • writing your own such piece of software on the basis of code you don’t understand, and which was never intended to be anything more general than “the startup code for Firefox”

then you might have some reasons to choose the latter, I suppose, but I can’t for the life of me understand how “maturity” is one of them. XULRunner is farther towards its stated goal — which happens to be completely identical to the goal that Daniel uses in his example — than anything you’ll find in the directories that Daniel lists, as evidenced by the fact that a number of people are already using it in service of that goal.

Even if XULRunner falls short of some subgoal today, investment in improving it to suit the needs of your own app is almost certainly the wiser course, as you reduce the need to maintain your own private fork of the firefox/thunderbird/whatever code — back in the early Mozilla days, we used to refer to this as “the stupid tax”, and talk about how it was often a strong disincentive to keep patches private instead of integrating well-designed hooks into the core app.