The Web, indeed the Internet, has a rich tradition of being made from "small pieces, loosely joined" to use David Weinberger's excellent phrase. The beauty of the Web is that it's all built from a handful of relatively simple standards:

• HTML, a standard for marking up documents with formatting instructions and creating rudimentary user interfaces called "forms,"
• HTTP, a simple request-response protocol for moving resource representations (which might be documents formatted in HTML) from place to place, and
• URIs, a standard for how resources will be universally reference on the Web

Using those simple pieces, the Web has evolved to rich collection of sites and services we now enjoy. Or, at least, that's the romantic view.

In fact, the modern Web is built on a large collection of conventions, patterns, architectures, libraries, and systems that have been built on top of the three pillars of the Web. In theory, you could build Facebook with nothing more than a CGI script that reads raw input on STDIN from the server, consults a database, and formats responses as a series of print statements on STDOUT--like we did in 1993--but that's not how it's done. The vast panoply of Web sites we use everyday exists because programmers make use of architectures and libraries built on top of the basics of the Web.

There's always some tension in this. For example, consider SOAP and the Web Services edifice that was constructed around it. A battle eventually ensued that pitted that elaborate structure of standards, protocols, and practices against a much simpler idea called "REST" that has, at this date, largely replaced it. REST accomplished many of the goals people had for SOAP in a way that was simpler. It didn't hurt that REST could invoke religious arguments that it was "truer" to the spirit of the Web. There's power in that, to be sure.

Now consider Rails, a programming framework built on top of Ruby. Rails asked much of its early adopters. First, it was built on a new and unfamiliar language called Ruby. Second, Rails introduced new and unfamiliar nomenclature to describe its core concepts. Third, it placed restrictions and boundaries on how programmers worked, requiring them to work in certain ways. And yet, developers who made the effort to overcome these hurdles were able achieve desirable results easier than with other alternatives.

Rails provided abstractions--conceptual models--that changed how programmers thought about the task of building interactive Web sites. Rails included conventions for certain, oft-repeated tasks to let programmers avoid choices that had little bearing on the final outcome of their project. Rails provided libraries and tools that made common tasks, like doing object to relational mapping, easy. But most importantly, Rails wrapped all of these into a system, with its own language and culture, so that they all worked together without the impedance mismatches developers face in "rolling their own."

We can ask "why did Rails succeed where Web Services failed?" While there might be a lot of technical arguments we could make, I think there are a few important ones:

1. Web Services was too heavy, requiring a huge investment in congnition and effort for even small jobs. Web Services tried to solve every problem with yet-another-standard. in the end, Web Services feels like lots of standards without a system to tie them together. Another way to put it: Web Services is a large cognitive model without a supporting linguistic framework. XML just doesn't do that--it's too flexible and too general.
2. More important, Web Services got dragged into the enterprise because that's where vendors pushing Web Services like IBM, Sun, and Microsoft could sell software using what I call the "two guys in suits" model. The enterprise is never as innovative as the non-enterprise, consumer-oriented developer space. Without the innovation, Web Services never got its groove on. It just wasn't cool.

I need to make a big disclaimer here: I'm not saying Web Services failed, just that it failed to get developer uptake in sufficient numbers to make it a player in the future Web. Indeed, Web Services has informed and left bread crumbs for a number of important discussions. For example, REST needs an API description language so that minor annoyances like generating libraries for various languages can be automated. Web Services has a lot of experience with that sort of thing that will inform thinking in this important area. Further, the problems Web Services was trying to solve are real. I think os Web Services as just the initial prototype of the services we'll have to build out to solve them.

I think a lot about what it takes to get developers over the hurdle of learning a new paradigm because the success or failure of Kynetx depends on that issue. I'm constantly balancing the height of that hurdle with expressiveness and cohesiveness. Over the course of the last several years, we've constantly adjusted the kinds of problems we're working on to find the ones where our ideas can have the bigget impact.

I believe strongly in the power of a programming language to shape the thoughts of developers along a particular path and in ways that make thinking about certain kinds of problems easier or harder. For example, Rails is domain specific language embedded in Ruby. The language of Rails, however, pushes developers to think about Web development problems in specific ways and, in so doing, shape and guide that thinking. Its success is dependent on being properly matched to the problem domain it's designed for a net effort savings by the developer.

I also believe that systems are more likely to be successful in that effort than mere patterns. While patterns are useful and form what we might think of as the first bastion of abstraction in the programmer's arsenal, they rarely have evengelical power sufficient to unite large crowds of developers around an idea. Systems, at the other end of the abstraction spectrum, unite a programing model with libraries and services to provide a platform (in the original sense) upon which community can be built.

With Kynetx, we're trying to introduce a new programming model for developing evented systems that understand entity (i.e. individual) context. That problem warrants a system with a new language to make it easy to solve. The problem is big, audaciuous, and hairy. The gap between a few patterns using the basic building blocks of the Web and the problem we're solving is too big for most developers to tackle and requires too much effort for all but the most profitable ventures. With a supporting system, however, smaller scale projects can be built with a level of effort comensurate to their value.