Overall, I think that OSBridge more effectively captured the spirit of the community from which it springs. The lack of the usual sponsored keynotes, expo hall stuffed with vendors, and “big shot” community leaders made the software itself, and the community building it, the main attraction. OSCON, by contrast, is much more focused on products in the OSS space, and talks are often a sales presentation wrapped in a technical overview.

On the downside, the quality of talks at OSBridge was highly variable. With fewer proposals to choose from, it was inevitable that some weaker or less-experienced speakers would end up on the program. (Hell, they even let me speak.) OSCON attracts a pretty stellar level of presentation, with rare exceptions (again, yours truly) and has an air of legitimacy that helps convince employers and sponsors to support the event.

I also don’t think that the commercial focus of OSCON is inherently a bad thing. I for one am happy to get paid to work with and on open source software, and I don’t begrudge those attempting to derive their livelihood entirely from it a few minutes to pitch their wares. If anything, I think the Portland tech community should be more focused on commercializing their projects, the better to sustain and improve the pool of talented developers who choose to live and work here.

Unfortunately, OSCON has two critical flaws. First and foremost, it’s too expensive. While the catered lunches, free coffee, and after-hours parties are all lovely in their own right, the total cost of the conference (around $1200 for the normal sessions only, and closer to $1800 with a full set of tutorials, plus airfare and lodging) puts it out of reach for many developers who simply want to get together and hack and share tips with their peers.

Secondly, many of the “keynote” presentations are simply apologia from proprietary OS and platform vendors, and really shouldn’t have a place in a conference focused on open source. I don’t mind hearing a pitch from a talented speaker, but market-speak-centric presentations on “cloud computing” and “open standards” are anathema to the DIY spirit of a true hacker’s conference.

Sadly, addressing both of these issues concurrently is a serious challenge, as I can only presume that Microsoft, et. al., paid handsomely for the opportunity to present themselves. Other events manage to keep costs down, however, so I assume there’s some room for cost savings that wouldn’t require moving the event to a spare O’Reilly warehouse and catering it entirely with Folger’s coffee and stale PB&J sandwiches.

Personally, I find I have more fun (and often learn more) at smaller, more focused events like JSConf, Ruby Future, DjangoCon. Emerging Languages Camp was another perfect example of this — by stripping down the focus of the event, the organizers and speakers crammed an incredible amount of high-quality content into two days.

I find myself wondering if OSCON might not work better if it were split into an “executive” event focused on platform and service offerings, and the “hacker” gathering which narrowed in on code, tooling, and collaboration. I still very much enjoy getting to see community leaders like Rob Pike and Larry Wall speak, and will happily continue attending OSCON if I can do so safe in the knowledge that I don’t be inundated with salesdroids throughout the week.

Unfortunately, all is not wine and roses (or scotch and bacon, or whatever). The major dynamic webapp frameworks push you by convention into doing the bulk of your application work syncronously in the request-processing loop, rather than asynchronously in a background thread. All of the accumulated wisdom about building responsive graphical user interfaces gets thrown out and re-discovered by each framework’s user community, resulting in a multitude of solutions for the basic problem of pushing work into a queue and dealing with it later.

As the fine folks at Twitter so famously discovered, synchronous processing puts a hard upper limit on how much (and how quickly) you can scale an application. Even at the much more modest loads my current project at work receives, there are quite a few performance problems that can’t be solved by simply throwing more stuff in memcached and hoping for the best.

Some folks are starting to catch on, and bake asynchronous processing into their frameworks by default, but the solutions tend to either be limited to very particular deployment and application models, or esoteric in the extreme. Meanwhile, desktop application authors continue to politely chuckle at all of our bumbling, and old-skool enterprise developers look at our hackish background-worker implementations and (rightly) consider them to be toys compared to the classic “big boy” message queueing solutions, or even the newer open source alternatives.

The next generation of web application frameworks should be designed around the idea that work is done asynchronously by default, with a fallback to syncronous jobs only in cases where a user needs to see the result immediately. Since applications also need to scale across a potentially large and heterogenous set of CPUs and servers, those delayed jobs also may not be running in the same memory space as the web application itself. That means machine and language-agnostic serialization, fast network IPC, and callback and event-driven programming.

Developers who grok these concepts now will have a leg up on the competition when building tomorrow’s crop of web applications.

The quick version is: the Project Kenai team is turning out to be just about as good a group to work with as I could hope for. We’ve got enough to do to keep things from getting boring, but it’s the good kind of work: interesting + challenging, but nothing that feels like a death march. Plus, every time I fire up an editor to look at a new piece of code and see the GPL license in the header comments, I feel a little better about the company as a whole. Being somewhere that open source is the default (rather than a special case for which you have to lobby) is a pretty cool feeling for a OSS nerd like me.

