Some predictions for the coming 'mashosphere'

As MashupCamp gets into full swing today, I thought I'd try my hand at projecting current trends forward and seeing how the mashup world might look in the near future.  The fact is that the services and data available all over the Web, and inside our own organizations, are now just too tempting a target as significant source material for our software efforts. This is important within the enterprise because mashups have the potential to deliver zero-footprint, Web-based business applications that are easier to build, cheaper, more reusable, and more maintainable.

And the open Web services and SOAs that most of us are now building are also really helping make this possible by lowering the impedance between our systems.  Thus, being able to readily combine all our services into rich new applications will probably herald the long-awaited arrival of true software reuse (beyond the ever ubiquitous cut-and-paste method that is).

Software reuse has been a holy grail of the industry for decades and this is one of the very reasons mashups are so fascinating.  Indeed, mashups make reuse happen at several different levels, but that's a story for another time.

I'm fond of citing John Musser's excellent Mashup Feed site, which lists many of the known mashups, though surely many are still not listed.  The main page enumerates the average creation rate of brand-new offerings, presently showing there are 2.75 new mashups created every day.  The implication is clearly that something momentous is happening.

A quick backstory: Driving forces behind mashups

Before we get to the predictions proper, let's focus for a minute on the underlying reasons for the mashup phenomenon.  An important one is the advent of Web 2.0 concepts that encourage software creators to expose their applications as sets of reusable services.  The theory is that you can be much more valuable to the rest of the world if your software can be reused in unintended ways.  In other words, don't just provide a fully created end-product for one pre-intended use.  Encourage others use the good pieces of what you provide in new and innovative ways.

I would also assert that one of the larger drivers of mashups is last year's advent of the web application browser technique, Ajax.  A good Ajax application loads a bunch of Javascript into the browser once and then manipulates the CSS and HTML to provide the visual effect of a full native application.  But since it loads once, the Ajax application is cut off from new data that's usually obtained by page reloading.  Hence something called XmlHttpRequest, a newish addition to browsers that lets Javascript programs in the browser call Web services.  Consequently, Ajax appications are voracious, mandatory consumers of HTTP services including real, full blown, SOA-type Web services.

There are other contributing factors to the mashup craze including the growing interest in lightweight data formats like JSON as well as a style these days of building online software in little bits and pieces that can be easily wired together (the Google Maps Javascript include example being classic here.)

On the demand-side there is a rising comfort with and expectation of finding a throw-away application to do just the one thing you needed when you need it (this is the tendency of mashups to be a handful of features, at most.)

And of course, all of this is important within the enterprise because mashups have the potential to deliver zero-footprint, Web-based business applications much faster, cheaper, more reusably, and more maintainable than ever before.  Applied correctly, all of this can confer vital competitive advantage.  That is, if some of the disadvantages of mashups can be ameliorated such as the aforementioned small feature area.

OK, enough with the prologue and on to the predictions.  Where is all this heading, why should you care, and what's going to happen to you even if you don't?

Predictions for the coming 'mashosphere'

