OSCON is the type of show that is more or less impossible to sum up in a few, easily digestible paragraphs. It’s a rare confluence of converging commercial and open source interests, with talks ranging from talks on open source strategy to “How to Write Portable C Code.” As such, it defies easy categorization and description. So rather than try and present a comprehensive summary of the show as a whole, I’ll merely recount what I consider to be the highlights.
- Accidental Development:
It was a mere footnote to his overall presentation, but Mark Spencer’s confession that Digium’s origins lay not in disruptive VOIP provider but Linux supporter struck a chord with me. Because just as Asterisk was developed purely by accident to scratch an itch – Digium’s internal phone system – this is a more common development pattern than is commonly recognized. Outside of software, many are familiar with the fact that penicillin was discovered by accident, but how many know that PageRank – the innovation upon which Google has built a multi-billion dollar business in a short span of time – was not the original focus? Or that Ximian, a company built to provide support for the Linux desktop, would attract the most attention and eventually be acquired by Novell because of an afterthought called Red Carpet?Not I, certainly. The moral here is clear: businesses may emerge where you least expect them, so pay attention. This is particularly true in open source; as Autodesk’s Gary Lang related Thursday morning, your business might not be what you think it is.
- Asterisk:
Speaking of Asterisk, I’ve had probably half a dozen conversations with people about how underappreciated this project is. The good news is that most people agree, or at least pretend to so as to get me to stop talking about it. VOIP is one of those rare technologies that can have immediate and discernible impacts on the bottom lines even of the smallest businesses, and I think – as I’ve said before – that we’ll be hearing a lot more about this project in the next 12 months. Maybe even sooner if some of the conversations I’m having bear fruit. - Asymmetric Competition:
A popular topic of discussion during Tuesday’s O’Reilly Radar sessions, I have to admit that I don’t know that I fully grok what the term is meant to convey. As best I understand it, an asymmetric competition is one in which two opposing forces spar on uneven ground – apples to oranges, as it were. Think Writely vs Microsoft Word. Given that this line of thinking dovetails and overlaps to some extent with my Bart Simpson / Sun Tzu thoughts, I’m a believer. As I exhorted the assembled audience in today’s keynote, be creative. Playing by your competitor’s rules is not a guarantee of failure, but it’s not doing you favors either.When competing with closed source applications, most open source applications will be doing so on asymmetric terms, but as open source application availability goes up we’ll inevitably begin seeing efforts to make the competition between two open source contenders uneven in some way.
- Business Models:
I’m often asked when speaking with customers contemplating open source businesses what percentage of customers they can expect to pay. According to David Skok, one of the original investors in JBoss, the conversion percentage of the middleware firm was around 3%. Put another way, it means that 97% of JBoss users did not pay the firm a dime. Is there money in such a model? Before acquisition, they were projecting around $65 million for this year, and possibly double that next. That number, depending on your perspective, could be good or bad, but the relative revenue opportunities for volume rather than margin based models is a topic too big for this entry. Will explore that in more detail later.Besides the JBoss examples, there were animated discussions concerning the role of service, support and maintenance, and the general conclusions seemed to be that support itself is not enough. I completely agree, and think that the next major monetization opportunity is what I’ve been chatting up with customers and others within or around a variety of open source communities. I’ll have more on that too in a later post, but think Salesforce AppExchange, Ubuntu Marketplace/Commercial, or even the Mozilla Extensions library.
- Componentization and Application Development:
I do not believe that I’m allowed to discuss the details of a very interesting lunch that I was thankful to be invited to, but the general point worth making is this: the componentization of application portfolios is not a phenonmenon limited to ISVs. I heard first hand from the Chief Technologist of a large financial firm how they were going about this problem, and had decided against virtualization in favor of an approach that borrowed from Linux package management strategies. I need to think on this further, but it’s something to monitor. - Development – Legacy vs Innovation:
MySQL’s Paul Weinstein was quite candid in an O’Reilly Radar session in describing the ongoing tension within the database firm between the past and the future. On the one hand, customers cry out for traditional database features such as stored procedures and triggers, but on the other there are many in search of an information store that’s quite a departure from what we’ve traditionally considered a database. It’s certainly not a tension that’s unique to open source, but it’s an issue faced by a great many open source projects, in my opinion, for a simple reason. Several years ago, when open source was less well understood, and therefore more liability than asset in the evaluation process, projects were implicitly encouraged to be conservative in their approach. Thus OpenOffice.org, MySQL, JBoss and other successful open source projects ended up looking a great deal like their commercial counterparts. While this was beneficial initially, because it allowed these products to compete more effectively for businesses who knew (or thought they did) what they wanted in an office suite, database, etc, I maintain that longer term this is a less than ideal approach. Now that open source, as I argued in my keynote, is more established and clearly here to stay, it is my hope that open source projects will feel less shackled by conventional expectations and will begin delivering more products that transcend traditional definitions and categories. - Evolution of Communities – Early Adopters Might Leave, But Are Replaced:
One of the interesting comments made during the aforementioned O’Reilly Radar sessions was an offhand remark from Red Hat’s Tiemann. In discussing issues relating to the conscious transition Red Hat had made in order to focus on the needs of enterprise customers, he discussed the nature of community traction and momentum. In particular, he asserted that while the participation level of early adopters may decline over the course of any given project as it matures and becomes more stable, less bleeding edge, their numbers would be more than made up for the influx of mainstream users. I take his point, but would disagree in that I don’t believe all users are created equal, and I don’t believe that mainstream volume is a given to offset the departure of early adopters. I don’t believe, for example, the selection of Ubuntu by gurus/technical deities such as Doctorow, Pilgrim, and Ruby are as irrelevant as that comment would seem to indicate. Red Hat’s current financial success is obviously an important datapoint that at present validates Tiemann’s belief, but I think an approach that offers the best of both worlds – enterprise stability for those who need it, cutting edge features for those with a higher risk threshold – is more viable over the long term. The obvious next question is who’s doing the best job of that, and IMO that’s Ubuntu, not Red Hat. Mugshot excepted, Red Hat is increasingly cementing a reputation as a strictly enterprise distro, and sooner or later the question has to be asked: is that good or bad? - Journalism via Computer Programming:
This may have been my favorite session of the entire show. Adrian Holovaty, of Chicagocrime.org and DJango fame, described how applications can themselves become journalism of a sort. The idea is that as applications begin to integrate new and disparate data sources in a variety of ways, they begin to transcend the boundary of mere application and become real journalism. By recombining datasets from the Washington Post’s various databases, Adrian’s insightful Votes Database and sad Faces of the Fallen draw new conclusions from the data much as a live reporter would. This is definitely related to the idea of personal business intelligence I’ve floated in the past from time to time, but suffice it to say I’m an avid follower of Adrian’s work and I think you should be too. - Open Data:
As I told the audience on Thursday morning – not that I was alone in addressing this topic, quite the contrary – one of the single most significant impediments to open source adoption is data import/export, or in a more formal sense ETL (Extract/Transform/Load). Consider the case of mail migration, for example: potential customers of Scalix, Zimbra or other open source mail packages must- Determine how to extract their data from their current mail system, which statistically speaking is likely to be be closed source and employ proprietary protocols
- Determine how to import that information into their alternative mail system
- And lastly – and perhaps most importantly – have an exit strategy allowing for the reexport of application data should the new system not meet their needs
The trend towards open data may be unpopular and difficult to stomach at times (Tim’s interview with Yahoo/Flickr’s Chad Dickerson was quite instructive here) but the roach motel data model (where data checks in, but doesn’t check out) simply is not sustainable in the face of options that do not lock in data. Much like cell phone providers in the US fought number portability in an effort to lock in customers, so too will certain application providers, but data providers that choose to try to lock in data will face some tough questions from customers. It may be, as Simon asserts, paradoxical that the Freedom to Leave encourages customers to stay, but it’s true nonetheless.[1]
- Open Source Infrastructure, Not the Application:
On the question of what should and conversely should not be open sourced come some interesting case studies. Much like the web framework phenomenon of Rails was extracted from a work application (Basecamp), so too was Python’s DJango distilled from live applications developed for the Lawrence Journal’s various web properties. In both cases, the applications including datamodels and specific business logic were not open sourced but rather sold, either as software as a service (Basecamp) or on an OEM basis (can’t read my own notes on the software package the Lawrence paper sells – Ellison, maybe?Ellington – thanks Jeff). What this points to is a hybrid model that has benefits for nearly everyone involved:- Community:
Communities benefit from the addition of high quality code developed, tested and implemented by paid developers, and consequently the language associated with a given community can see downstream bumps in mindshare and momentum (e.g. Ruby). - Developers:
By open sourcing the infrastructure, developers can a.) offer the code the best possible shot at longevity and wide adoption, and b.) do wonders for their personal visibility and reputation (e.g. Adrian Holovaty or David Heinmeier Hansson). - Employers:
They benefit in several ways. First, should the primary developers depart as Adrian has done for other opportunities, the open sourcing of your infrastructure allows employers to potentially hire developers that already know their infrastructure. Second, the open sourcing of the infrastructure rather than the application built on top of it preserves the possibility for further economic gain and payback. And lastly, they begin to build a reputation as both both good open source citizens and an attractive place for outstanding developers to work.
- Community:
- r0ml:
As discussed in many other places, the phenomenon known as r0ml was the unqualified hit at the show. His sessions were jammed, raucous, entertaining and yet insightful, and he’s beginning to develop his own following. I hope the rumor is true and that there will be a full r0ml track next year, not only because I’d like to see more of what he has to say but also because I wouldn’t have to feel bad about anyone trying to follow him on stage 😉The most important news, however, regarding r0ml is what I learned on our flight out to JFK: he is
nota free agent and entertaining offers. I understand he is looking for a technical role – though presumably one that would allow him to boost his burgeoning population of groupies with continued appearances at OSCON – and I cannot stress enough that the firm that lands him will be a lucky one. Resources with his combination of technical acumen – honed on Wall St – and communication savvy are rare indeed. Make an offer while you can.
Besides having the opportunity to educate myself on the above topics, I had the pleasure of meeting a great many people at OSCON for the first time, such as IBM’s Sam Ruby, Sun’s Glynn Foster, and Yahoo’s Jeremy Zawodny. All in all, a very worthwhile conference and without question one of the highest values on the conference circuit today (provided that your focus is not on generating sales). Outstanding job by O’Reilly and company, and thanks again to Nat Torkington for the kind invitation to address the crowd. Can’t wait for next year’s event.
[1] Back at the IBM Intellectual Property conference I attended a month or two ago, I had a conversation with an IBM executive whose name I’ve regrettably forgotten about data and data loss. Specifically climate data, pertaining to temperature and climate shift research in Greenland as I recall. With global warming continuing to be a topic of much discussion and interest, this research has obvious importance but unfortunately when someone needed to go back to the original data it was missing in action. Somehow the data had been misplaced or unintentionally destroyed, and a potentially irreplacable knowledge set vanished without so much as a whimper. What if, this IBM executive pondered, academia in this area was committed to open data? Data that could and would be seamlessly shared across organizational and institutional boundaries? Might that data be cached somewhere else? This gentleman purported to be involved in a governmental and academic effort entitled Open Data, but I haven’t been able to discover any more about that consortium.