Otherwise, things are pretty normal. As my family and friends all give in to the gravitational pull of SE Portland, I also find that my social life is less and less about going out, and more about staying in for social meals + conversation, which suits me just fine, especially in the winter.

That’s it for now. Expect more on the technical side of the work I’m doing after Christmas, when I have some time to write up my impressions of doing JRuby on Rails, and working in a heterogenous Solaris/Linux/OS X environment.

I’ve been a BlackBerry user for the last year, and have also spent a decent amount of time messing with friends’ iPhones since the original 1st-gen release. In terms of polish and consistency, the Android UI lies somewhere between these two poles: you need to do a bit more context-switching in normal app operation than is required on the iPhone, but 3rd-party apps aren’t the unpredictable crapfest they are on the CrackBerry.

Performance is also somewhere between these two — while the entire system is quite stable, and response to hardware events (button presses, incoming calls, etc.) is good, some of the apps could obviously benefit from further performance optimization, as they tend to get bogged down on screens with a lot of redraw, or fail to offload as much processing into background tasks as they should to maintain UI responsiveness.

The keyboard is an almost-unmixed blessing. I’ve become a bit too accustomed to the layout of my BB Curve, so I’m not quite back to full “touch typing” mode on the G1, but I’m already far more proficient and confident in my typing than I’ve been able to get on the iPhone touchpad. Having the ability to close the keyboard and use the entire screen for text, images, or video is a definite win over the split-face Blackberry layout, as I’m one of those masochists who actually tends to read long-format text (blog posts, Wikipedia entries, and email) on my mobile device on a regular basis.

The Android platform application ecosystem is obviously far less mature and complete than the iPhone App Store. While I have a decent Twitter app (Twidroid) and SSH client (ConnectBot), there aren’t many compelling games or productivity apps available yet. Of course, I’m a coder, so there’s one obvious solution for this: write the damn things myself. Once things settle down a bit with the new job, I’m hoping to have some time to do just that.

Overall, though, I think the most interesting thing about Android is not what it offers in terms of competition for Apple, Microsoft, and Nokia (though that is a compelling argument in and of itself). What I see foreshadowed when poking around in this system is an absolutely kick-ass netbook or non-real-time embedded operating system. Given the performance Android is able to maintain on the ARM-based G1 hardware, I think it would scream on an Atom-based ultraportable like the ones Wind and Asus are manufacturing these days, especially if both a touchscreen and usably-large QWERTY keyboard were available on the system.

Android may not do much to stop Apple’s ascendence to smartphone domination, but it does offer a glimpse of how a truly usable, efficient Linux desktop environment might work.

Wrong.

Now that we’ve elected Obama, increased the Democratic majority in the House and Senate, and (in Oregon, at least) added a bunch of smart, young, enthusiastic new legislators, it is incumbent upon the electorate to help set the policy agenda. We can’t afford to let our current momentum die down one iota if we want to insure that the promises of the campaign season are actually fulfilled.

For myself, that means moving into a “citizen lobbyist” role. I’ve started the groundwork for that (along with a few of my like-minded friends) with Policy in Motion, but we haven’t yet completely figured out how to sip from the massive firehose that is an active legislative body.

I definitely believe that having one party control most major offices + both legislative bodies in the state means that transparency and access to information will be especially critical. Working towards open government, using both technological and volunteer-driven tools, is going to be a huge part of that. (And it just so happens to be part of Obama’s transitional agenda, as well.)

Regardless of the issues we choose, our government is not magically going to serve us well, simply because we voted in the right column on Nov. 4th.

Update: Digby seems to agree, at least in principal.

Unfortunately, I’m still chafing a bit at a number of little annoyances:

• The REPL is basically crippled since you can’t define functions. Being forced to think in terms of compilation units (rather than simple expressions) pisses me off.
• Why oh why do I need to explicitly list the module name in my file header if I’m also bound by the restriction that filenames and module names have to be the same? The old Java package/file path ties were always a big annoyance when I was stuck in that environment.
• For a functional language, there’s an awful lot of syntactic vinegar for basic operations like map and fold. I appreciate having a concise syntax for lambdas, but writing fun my_function/2 smells a bit.
• Records (as syntactic sugar for tuples) are a poor substitute for a real type system. Both tutorial and real-world Erlang code I’ve seen is basically full of tagged tuples, which means you get the verbosity of a strongly-typed language without any of the ability of real type checking to catch errors at compilation time.

I want to stick with it long enough to find the real gems underneath all this noise. I mean, if I can sit through extended sessions reading and writing Perl, I should be able to find something to love about Erlang. Furthermore, most of the complaints I make above are inapplicable to mainstream languages — i.e., C and Java dont have an REPL or lambdas, and Ruby and Perl don’t have anything resembling a traditional compiler — not miraculously better.

