R0ml has been quoted by John Udell as saying that Open Source software can replace standardization. Many of the things I consider blogworthy are distillations of a position in an argument I've had with my father, but on this I think we are in violent agreement. Everybody loves a fight though, so I'll try to state this as antagonistically as possible - arguing against Mr. Udell's commentary. He raises three potential objections, asking if the idea is wrong in principle.

Objection: We don't write programs that way.

Who's "we", kimosabe? Speaking for groups that count me as a member, we do. Apparently some other people do too - David Wheeler claims that there are 30 million lines (more than $1 billion worth) in Red Hat Linux alone.

Objection: Our technology platforms are too balkanized to enable us to collaborate on common implementations.

Maybe Microsoft isn't going to start collaborating on Firefox, but who cares? If you follow the trends that W3Schools sets forth, IE's days are numbered anyway. Apple already uses an open-source browser engine.

Objection: Ditto for our political agendas.

This, I think, is the most telling objection. People who want to produce a good product for their customers will use open-source software and collaborate on its implementation, because that is quickly becoming the industry's best practice for producing high-quality software. People who instead have a strong political agenda, unrelated to the quality of their products, will develop standards bodies and waste their time re-implementing tons of code which is available elsewhere for free.

For an example of technology politicization, SQL is a "standardized" language, whereas PHP, Python, Perl, and Ruby are each open-source with a single implementation. Have you tried to write a whole program in SQL lately? Or even make a generated SQL statement run on more than one database at a time?

There are still some areas where standardization is important - the web comes immediately to mind - but that is only because it is a platform still nominally controlled by entrenched proprietary interests. Imagine, for example, Microsoft were to give up IE tomorrow, and suddenly declare that they were simply packaging Firefox with Vista. What would the point of the W3C be at that point? To broker discussions between Firefox - with 99% market share - and Safari and Opera? It's unlikely. Safari, being open-source itself, can crib freely from Firefox's code where necessary, and Opera is already an also-ran, copying from behavior of the major browsers more than implementing an abstract standard.

While not quite as bad as SQL (it is possible to make pages which render in both Firefox and IE, at least), anyone who has done browser-portability work will tell you that standards aren't all they're cracked up to be in this arena either. On a daily basis I wish that Firefox were the only implementation I had to contend with.

There are more examples of this trend. There is a PNG standard but even Microsoft just uses libpng. Mozilla maintains what I think is the most exhaustive description of the failure of the C++ standardization process - I think it would be hard to argue that things wouldn't be better if the "standard" were in the hands of the GCC team. Jython and JRuby both elegantly prove that you can have implementations that bridge language gaps without a formal standard.

It's not that open source can replace "open" standards and the standardization process. Open source has replaced standardization. We've just been waiting for the world to catch on.

The week before last I took a trip to Austin, Texas. This was unfortunately in lieu of both PyCon 2006 and ETech 2006 since we couldn't get the whole Divmod team to either of those events. Sorry, disappointed conference-goers! We'll make it next year for sure.

It was a half-vacation half-bizdev trip. It was really good to get a break from the day-to-day minutia of everything that needs to be done on Divmod's infrastructure, and take a look at the view from a thousand feet up, and think more about how awesome our team and technology are. Luckily we are pretty awesome so it was a good boost to my energy level to focus on that for a while.

The ostensible purpose for this trip was to cement some kind of formal working relationship between Divmod and Roxor Games. On that front I think things went spectacularly. We had a series of meetings that lasted all week long, and were, I think, a credit to the very concept of a "meeting". I had hoped that this post would be longer, but looking back over the week, it seems that most of the details of those meetings involved deals that aren't final yet and are technically secret. I'm kind of out of practice at keeping secrets, having been on the open-source circuit for so long, but even I am pretty clear that putting things on a syndicated blog that gets tens of thousands of hits per post is not exactly in the spirit of an NDA.

If you know me, or you know J---- (the malign overlord of Roxor), you can probably guess at least part of what's going on. Don't spoil it for everyone, please! If you, for example, posted "Oh snap are you guys making a [REDACTED] for the [REDACTED] market???" in the comments here, I think I might be violating confidentiality agreements by proxy. If you're not one of the folks In The Know, I will give you one hint: Divmod's technology has certain applications outside of email.

To give you some of the flavor of the week, though, here is a cell-phone snapshot of the one formal presentation I gave while I was out there. For a "projector", I used a prototype of an racing arcade machine Roxor will be releasing soon.

