Then most will say it was a pretty obvious move but then ‘we were already tied up with ours’.

Best.
alain

The real sneaky part is to try to get a standard ratified that requires a patent that you secretly hold. So that you can milk the implementers once the standard is adopted. Standards organizations have IP policies that try to prevent this, but it’s very hard to do. But I don’t see any sign that 3Tera is doing this.

It’s kind of a “damned if you do damned if you don’t” situation for 3Tera. If they don’t have an implementation they are accused of “design by committee” and standardizing too early. If they do then they are accused of trying to game the system towards their solution.

In addition, seeing how stacked that deck is against small companies in standards bodies, I am willing to give them plenty of slack. It’s one thing to criticize Microsoft for trying to impose their proprietary specs as standards, it’s another to go after 3Tera for the same.

Note that I don’t know enough about Cloudware and ADL to actually have a strong opinion about the technical value of their proposal. But the fact that they base it on their implementation seems natural to me.

And don’t worry, they won’t get away with it anyway. Some technologies take the world by surprise such that the early , obscure standard becomes dominant (because no-one was paying attention when they got set, e.g. by the time big vendors realized the web was a big deal it was too late to replace HTTP by a “better” protocols). But utility computing is too high-profile by now for this to happen. Not to mention that it is too tightly linked to existing IT management technologies (mainly IT automation).

As I like to often point out here, what we have here is a complex adaptive system doing its thing. The overall software ecosystem, and cloud computing markets specifically, require many iterations to produce an agent that survives, much less thrives, in this highly competitive environment. Traditional standards bodies play a role in all of this, as does open source.

Perhaps the big winners in the “de facto standard” world are the finished, tested protocols (including programming languages and their runtimes) that anyone can use and develop to from the get go. See RSS, REST, SOAP, JavaScript, Java, etc.

That being said, what bothers me most about Cloudware is the seemingly blatant attempt by 3TERA to base the standard around their architecture and protocols. I am concerned that Cloudware adoption will actually–for example–force Amazon to do a ton of work to comply, which seems odd to me since AWS has many times the mindshare and marketshare for HaaS than 3TERA.

I applaud the idea that someone should get started, but pre-announcing the effort, then freezing out other vendors until the reference implementation is based on your product, seems a little self-serving to me. As I wrote in my post, either open source AppLogic (and share the implementation), or create Cloudware as a framework for AppLogic itself, and *then* begin the discussion about how to create a standard based on any useful protocols, not the implementation itself.

(By the way, you may not be able to tell from this comment, but I am actually generally a big fan of what 3TERA has accomplished from a marketing perspective. I just have issues with the Cloudware initiative.)

On another note, I agree with William that should a standards body get to work on anything in this space (even something wrapped up nicely in a pretty bow), the big guys are going to throw their entire “diplomatic” muscle at that body, and the discussion will quickly become a chess game of competing interests, permanently morphing such a proposal beyond recognition. It will take years to create something agreed upon and generally implemented, ala WS-*.

Answer: None of them had Java bindings. Who the heck wants to program Web sites in C? Those were bindings to Web Server Extensions, not a database-backed website.

While we’re tripping down memory lane, here’s my recollection of how stuff shaked out (I was a fresh college student in those days). Servlets, if anything, were a reflection of NetDynamics’ approach to application servers circa 1997. Netscape’s LiveWire was another useful attempt (they even had Comet-like push HTTP!) and coulda grown if JavaScript interpreters were faster and more stable and they wanted to build a multi-vendor community around it (they didn’t). Then Netscape bought Kiva and, well, did nothing to drive adoption of either.

FastCGI could have been the answer, but I think the problem was twofold: a) CGI generally was felt to be hackish; scripting languages weren’t taken anywhere near as seriously then as they are now, b) implementation stability; FastCGI had (and still has!) a habit of taking down the web server when the module crashes. I surmise this is because it doesn’t have the isolation that, for example, Apache mod_* memory pools give you, but I’m not completely sure.

Java was the fastest adopted language in computing history, as it got wrapped up in the whole Internet wave. Not that Java was perfect, but more what it represented: the first sign that the web browser was the new “everything”, emancipation for developers from Win32, MFC or Borland OWL, and VB….