I definitely think that learning a new language should make you feel a little bit uncomfortable. Unfortunately, right now Erlang leaves me feeling uncomfortable in all the wrong ways: I understand everything that’s going on with the language, and just don’t like it.

I’m going to keep plugging away for at least a little bit longer, though. Next up: reading the source to EJabberD to (hopefully) get a sense for idiomatic language use in a context where its unique features (lightweight concurrency + distributed computing) are a real advantage.

I’m unlikely to work as a proprietary desktop software developer any time soon, given that I haven’t tried to write a desktop GUI application in about five years, but I do appreciate the work that Panic puts into polishing their user experience, and have a great deal of respect for them as a development team. And so, it was extremely refreshing to me to see many of the fears and frustrations I’ve expressed about the iPhone/App Store platform lock-in as an outside being echoed by someone who is working within that ecosystem.

One realization I had early on in my IT career was that almost any two firms could easily become competitors. Given the rate at which a competent team can develop most any class of application on the planet, and the generality of the platforms on which our code runs, it is entirely conceivable that your platform vendor of choice today (or your client buying your tools or OS) could become a direct competitor tomorrow. For that very reason, trusting the future of your business to the continuing benevolence of a vendor is a very risky decision.

Every developer working on applications for the iPhone/iTouch platform is in exactly that precarious position right now. Those innovative applications that drive sales of the platform could easily be incorporated into the next release of the OS, since Apple has more than enough resources to re-implement any 3rd-party app without breaking a sweat. (There is certainly precedent for this: just ask the developers of Watson what it’s like to one-up Apple in the system utility space.) Even worse, truly disruptive applications that offer capabilities beyond Apple’s comfort zone (or that of one or more of their mobile network providers) could find themselves summarily dropped from the App Store, effectively strangling any business the developer hoped to build around the product.

This is, to me at least, an unacceptable bargain, and I’m surprised that so many other developers seem to have no problem with the arrangement. (Have I mentioned how much I can’t wait for Android?)

Podcast Producer does to the production of podcasts what the assembly line did to automobile production.

ORLY?

What are these projects? Simple: the distributed storage and merging tools. The most successful example is probably Git, but a bunch of other interesting related projects (CloudRCS, Google Gears, Prophet, etc.) are all exploring a similar space. Basically, the proposition is that, given the right kind of atomic update operations, data can be modified on a bunch of different nodes, and merges can happen asynchronously (if at all) when time, connectivity, or workflow permits it.

To explain why I think these tools are important, and where I think the opportunity exists for the next crop of interesting applications, let me offer examples from two different conferences I’ve attended in recent months.

First, an example of where distributed authoring tools succeeded: at RubyFringe, almost every presentation which featured code included a GitHub link and invitation to fork the project and push back changes. In fact, one of the presenters introduced Gist, a tool designed to allow even throw-away “pasties” of code to be version-controlled and shared using Git as a backend. 

Anyone interested in checking out a copy of the code, making some tweaks, and pushing them back to the original author just needed a copy of Git. They didn’t have to do the work online, and didn’t even have to use GitHub if they didn’t want to, and their work would still be version-tracked and shareable with other developers.

In contrast, while at the NITLE Moodle User Meeting in Tacoma back in June, I struggled to share an outline for a presentation I made with my co-presenter. The hotel where the conference was happening had effectively useless ‘net access, so Google Docs and other online services were out of the question. We eventually just had to sit down next to each other the night before the talk in front of my laptop and edit the outline as plaintext, and then copy the file as a whole to his machine for conversion to Keynote slides.

Now we have a simple text file containing the outline, and a PDF generated from the Keynote slides, but no way to show the evolution of the presentation over the days of the conference, or to track changes for future adaptations of the material. Furthermore, if one of us wants to make changes and share with the other, we’re stuck with email attachments (or the glorified Web 2.0 FTP-clones like Dropbox) to keep up to date.

Programmers have figured out the value of distributed authoring, and understand the necessity for sane merging and conflict-resolution practices from long, painful experience. Knowledge workers in other fields have been using the “track changes” features in Word for just as long, but haven’t yet made the leap to fully-shared authoring. Even when they do, it tends to look more like a Wiki than an offline, sync-able tool like Git.

There’s a huge potential in this space for applications other than source code and other plaintext formats. Tabular data like spreadsheets, outline editors and presentation tools, and PIM and calendaring systems could all benefit from asynchronous, distributed authoring and merging. There’s some work being done at the OS level, (iSync/SyncServices, Live Mesh, etc.) but I think that the really interesting stuff is going to happen out at the edge, amongst the startups and small app developers.