Blogs

RedMonk

Skip to content

Closing Thoughts on Mashup Camp


Jonathan Schwartz Presenting the Mashup Camp Grand Prize

Originally uploaded by sogrady.

One of the core tenets upon which RedMonk was founded was that context matters. A lot. Mashup Camp was, in my view, an excellent reminder of this belief. For example, my feedback from day one of the show drew criticism from my colleague, who believes that my signal to noise comment was potentially insulting to our regular audience. And in a hallway conversation, ZDNet’s Steve Gillmor indicated that he didn’t share my belief that this was one of the better conferences in a while, if not ever.

But it’s a question of context, I think. My opinions of the show, and its value, cannot be divorced from it. As has been covered any number of times before, the most important constituency for me to track is the developer community, and Mashup Camp was a camp all about developers. Developers provided the content, developers set the agenda, and developers competed for the rights to a tricked out Sun server.

Is this the perfect conference format for everyone? Absolutely not. But for me, it was ideal. I was free to wander around, chatting with some of the best and brightest within the development community – with no barriers. Want to talk to Chicagocrime.org‘s Adrian Holotavy? Pull up a chair. Want to hear about what Mashup Camp’s Grand Prize winner, Taylor McKnight, built his application on? Just ask.

So while I’m sure that many will have their opinions on what Mashup Camp got right or wrong, not to mention its ultimate value, I’m with Jonathan Schwartz: I personally hope this is the future of trade shows, because it prioritizes the voices of the constituency that I care most about – the developers. YMMV, as always.

Other news & notes from the show:

  • I was going to bring you summaries of the highlights from the ‘speedgeeking’ portion of the show, but Dan Farber’s already done that here.

  • Of the mashups, which were my favorites? Well, I did think Taylor and Daniel Westermann-Clark’s Podbop.org (Perl) winner was pretty cool, but Adrian’s second place Chicagocrime.org (Django/Python/Postgres/PostGIS) got my nickel. What he’s done with that site is remarkable, and there’s more on the way. In addition, to those two, I liked David Schorr’s Weatherbonk.com/Skibonk.com (Java) and travel services Flyspy and TrainCheck. I’m almost certain to also be trying out Eventful’s iTunes to calendar synchronization service.
  • Any other posts of interest? Tons – just hit one of the blog search engines. But in the meantime, check out the wrapups from the folks I had dinner with yesterday: FeedLounge’s Alex King and Sharpcast’s (looks awesome) Adam Tow. As an aside, Adam took the time to demo some of the Newton functionality for me yesterday – yes, that Newton – and it’s amazing how ahead of its time that device was. Linking the calendar with notetaking with contacts? I can’t do that on my desktop.
  • Language preferences: the lack of Ruby apps was notable. Apart from Eventful, I don’t know that there was another Ruby app in house Eventful is apparently not done in Ruby on Rails, but John Herren’s very cool mastrbeta.com is a Rails app. The informal results said that PHP led the pack with a reported 12 applications, Perl checked in with 4, 2 in JavaScript (as if that wasn’t in most?), and 2 in – surprise, surprise – C++. As reported below by Adrian, Python checked in with at least 3 applications of its own – Chicagocrime, traincheck, and Attendr. Again, the results are entirely unofficial not to mention statistically irrelevant, but still interesting.
  • Someone on Day 1 had reported that there were in total (as I understood it – correct me if I’m wrong – maybe there was a qualifier I missed) 160 APIs available for consumption by mashups; that number seems insanely low to me. eBay alone claimed that they had over a 100, so I’m not really sure where they came up with that figure.
  • Monetization: I mentioned briefly yesterday that selling the application was not the only way to monetize the efforts behind these mashups, and yesterday confirmed it. I personally witnessed four separate “interviews” of developers during the conference, and I’m sure there were tons that I didn’t see.

