SVG - Are We There Yet?

Anyone who has kids knows this particular plaint coming from the backseat of the car, usually not longer after starting down the road toward some favorite vacation spot. I was thinking about this today in light of the recent SVG conference, and some post-conference discussions I've had with a few of the other attendees via e-mail.

At what point do you throw in the towel with respect to an Open Standards technology such as SVG? At what stage in a technology's development do you question whether it has failed to reach some minimal threshhold of survivability, and will only end up being a shadow standard, one that may exist on paper but that couldn't survive out in the wild.

Such questions have more than academic interest. SVG is potentially a very useful technology ... one that is already beginning to prove itself in niche areas such as GIS, where the advantages of semantically rich graphics are most immediate obvious. Outside of this small domain, however, the advantages are nowhere near as clear-cut, where there are commercial companies with very well-entrenched proprietary solutions, and where there are few tools of the calibur of an Illustrator or Flash to entice graphical artists. Explaining the benefits of XML to a tech savvy crowd of developers is a fairly easy proposition ... explaining it to graphic artists who can already do everything that the technology offers via other means is a much more difficult one.

If a technology isn't sufficiently viable, if it doesn't hit that critical mass necessary for "fusion" to occur, then it will be like a brown dwarf, a protostar that is too small to sustain its interior fires. In order for that critical mass to happen, in the case of SVG, there are several different pieces that will need to all fall into place:

1. Developer Base. If there aren't enough developers working with the technology, then the quality of the applications built with it will almost always be far below that provided by a commercial vendor's offerings, and the breadth of those applications will be limited. The SVG developer base is not yet huge, but it IS growing at a pretty good clip.
   
2. Sponsor.In the Open Standards arena, there is typically a sponsor organization pushing the technology. In some cases, such as IBM's release of code for Eclipse, this champion is a large vendor interested in promoting open source solutions. In other cases, such as the Apache Software Foundation, it is a large umbrella group of technology providers that serve to promote the critical standards. I'd have to say that Apache has a few champions in different spaces - the aforementioned Apache with the Batik project (though that program has slowed in recent years), Adobe (which has had an on-again, off-again feeling for SVG), and of late the Novell/IBM access, which has been quietly funding the SVG development in Linux.
   
3. Synergy. An open standard typically does not exist by itself. Instead, it will often gain much needed value by coming along at the same time as technologies for which the standard lends itself particular well. The "LAMP" suite -- Linux, Apache, mySQL and Perl (or increasingly PHP) -- represent such a synergy. SVG is beginning to really take off in the wireless space, with the language especially well suited for JIT transmission of graphical content in a small, easily modifiable payload, yet another such synergy that I suspect will be increasingly important over the next couple of years.
   
4. Modularity. The degree to which a technology is "plug-and-play" can significantly affect its degree of adoption. In some respects this is a strength for the W3C in general, in others its a weakness. SVG in particular has some problems with modularity -- it can in theory be integrated in with XHTML and work with XForms, but the practice is usually not as clean as anyone would like. On the flipside, while SVG had adopted the W3C DOM, it's not completely consistent with its use of SVG 3.0 standards, and there are questions in the sXBL space about the support for certain other W3C standards such as XPath. The temptation to roll your own API is always there, of course, as a generic API specifically adds a layer of abstraction complexity that more dedicated APIs don't have to deal with, but a well-designed general API also usually is less susceptible to feature creep and encrustation that more specialized APIs tend to encounter on an all too frequent basis.
5. Evangelists. Guy Kawasaki was responsible for bringing this term into the programming lexicon, but the idea has been around for a while. Sponsors are usually capital backers, the ones to provide the funding to keep the core developers in pizza. Evangelists, on the other hand, are people who live, eat and breathe the technology, who serve to champion it to other developers, corporate managers, and the public at large. Evangelists fervently believe in the technology, in what can be done with it, and typically are not directly associated with the sponsor of the technology (though evangelists often eventually get picked up by sponsors for doing things like standards efforts). I'd consider myself an evangelist for SVG, along with people like Don Demsiak (Don XML), Ronan Oger, Michael Bolger, Peter Schonefeld, Antoine Quint, Michael Bierman, Philip Mansfield, Jon Ferraiolo and others likely to be found on the SVG-Developers list.
   
6. Exposure. Evangelists are important because they act as intermediaries between the core development community and the media (both IT and otherwise). Right now, SVG is a barely-kept secret. GIS is adopting it in a big way, it's beginning to make waves in wireless media, but SVG is still at the point where most people require the acronym to be spelled out in order to know what it refers to. However, that is showing signs of change, due in part to the efforts of evangelists to educate the larger IT community, in part because there is enough saturation of products with SVG to make it a strong marketing point. When you see stories about SVG in Time Magazine, you'll know that it has become mainstream, and you better have that IPO ready.

SVG has the potential to have a huge effect on all aspects of the web, something I think many in the SVG community already know. However, to make SVG adoption happen faster, there are several things that you and others can do:

1. Become an Evangelist. If you are a consultant, pitch SVG solutions to your clients for intranet applications. If you are a full-time programmer, look for places where SVG can be used in your company's applications, either for core functionality or eye candy. If you are a manager or marketer, look at what advantages SVG can buy you, and become a champion of the technology in your own company. SVG is maturing enough now that you CAN build such solutions into your own applications, though it can take some work.
2. SVG Web. SVG on the web is going to take a while to become solid, in part because of the whole issue of plug-ins and varying degrees of support. If you can, build SVG sections on your websites, clearly labeled for what they are. SVG is not quite ready yet for core functionality within public sites, but it can be an interesting diversion for those sites that do support it.
3. Contribute. I'm going out on a limb to say that I think Mozilla Firefox is going to seriously erode Microsoft Internet Explorer's base, especially as Redmond doesn't seem to have anything in the works to shore up that side of things. The Mozilla SVG support is sporadic right now, and can use an infusion of developers to pick things up, but its solid enough that this isn't the massive effort it could be. Think about the advantage of native support of SVG within a web browser. If you are in the Linux world, help with the KDE and Gnome SVG efforts, for much the same reason - SVG support built into the operating system is a huge advantage, and additionally gives you a track for getting SVG onto the Macintosh as a native API.
   
4. Create Art. If you are an artist, a graphic designer, animator, or in similar field, use tools such as Adobe Illustrator, Inkscape, Sodipodi, or any other of dozens of such editing tools to create good quality SVG artwork, and get it in front of people, along with instructions for being able to load it in appropriate viewers. Artists often find SVG to be intriguing once they figure out the potential for what it can do, but all too many are simply not aware of SVG in the first place. I hope to be able to set up an SVG gallery soon as part of this process as well.
5. Talk to Vendors. Software companies respond to customers and to developers. The more that they hear about a given technology demand from their client, the more they are likely to add in support for that technology if a decent business case can be made. Microsoft is probably a waste of time, but Macromedia's halting first steps in that direction at least indicate that they are cognizant of the market, and Adobe's SVG efforts (while maddeningly secretive) seem to be gathering steam in response to the technology.
   

Has SVG reached critical mass yet? Perhaps. The tipping point is usually only obvious in retrospect, where the second order derivative begins to contribute in a meaningful way to the adoption of that technology. My gut feeling is that we're close to being there, if not slightly past it, that the pieces are all beginning to line up, and that the growth in SVG related tech is going to be explosive in 2005, but that's just a gut check, and I'm still pulling together the imperative evidence for it. I'm lining up my SVG ducks in a row right now, and would recommend that you do the same.

Until then, remember to stop for potty breaks. It keeps the kids from driving you crazy ...

Kurt Cagle