1. It's a hockey stick, folks.  We've only seen Ajax applications and reusable APIs proliferate like this for about a year (heck, at least as a formal term, Ajax's official one year birthday was this past Saturday.)  Expect to see APIs and services sprout up like wildflowers inside and outside the firewall and it will be so very tempting to use them.  I've watched the growth rate on Mashup Feed increase and increase, and David Berlind has gone so far as to say that he expects 10 a day by 2007.  Expect the torrent of new services become a near avalanche with all the attendant implications including the possible eradication of the not-invented-here attitude in software development.
   
2. A real universal registry for mashup APIs gets figured out.  Sites likes Programmable Web do an amazing job making it easy to find the API you're looking for. But this is a far cry from the formalism of UDDI, the Web services directory standard.  This means sorting through APIs is done manually and is not tool aided.  I predict this situation won't last long.  While as far as I know, no one has figured out if UDDI 3.0 or some other standard will do the trick, somebody smart will figure this out and change the world.
3. Mashups tools arrive, and fall short initially.  Weaving together the data and functionality from multiple Web services is the one part of mashups that isn't as easy as it looks.  Modern browsers and server toolkits now make it easy to get data from Web services.  But once you've got have data loaded up in the browser, doing the actual slicing, filtering, transforming, and swizzling of data within your mashup isn't for the faint of heart.  This is the area still requiring arcane skill with things like XSLT and XPath.  Pointing and clicking your way through this is still a ways off. The first and probably second wave of tools just won't be able to elide this problem very well.  I do predict that it's solveable but at the real danger, whoops, I mean benefit of putting application development into business analyst's hands.
4. The cross-domain security problem.  Fixed? Not anytime soon.  A real issue with many mashups is that they want to combine the data from Web services from over the Web.  Wait, isn't that the point you ask?  Yes, but ironically the browser security sandbox really discourages this.  In reality, many mashups do the mashup part on the server because of this restriction.  Using the Web as a world-wide SOA isn't going to happen until this problem is solved.  The sandbox can be worked around with quite a bit of effort today but there needs to be a one-size fits all browser solution.  And this means making folks work together (Microsoft, Mozilla, Apple, etc.) that would often rather not.  So I predict it'll be a while.
   
5. Mashup adoption will follow the usual curve.  Enthusiasts first, then early adopters, then fast followers, and finally, after it's been happening so long it's old news, slow adopters.  No news here, right?  Wrong.  Mashups, like Ajax, are a disruptive technology, meaning that they are a genuine threat to the old way of doing things.  The old way here being traditional EAI and composite application technology from SOAs.  This may very well mean that slow adopters are the never adopters, because they're cancelled, put to pasture, given special projects, or what-have-you.  Fast-moving folks with good mashup tools and a vast landscape of services can punch out 10 smaller applications that not only do what your old creaky ways of building software did, but are in turn reusable and composable.
   

   

   
   
6. There will be a mashup information ecosystem crisis.  Whether it's the explosion of uncontrollable dependencies, vicious dependency cycles, scalability issues, privacy problems or some other side-effect of high levels of somewhat ad-hoc integration, mark my words there will be significant growing pains.  Of course, we'll learn our lessons and there are ways of dealing with all the problems that will come up.  But sometimes we like to re-invent the wheel, especially in environments where we don't have full control.
7. RSS becomes the mashup protocol par excellence.  It's going to be RSS folks, not Atom.  Things like Microsoft's SSE are really going to help, but guess what, I'm now thinking it may be the next incremental version of RSS that fixes the one-way syndication issue.  That's not to say you won't see every possible way of exposing a service but RSS will become increasingly popular, particulary in the tool space because 1) it's so easy understand and simple to use and 2) see #1.
   
8. The static technologies and languages aren't up to the task.  I've tried using Java and C# to build Web 2.0-style software and it's ugly when compared to things like Ruby.  Contact me for some reference examples, but this new world seemingly belongs to languages that readily support malleability, simplicity, and high rates of change.  Expect that things like Ruby on Rails will get extremely popular for building mashups.  Building skills in these technologies will be required to compete because it's so much easier to build and maintain.
9. Feature counts increase a bit.  I can find no good reason that mashups tend to be not much more than a feature.  The problem is likely one of specialization.  Push together a couple of pieces and you may have solved your problem, like Housingmaps does.  But there is also a market for more complex, easily changeable applications-as-business-processes, delivered in mashup form.  This is a big potential growth area and one that a lot of folks are watching to see if mashups are the solution.  And it may very well be though the jury is still out.  However, I'm actively tracking tools racing to market to leverage this approach.  For now, I'll play it safe and say the feature size of mashups will grow a bit.
10. Intellectual property issues continue to nag.  This deserves an entire article to itself but the Right To Remix has to be sacred and learning the ins and out of the Creative Commons license will be standard fare for most of us in the mashup future.  Expect that public flare-ups over violations of fair use and numerous other IP bugaboos will arise and make mashups less straightforward for certain types of applications (especially ones involving people's personal information.)