If Systinet was sold for 105M it wasn’t because of UDDI, but rather because of 1) the ecosystem of vendors we built around the Systinet Governance Interoperability Framework (GIF) for which UDDI served as a key building block; 2) by being the leading registry vendors (we oem’d to BEA, Oracle and Tibco); 3) by defining and being the first to deliver a SOA Governance framework using GIF, UDDI, and great product capabilities in the areas of contract management, policy management and the like; and 4) GREAT marketing. That being said, we WOULD NOT have been successful had we not emphasized openness and standardization and executed accordingly. For more on this see “http://soaguidebook.com/chapters.html#chapter3″ (shameless plug).

On the matter of “Standards need OSS implementations”. These issues are entirely and utterly orthogonal. OSS has very little to do with standardization - quite the contrary! I’ve seen too many exploit OSS as a way to get around standardization. It’s not to say that OSS cannot contribute to standardization, but as is the case for BPEL, BPMN, BPEL Extensions for People and WS-HumanTask - areas of standardization I’m currently involved in - OSS has been contributing very little. OSS is a business-model for +95% of participants. Please don’t confound OSS with standards - that would be a disservice to the standards community.

I am not debating your point (with which I tend to agree) as much as pointing out that history is a messy business… Many factors interlock (like differing programming languages fortunes in this example). Did java rise because of servlet or did servlet rise because of java?

I would note, however, that those innovations rely on a standard that had “available source” but not “open source” until very recently. Those standards were the Java SE libraries and Java Servlet APIs. Interestingly, these were not hammered out by committee, but were one of those “right time & place” successes that a) had working code behind them, b) had Sun’s force of will behind them to keep them stable, and c) were eventually adopted and managed by committee (the JCP) when they had matured enough. I see this approach being taken increasingly by Internet standards like Atom, Atompub, OpenID, OAuth, etc, and it seems to be reasonable.

At Jazoon, Roy Fielding gave a good keynote on the conditions in fostering a thriving community and “de facto standards”. His major point was that they require “an architecture for decentralized evolution”. He made the bold claim that the success of Linux, Apache httpd, and Eclipse actually had little to do with their open source nature, and much more to do with their architecture enabling modules, plugins, and the enablement of isolated evolution that didn’t require any influence or time commitment from the core team. Slides are availabile here.

But back in the days of e-speak, we had a fully open-source implementation and we thought that freed us from bothering to standardize the communication protocols. Then came SOAP/WSDL/UDDI and e-speak died… But that may not prove anything. For one thing, we had the code out but we failed to build a development community around it, which is a big difference.

On the Systinet/UDDI front, I still think UDDI’s mindshare and the fact that Systinet was the leading provider enhanced their valuation a lot. Even if at the product level the UDDI support was a small portion of the actual feature set. But what do I know. Luc, are you reading? Any comment? Any advice to Bert and his colleagues?

To use the UDDI example, there was a specification that was too ahead of its time. The vision was to be “public yellow pages”. But almost all public UDDI servers are gone now. The real problem was “governance infrastructure” and “interface interoperability”. UDDI had little to do with governance other than enabling categorization — it didn’t help processes. And we’re still running at that interface interoperability fence. So, UDDI devolved into becoming a plugin to lookup services via developer IDE’s or service buses. Yet most developers (and servers) can also just use RESTful discovery (i.e. the ?WSDL query string at a service endpoint) - no specialized protocol required!

Did it increase Systinet’s valuation? Certainly, yes, in the early days. By many millions by the time Mercury bought them? Likely not. By that time, UDDI was, at best, a checkbox feature to provide a modicum of comfort that a customer wasn’t totally locked in to some kind of proprietary metadata repository (which they were, if it was to do anything useful). Systinet’s value was mostly that it built useful, extensible, and popular management applications — completely independent of UDDI, except, again, as a checkbox of modest “interop? let’s not lift that rock kthx!” comfort.

It’s one thing to be open and flexible — the point behind ECML, EDML, [insert your description or markup language here] etc. It’s another thing to formalize agreement around these things — hard when we participants don’t even necessarily agree on our shared concerns, since the area is so new. :-)