To wrap up, it was a show well worth the trip and I look forward to attending the next iteration (hopefully, with later start times), whever it might be. From the signup page there, it seems as if most of the attendees of Mashup Camp 1 feel the same way.

Update: Couple of corrections/updates:

  1. Fixed a couple of rather egregious typos

  2. Updated/corrected some of the language information

Categories: Conferences & Shows.

  • http://edward.oconnor.cx/blog/ Edward O’Connor

    Apart from Eventful, I don’t know that there was another Ruby app in house.

    Actually, Eventful (the site) is written in PHP, while the EVDB API is in Perl. We have a Ruby API client available, but that’s about all the Ruby going on here.

  • http://edward.oconnor.cx/blog/ Edward O’Connor

    Looks like my blockquote got gobbled in the above.

  • http://baus.net/ christopher baus

    Ok I liked the conference. It was real. I wish I had more energy to invest in it, but I was pretty burned out after hacking all weekend. If there is another in the Bay Area, I’m going.

  • http://baus.net/ christopher baus

    BTW, I thought it pretty cool that C++ was representin’ . We ain’t dead yet :)

  • http://mastrbeta.com John Herren

    My “other” mashup aside from TagCloud is mastrBeta.com which was done in Rails. I believe one other person did a Rails mashup, but chose not to demo it.

  • Danno

    Weird about the lack of Ruby mashing. I know there are a number of APIs for popular webservices floating around on the Forge, wonder why nobody’s pushing anything together.

    Question: What qualifies something as a mashup? Does it just have to integrate data sources from another site?

  • http://www.datamobilitygroup.com/ Walter Purvis

    Re: “160 APIs available for consumption by mashups; that number seems insanely low to me. eBay alone claimed that they had over a 100…”

    I would say that eBay’s 100+ function calls represent 1 API; likewise, Amazon’s Web Services API counts as 1 API, even though there are hundreds of different requests you can make.

    Even so, 160 seems really, really low to me. It does sound like about the number I could come up with if I spent, say, one weekend composing a list of all the APIs that I could find mentioned in articles, etc., but I’d bet my pathetically small life savings that there are far more public APIs out there than that.

  • http://www.holovaty.com/ Adrian Holovaty

    For the record, at least 3 of the “speed-geeking” mashups were made with Python — chicagocrime.org, traincheck.com and attendr.com. I talked to a number of other Python users at camp as well.

  • http://alanlewis.typepad.com/weblog Alan Lewis

    Walter – The problem of how to count APIs is a hard one. eBay has 100+ calls, but if you look at what we really offer its more like 20 or so “use cases” like feedback management, My eBay, search, and so on. Most people are still talking in terms of number of functions or calls, which is why I still use the 100+ number — to put it all in perspective.

  • http://www.peopleoverprocess.com Cote’

    Wow, this topic gets more comments than even ODF! ;>

    We outta look into doing something like this: being able to “to wander around, chatting with some of the best and brightest within the development community – with no barriers” sounds like it’d be worth it (granted that it was unconference instead of Disney world conference).

    If we could get developers and non-developers in the mix, it’d be even better.

  • Ed Holzinger

    Re traincheck

    I live in the DC area and let’s just say the traincheck thing ain’t ready for primetime. I use a blackberry, like many of the people who work in this area, but the app doesn’t work for us. The developers say it has to do with their software seeing messages from the blackberry as being empty.

    I’m sure they’ll fix it, eventually, but seems to me before traincheck gets a whole lot of high praise, it really ought to work with the one device lots and lots of people in DC use.

    That said, it’s a cool idea, but it’s not SMS, despite what the website may say. No, it’s an e-mail service. What they should do is get users to sign up and give their cell phone numbers so the messages, at least, go to the phone as SMS. You know, like Dodgeball.

  • http://scottmark.blogspot.com Scott Mark

    Sounds like Java “got served” at this conference – what do you make of the fact that Java doesn’t feature in mashups? Is it too stodgy of a platform for this culture? Does it just not lend itself well enough to cool and efficient feed parsing from the presentation tier?

    Or maybe large enterprises where Java has it’s hold just wouldn’t cough up to send their devs to mashup camp? :-)

  • Pingback: People Over Process

  • http://www.traincheck.com Bart

    Hello everyone!

    I’m Bart, the developer behind TrainCheck. Thanks to Mr. Holizinger’s feedback, we discovered that a few Blackberry models insert a blank line in all messages sent from the device. The blank message issue has been resolved. Ppl can now type the full text name of the station they want, and the system will return a set of times if an exact match is found, or a set of short codes for multiple matches. Visit our site for more info: http://www.traincheck.com

    We nixed the idea of user registration to keep the service freely accessible to anyone with a cell phone capable of sending SMS or email to the dc@traincheck address. Dodgeball requires registration since your phone number or email must be associated with other “people” in your dodgeball network. The backend messaging systems are identical in function, i.e. email systems. SMS is a actually formatted as a plaintext email, contrary to popular belief.

    Thanks for the feedback, Ed!

  • http://www.traincheck.com Bart

    Hello everyone!

    I’m Bart, the developer behind TrainCheck. Thanks to Mr. Holizinger’s feedback, we discovered that a few Blackberry models insert a blank line in all messages sent from the device. The blank message issue has been resolved. Ppl can now type the full text name of the station they want, and the system will return a set of times if an exact match is found, or a set of short codes for multiple matches. Visit our site for more info: http://www.traincheck.com

    We nixed the idea of user registration to keep the service freely accessible to anyone with a cell phone capable of sending SMS or email to the dc@traincheck address. Dodgeball requires registration since your phone number or email must be associated with other “people” in your dodgeball network. The backend messaging systems are identical in function, i.e. email systems. SMS is a actually formatted as a plaintext email, contrary to popular belief.

    We are currently looking for funding to support the cost of implementing short codes [ex. GOOGL for google search] that would allow ALL numeric SMS capable phones to query our system. The application won’t change on teh backend to implement this service. Stay tuned to our site for updates. After all, we launched into beta on February 21st.

    Thanks for the feedback, Ed!

  • http://www.redmonk.com/sogrady stephen o’grady

    Little late on comments here, but just in case folks stumble back here:

    Edward: corrected this, as you can probably see

    christopher: will hope to catch you at the sequel, then

    john: corrected – thx. didn’t mean to leave you out; mastrbeta might be simple, but it’s pretty cool.

    danno: i thought so too. as far as what qualifies, it seems as if everyone’s definition is different.

    Walter: yup, that’s the way that i saw it too.

    Adrian: thx for the correction, and i’d add that FeedLounge – not demo’d, but with one of its founders there – was also written in Python.

    Alan: thx for the clarification – that makes more sense to me now.

    Cote: yes indeed, altho there are some elements of the unconference that i’d leave out (it’s a little too touchy/feely for me at times).

    Ed: hopefully you’ve seen the response from Bart below your comment – be interested for any further feedback.

    Scott: well, even given that the audience was somewhat self-selecting, Java was not a huge presence. what will be interesting to watch, however, is whether or not some of these players pull an Audioscrobbler at some point and rewrite their application in Java for scale reasons (not that i think you can’t scale, with some of the other languages/platforms, mind you).

    Bart: thanks for the update – hopefully Ed can update his remarks in light of the correction.

  • http://beethere.net/ Carl Eklof

    Hello Stephen,

    We (http://beethere.net/) have been offering a easier (we think much better) implementation of iTunes integration for some time now. We have far more concerts, and much more useful information about the artists, allowing us to also make recommendations, and will finish the national rollout next week. Also, integration with common calendar systems is coming soon.

    I invite you to try it, and let me know what you think.

    We are a musician-run site devoted to concert events. We think that is an advantage for us.

    Thanks,

    -Carl