It was also surreal, not to mention a ton of fun, to get a whirlwind tour of the gaming industry rumor mill, not having been involved for a while myself. At various points throughout the week I found myself, a visitor from two thousand miles away, relaying messages between folks who are within a stone's throw of each other. Thank you to everyone who had a great story for me.

Most of all it was fantastic to get to visit a bunch of old friends. Shout outs to my homies: thanks for making time for me! Thank you Allen for driving me around town for a week. Thanks also to Jason, John, Al, Travis, Brian, Jason[2], Matt, Melanie, Seneca, Dave, Damion, and Sean. To those of you who I missed - especially Andy, Skiv, Adam, and Spencer, and of course anyone who I forgot to list - sorry about that. I'll be down again sometime soon, drop me a line at glyph@divmod.com and I'll make sure to meet up with you next time.

One is forthcoming, but this has been a crazy week for me. There was a lot to do upon my return from Austin, and I have been sick for the last 2 days.  I do have quite a bit of backlogged posting to do here; I should have at least one up over the weekend.

I didn't get to go to PyCon this year. I'm just now back from Austin, where I was discussing secret plans. More on that soon.

However, before I forget, I'd just like to thank Ted Leung for specifically mentioning Divmod's absence in his PyCon wrap-up. It's good to be missed. We missed interacting with the PyCon crowd this year too - and of course, specifically the Chandler team ;-).

(PS, it's "Divmod", not "DivMod" - although Ted is hardly the only person I've seen make this mistake. I have a feeling it's fated to be a common one, like the way some people say "PC or MAC" as if "MAC" were an acronym for Macintosh Apple Computer or something.)

F9 is the default keybinding for "run the unit tests for the current file" when using the Twisted Emacs bindings.

As her Windows/Divmod tutorial indicates, Ying is getting started with coding using Twisted again. This is the third time that she's gotten started with it - tries #1 and #2 involved Woven and Nevow, respectively. I was cringing as she started to get her development environment set up, because those previous attempts were shockingly painful. Every step of the way was a challenge - version skew. Path problems. Obscure deprecation warnings. Un-debuggable template interactions. Undocumented assumptions. DOCTYPE declarations.

This time she's got a bit more of a domain-model problem to attack. It was staggering to me how different it was. While getting started with a web-based development project with Twisted was painful, and it wasn't necessarily clear how to proceed, getting started with a domain model was trivial. With a 4-line unit test template, she was productive within 5 minutes. Of course, having yours truly in the room (and emotionally dependent upon you) when you start to work on a Twisted program helps, but I have been largely uninvolved - as opposed to previous attempts where she would ask a question every 5 minutes and I would start the answer with, "You have to understand the history of the multiple projects involved here..." or "There are some unresolved issues...", now she asks a question once per day or so, and the answers are short, direct sentences like "use twisted.web.client.getPage" or "return a Deferred from your test method".

I have long despaired of Twisted development being easy to newcomers, and the community (both friendly and hostile to Twisted) reinforces this assumption. "Asynchronous programming is too hard", "learning Twisted is a serious investment of time", "there's so much you have to know to get started", etc. However, I've now seen that it can be easy. We just need more tutorials that blitz through the introductory steps on a particular platform without explaining anything, and get straight to coding something.

For example, if I had written the tutorial that Ying posted to her blog, I probably would have explained each step, so as to give users maximal flexibility in their setup. "Make a folder to hold your projects. We'll call this the 'combinator container' folder from now on. You can place this anywhere on your sys.path. Now, make a folder /path/to/combinator-container/Divmod ..." Ying chose a much more direct route. Nobody really cares what the folder is named, they just want things to work. "Make a folder C:\Projects. Now make a folder inside that called Divmod. Then run 'svn co ...'"

Once you have gotten to the point where you are hitting F9 every five minutes, watching your code run, and fixing problems, you don't really care that you don't know how to put C:\Projects at H:\Documents and Settings\%USER%\My Documents\Programming\MyNiftyProject\Infrastructure. You don't care that you had to run svn command lines rather than installers. You certainly don't care why version 0.9.8a of OpenSSL is required or where ZopeInterface was installed.

That last step - where you just push a button, rather than starting up a terminal and typing a command line - is an important one. It makes the experience feel complete, and it removes a point in the development process (that happens every 5 minutes or so) where a new Twisted user thinks, "this is a pain in the ass, these tools are terrible".

twisted-dev.el is the best-kept secret of Twisted developers. It needs to be more front-and-center. We should eschew the bits that never really worked, and are no longer maintained, i.e. the PB/Emacs integration, and include the core one-button-unit-test functionality with Twisted itself.