BT

SOA Manifesto Released

by Mark Little on Oct 26, 2009 |

The Agile Manifesto has become a leading reference for agile software developers mainly for two reasons: it was written by thought leaders, and it's written in a very short and accessible format. The format highlights the core values of agile software development by stating what matters more out of two good things and then goes on to provides principles that explain and expand upon those core values. SOA has matured in recent years and recently a group of SOA practitioners/writers/authors saw fit to create a SOA Manifesto using the format of the Agile Manifesto in an attempt to similarly help the SOA community of developers and users. The SOA Manifesto was recently worked out at the 2nd International SOA Symposium in Rotterdam. Prior to meeting in Rotterdam the authors prepared their own draft manifestos based on their own insights and that of their peers.

As reported elsewhere the discussions at times were quite intense, as could be imagined with something as important and yet often ill defined as SOA. However, consensus was reached, though as with any working group not everyone got everything that they wanted. Although the discussions in Rotterdam were intense at times, in the end the group came to a surprisingly high level of consensus. The manifesto was first announced at the SOA Symposium and this announcement was recorded:

In the short time after the manifesto was published there have already been quite a few comments, some positive and some negative. In order to follow the original Agile Manifesto style, the SOA Manifesto is short and to the point. However, this may also lead to a weakness in the presentation. To describe a lot of information in few words will inevitably lead to statements that are open to different interpretations. For example one can interpret the statement “Intrinsic interoperability” as being a strong suggestion to buy an ESB and base all the interoperability on its standardized capabilities and formats. However, it would seem that during the discussions in Rotterdam the members of the group rather seemed to be thinking about designing interoperability into the services from the very start. The latter interpretation of this statement also plays nicely with the principle that states that products cannot give you an SOA.

If the SOA Manifesto is to become widely accepted the SOA community must first agree upon how these statements should be interpreted. If not, the discussions will never come to an end and the SOA Manifesto will not be able to contribute to filling the empty void of the SOA community: a shared understanding of the core values of SOA. As such it is important that all of the Manifesto is read in its entirely and the authors perhaps follow up with an in depth discussion of what they were trying to achieve. Without this happening in quite short order, it is possible that the Manifesto could become sidelined by much more vocal discussions around it that are perhaps based on misunderstandings.

Note, content co-authored by Herbjörn Wilhelmsen.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Sorry Mark, but thumbs down by Jean-Jacques Dubray

I am not sure why somebody of your caliber would think that signing such an empty document would bring any value to our industry or the SOA community in general. In 2009, it is kind of sad to think that any IT architect would feel empowered to share this document with the business or with his or her colleagues.
If the SOA Manifesto is to become widely accepted the SOA community must first agree upon how these statements should be interpreted. If not, the discussions will never come to an end and the SOA Manifesto will not be able to contribute to filling the empty void of the SOA community: a shared understanding of the core values of SOA.

Is that a threat? Are you telling us to adopt the SOA manifesto ... or else?

Day in and day out we see people having a general understanding of SOA, they don't need a Manifesto (frankly this masquerade is reminiscent to the practices of the former Soviet Union), what these people need are detailed practices of how to make SOA successful. Unfortunately no single member of this group of markitects seem to have any understanding nor compassion for filling -that- gap. SOA fails in the detail, not in the large. SOA fails when you don't understand versioning, when you don't understand where orchestration fits, how assemblies and bi-directional interfaces can be used. SOA fails when you have no or an inappropriate modeling architecture. SOA fails when all your services are at the data access layer level, SOA fails when all you do is synchronous, RPC or CRUD oriented. SOA fails when you don't understand the role of events in SOA. Finally SOA fails when you don't understand how to achieve loose coupling. These are not just words, they are deep architecture concepts that everyone in IT needs to understand. We have a duty to deliver this knowledge. You have that duty too. This is just a question of courage. Our industry needs real help, no more fluff. If you want to discredit SOA, our industry and the vendors that participated, please continue this 'work'.

Jeff Schneider (disclosure, Jeff is my boss, but he knows I always speak my mind) had by himself written a far better document in 2007 (A poll on the current document is available here: www.soamanifesto.com). I am not sure we needed a second one today.

Re: Sorry Mark, but thumbs down by Steve Ross-Talbot

Jean-Jacquues,

I am saddened by your thumbs down. I took much of what had been offered in the previous thread with me. And we did use all of it in one way or another. The Manifesto is, by design, short - as Mark has said. It will take time for all of us, including even you, to add more detail to it.

It is not a recipe for success but rather it starts the process of framing success. As such it is by use that it will find it's merit. It is always easy to pick holes in things it is much harder to dive deeper and find the real meaning. That I think is the process in which we are all now fully engaged.

Cheers

Steve T

Re: Sorry Mark, but thumbs down by Jean-Jacques Dubray

Steve:

it is not really a question of what the Manifesto is, it is really a question of what does our industry need, today in the fall of 2009? Does it need this document?

There is nothing I can fundamentally disagree with in your Manifesto, but yet again we are conveying that the best vendors and pundits can deliver to help IT fulfill its difficult mission is alas totally empty and painfully useless. This is well inline with much of all the work that started in 1998 as "SOAP, WSDL and UDDI" is all you'll ever need to be successful. This is well in line with what was delivered with SOA-RM, SOA-RA and SoaML. The pompous ceremony surrounding the organization and release of this Manifesto simply reinforces that sentiment.

It can always be corrupted. by Francisco Jose Peredo Noguez

I think this very high lever manifesto is not a bad idea, but we need to remember that, because of the is very high level and abstract nature of manifest, they can easily be corrupted on practice.
Take for example the agile manifesto:

Individuals and interactions over processes and tools: It can be interpreted as an excuse to use crappy tools and avoid standardization of processes.
Working software over comprehensive documentation: It can be used as an excuse for not writing even basic documentation.
Customer collaboration over contract negotiation: Can be used as a excuse by customer, to avoid the costs of self examination, and act is if changing the rules had no consecuences .
Responding to change over following a plan: Excuse for not taking a moment to think about the consequences before we do something.

Same thing happens with the SOA Manifesto:

Business value over technical strategy: Excuse for using obsolete technology
Strategic goals over project-specific benefits: This one I can not think of a drawback, but I guess some will...
Intrinsic interoperability over custom integration: Great in theory but sometimes is just too expensive.
Shared services over specific-purpose implementations: Same thing, great in theory but sometimes just to expensive in practice.
Flexibility over optimization: Excuse for making things with bad performance
Evolutionary refinement over pursuit of initial perfection: Excuse for always leaving problems for later (some problems, if left for later, become so bad that just kill you, like a cancer)

Re: It can always be corrupted. by Jonathan Allen


Strategic goals over project-specific benefits: This one I can not think of a drawback, but I guess some will...


Oh that's easy. Where I work it is used all the time to ignore easily fixed bugs because they are not "impacting strategic goals". The fact that we can't work on the strategic projects because we are too busy dealing with production issues is lost on them.


Flexibility over optimization: Excuse for making things with bad performance


Not just designs with bad performance, but designs that are so "flexible" that fixing the performance issues are impossible.

Re: Sorry Mark, but thumbs down by Jonathan Allen

It is not a recipe for success but rather it starts the process of framing success.


That is complete and utter nonsense. Just as we don't need anyone telling us what color the sky is, we don’t need anyone to tell us the difference between successful and unsuccessful project.

What we need, in some cases desperately, is to know how to ensure our individual projects are successful. After a decade of flailing about, it is long past time to discard the hype machine and get down to work on the real issues.

Re: Sorry Mark, but thumbs down by Mark Little

JJ, is your reference link to "written a far better document in 2007" broken? It doesn't seem to work for me on Safari.

Re: Sorry Mark, but thumbs down by Mark Little

In case I'm not the only one who can't resolve it: schneider.blogspot.com/2007/10/enterprise-soa-m...

Re: Sorry Mark, but thumbs down by Mark Little

JJ, I think if you could see the individual manifesto's Steve and I brought to the table last week then you'd see a lot of similarities with what Jeff said a couple of years back. Of course you can't get everything you want in any committee driven activity, but I believe this is a start and hope that we'll see an evolution of it based on the positive critical feedback that we've been seeing so far.

Re: Sorry Mark, but thumbs down by Jean-Jacques Dubray

After a decade of flailing about, it is long past time to discard the hype machine and get down to work on the real issues.

I'll second that, and that too:
some problems, if left for later, become so bad that just kill you, like a cancer

Re: Sorry Mark, but thumbs down by tim pijpops

"Business value over technical strategy" => We learned from those agilists that we have to use the words "business" and "value" in the same sentence to be credible

"Strategic goals over project-specific benefits" => Never mind about delivering business value as early as possible. Instead, convince the business that they need an ESB to be "strategic"

"Intrinsic interoperability over custom integration" => Adopt our WS-* fantasy instead of proven technology

"Shared services over specific-purpose implementations" => Again, don't put yourself into trouble by delivering early, instead adopt a big-design-up-front approach and buy the illusion that you can design for reuse

"Flexibility over optimization" => With our BPM and ESB products, we promise you that business users themselves can change the processes (although we have never seen this happen in reality)

"Evolutionary refinement over pursuit of initial perfection" => Here's another one we learned from the agile manifesto, but don't forget to buy that ESB first, iterative and incremental development will be a lot easier afterwards

Re: Sorry Mark, but thumbs down by Stefan Tilkov

Tim, that's just entirely off. I couldn't care less about ESBs, BPM tools, or WS-* crap. Ask JJ. Yet I'm one of the authors.
I can understand when people criticize the manifesto for its vagueness – that's simple a side effect of compromising. To claim that this is a vendor effort for selling ESBs just totally misses the point.

Re: Sorry Mark, but thumbs down by tim pijpops

Stefan, that's exactly my point. I have a lot of respect for your work, and I do believe that you are one of the few authors with a vendor-independent vision on SOA. But in my opinion the manifesto is an excuse for the big vendors (how much of the authors are working for IBM, Oracle, MS, Tibco or Redhat?) to sell more of their products instead of solving the fundamental problems with the current state of SOA. Of course, that's perfectly understandable from their point of view, but it's more of a marketing attempt than a manifesto.
Anyway, each vendor will translate this vagueness into its own selling story, wich reduces the value of this manifesto to zero...

Re: Sorry Mark, but thumbs down by Mark Little

Those people who read the manifesto and see it as "big vendors trying to sell their wares" really should look into what was done in the meeting and how it was accomplished a little but more thoroughly (check out the number of blog posts that have arisen from those present). Speaking for myself and Steve, selling software solutions was the furthest thing from our minds. There's even a principle that states SOA is not something you can buy!

Re: Sorry Mark, but thumbs down by Dilip Krishnan

It is not a recipe for success but rather it starts the process of framing success. As such it is by use that it will find it's merit. It is always easy to pick holes in things it is much harder to dive deeper and find the real meaning. That I think is the process in which we are all now fully engaged.

+1, I can understand why the manifesto itself can be vague.

Also, I mean that in a good way; putting in checks and balances in the values, is pure genius! Case in point...
"Shared services over specific-purpose implementations" and "Strategic goals over project-specific benefits" on one end
vs.
"Evolutionary refinement over pursuit of initial perfection" and "Flexibility over optimization" on the other!

Signed!

Re: Sorry Mark, but thumbs down by Jean-Jacques Dubray

Mark:

again, I don't necessarily criticize the content, even the vagueness, the compromises, whether it is vendor driven or not, whether it was similar/opposing to Jeff's manifesto ... the question, the only question is can this manifesto help build credibility for our industry? If you are going to make so much noise, in such a pompous way, are you going to provide some signal as well?

The problem is that the Manifesto does not build credibility, it contains no signal at all. Again somebody from the business or some SOA skeptic who would look at all this and say, "guys you have learned nothing".

Eventually, the problem with vendor driven initiatives (including Stefan who sells REST) is that you have to accommodate everyone, the text must contains a view that is common to what every vendor sells. This is what happened for a decade now. Unfortunately, this intersection is empty, tragically empty. This has hampered WS-* (which was designed initially to kill ebXML, because Microsoft did not want to play in that standard, for whatever silly reason). You know too well what happened in WS-Transaction...

It is not until people of your caliber will decide that this Swiss approach to create industry wide "standards" that products come second (which was how ebXML was designed), that the intersection cannot be empty, that the signal must be much higher than the industry noise.

The real game changer would be an ebXML II initiative (not as a standard, but in its industry wide spirit) and if Microsoft or any other vendor wants to stay away, it can, this time around its absence will be meaningless because IT demands signal and will buy signal not noise. Until then you guys are just wasting our time because everyone in this group wants to create something that he/she can go back to his/her customers and say look, what I am trying to sell you makes sense, it is written in that spec. That is meaningless. We no longer need this kind of justification to buy a particular product. Nobody trust this kind of initiative to guaranty that a product does X, Y or Z.

Until then, I am not sure there is anything you can defend in front of IT and the business. do you think people are that stupid?

Re: Sorry Mark, but thumbs down by John Harby

I see the need for further definition of SOA. There was work accomplished by OASIS but this needs to be carried further. There is still confusion for the architect who is told or has decided to "implement SOA". In that vein I certainly applaud this effort. However, I am sure there is still much work to do.

I'm not entirely comfortable with the notion that a large organization should adopt "Architecture X" for their middle-tier and commit completely to that architecture. I was far more friendly with the registry approach over the ESB as I have written here before. Consider business intelligence as one example but there are many. I feel an organization will need to support several architectural tacks in their middle-tier and minimize the application of declarative services to only the absolute necessary such as security and monitoring, say.

Re: Sorry Mark, but thumbs down by John Harby

I would add that the rule of thumb I apply is "only involve a declarative service where it actually applies". We learned this the hard way with EJB.

Re: Sorry Mark, but thumbs down by Mark Little

JJ, I agree with some of your sentiments and like I've said, I see this as a first necessary step. I don't think people are stupid, and that goes for the Manifesto authors as well, who need to take on board all of the feedback.

Finally a nice, precise definition of SOA! by Ronald Miura

"Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation."

That makes me think about applying the pattern to other concepts:

"Resource-Oriented Architecture (ROA) is a type of architecture that results from applying resource orientation."

"Domain-Driven Design (DDD) is a type of design that is driven by the domain."

"Test-Driven Development (TDD) is a type of development that is driven by tests."

(sigh)

I also have a suggestion, a little rephrasing of the manifesto:


SOA Manifesto

Don't



PS: no, I'm not trying to give a smart contribution to the discussion ;P

I'm counting on the Manifesto for one thing... by Peter Pascale

An increase in visitors and submissions to SOAFacts.com. This is great news for SOA humorists everywhere, and we applaud the manifesto authors for reviving this horse.

Graciously awaiting your manifesto-related submissions,

SOAFacts.com editorial staff.

Multiple answers to the above comments. by William Martinez

Hello.
Mark: Although the manifesto is a great first step, it is of general consent that is needs more, and even it may need change. How do we accomplish this, support this? The document was created by a group of people, not actually sure chosen by whom, and thus may not represent the feelings or understandings of all SOAfarians.

The first challenge was to agree (the group) in those things. The second one is to sell the idea, and the product may need to me tuned up. We need to think on a way to do that.

Is there any other option apart from signing it or not? I haven't done it myself for two or three principles that I think are not good, no way. It may be more benefit from a nice and deep discussion of how to improve it.

Jean-Jacques: I do feel the first step is to have all of us in the same page. So, a Manifesto, or a definition, or anything that everybody (not just a group) agrees upon is required. So, it is not true, not at all, completely wrong, to think all people has a general understanding of SOA. See this and this to know what I see people believes.
In other words, doing nothing and letting people go running with scissors is not the solution. Believe me.

Tim: I was afraid of the people in the list since they worked for vendors. I said so. And not because they were deliberately trying to sell tools, but because they will believe the tools concepts were correct, and thus their agreement would not be good enough to be partial.
Now, if the manifesto is so vague, then we need something else. And if the tools are not right for us, we need to say so, why and how to solve it. I teach my students at university how to create a web service using no tool, then I gradually teach them to use tools. That way they understand what is a service, and what a tool produces.

John: Completely agree. SOA is not for everyone, as REST is not either. The first thing an architect needs to learn is to know when something is appropriate or not. That is why I dislike much the flexibility over optimization part. Both are quality properties that need to be balanced and a trade off carried on. Architecture 101, or the class I teach at University.

Francisco: I would not say corrupted. Miss-interpreted, maybe. Here I talked about that effect in Agile. That is why the manifesto needs more discussion.

Jonathan: Great one about the bugs!

Ronald: LOL. Please see my definition (in blog) and let me know if it lacks too.

Peter: Some are good ones, some others are REALLY bad. Made me cry.


William Martinez Pomares.
Architect's Thoughts ditto

Re: Sorry Mark, but thumbs down by John Harby

I applaud your efforts Mark. SOA is still very fuzzy in many minds. Although I don't agree on certain points in the current SOA offerings (such as ESB), I do see the need for further definition of SOA itself.

Re: Sorry Mark, but thumbs down by John Harby

Hey Stefan,

I hope someone can add for the consideration that one might want to use an ESR (Enterprise Services Registry) over the ESB. I think the BPEL stuff is useful especially in workflow scenarios that involve human interaction. I've witnessed many of these in practice, the insurance industry is one good place to look. Thanks for participating in the manifesto though as it's great to have someone with your views as a voice for the rest of us.

Thanks,
John

Re: Finally a nice, precise definition of SOA! by Jean-Jacques Dubray

@William: this kind of remark (which are perfectly justified) is precisely the reason why this document is not helpful. It does not mean the people didn't have good intentions, it is just I can't show it to anyone skeptic about SOA, because he or she is become more skeptic about it.

Re: Sorry Mark, but thumbs down by Mark Little

I applaud your efforts Mark.
Thanks John, but this was definitely a group effort. I hope that as a community we can build on this in a constructive manner too.

Re: Sorry Mark, but thumbs down by Mark Fisher

So the manifesto is not "a strong suggestion to buy an ESB". However, just today JBoss sent out an "SOA Strategy" ad that claims: "Enterprise Service Bus has been intrinsic to many SOA programs in recent years. There is a very high likelihood that a successful SOA program includes successful ESBs".

Sounds like JBoss thinks selling an ESB is pretty tightly-coupled to this SOA acronym after all... and *intrinsic*?... coincidence?

Re: Sorry Mark, but thumbs down by Oleg Zhurakousky

"Service-oriented architecture (SOA) is a type of architecture that results from applying service
orientation"
- is this a joke? It reminds me of something I heard as a kid while forced to watch Gorbachev's speech ". . . economy must be economical. . ."
I think part of the problem is that 10-15 years down the road we are still trying to centralize the concept that might not need any centralization. Manifesto describes the obvious. . . something that makes perfect sense to someone who has actually written software, who have worked on large distributed systems... Centralizing it around some catchy acronym only helps the vendors and marketeers to build useless and expensive products to sell. So how about redefining SOA as Severely Overused Acronym similar to BFF, LOL, ROTFLMAO etc. . . burry it in history and move one to something new? How about CSA - Common Sense Approach?. . ., because at the end of the day that is all you need.

Re: Sorry Mark, but thumbs down by John Harby

Thanks Mark. The names involved with the manifesto are indeed most impressive too. I'm sure this will be of great value and best wishes for developments down the road. The two concerns I have in this are:
1.) Can we support those who wish to use the registry pattern rather than the ESB with multiple buses where asychrony is required? I.E. an architecture refactoring of the declarative services into an "only when needed" approach.
2.) Can we develop coexistence patterns for other architectures such as a cloud intranet?

Re: Sorry Mark, but thumbs down by Jean-Jacques Dubray

Guys,

can we just move on on the ESB debate? Can we call an ESB a "ESC" (Enterprise Service Container) or just Service Container and be done with it? An ESC reinforces the separation of Interface from Implementation. Service Containers come in all sizes with different capabilities to wire the interface to its implementation. It is recommended that you always use a service container though you might not always use all the capabilities it provides. The reason being that traditional runtimes (mostly OO) never enforce this separation. They actually encourage the opposite through code generators. RESTafarians don't understand this either, just take a look at the annotations of JAX-RS. The "cool" architectural style is to bolt the interface to the implementation. This is what has been wrong for 30 years of distributed computing. This is probably what will remain wrong for the next 3 billion years.

SOA has 3 pillars: Governance, Forwards Compatible Versioning and the separation of Interface from Implementation. You'll never be successful at SOA without all three in place, hence, including an ESC.

Re: Sorry Mark, but thumbs down by Mark Fisher

Why do we need to replace it with yet another TLA (three letter acronym) at all?

I would go further and say that the 3-billion year problem is thinking about "service" and "operation" as the things to be exposed. Of course, the separation of interface and implementation is necessary, but that should be something to consider on the inside only. In other words, an "interface" is still too fine-grained to be a system endpoint. People that understand REST don't consider that annotated code the "interface". They think about the URI and the supported HTTP request methods.

Re: Sorry Mark, but thumbs down by Jean-Jacques Dubray

The only reason for using a different TLA is that "bus" does not represent the reality of Service Orientation nor does it represents the way people use an ESB. The "bus" topology is not service oriented.

Unfortunately in REST you have no other choice than bolting the interface to the implementation since "access" is coupled to "identity" by definition. Service Orientation had successfully broken this anti-pattern of composite system construction. The anti-pattern itself had already proven its powers with CORBA or JEE, but no, that was too easy, why not take a step back.

Thinking about URI and HTTP verbs is simply a text encoding of OO semantics. Anyways, this is not the topic of this thread. If a notorious RESTafarian can sign the Manifesto, it is probably a good indication that it has nothing to do with Service Orientation itself.

Re: Sorry Mark, but thumbs down by Mark Fisher

Service Orientation had successfully broken this anti-pattern of composite system construction.


Can you elaborate on that assertion?

The anti-pattern itself had already proven its powers with CORBA or JEE, but no, that was too easy, why not take a step back.


When hearing "Enterprise Service Container" I think of JBI, and from my perspective, that falls into the same category. How do you view "ESC" as not another manifestation of the anti-pattern?

Re: Sorry Mark, but thumbs down by Jean-Jacques Dubray

Mark:

I explained many times that Service Orientation has brought many innovative concepts to building composite information systems: pure message orientation, technology neutral data exchanges, bi-directional interfaces, Orchestration-based programming languages, forwards compatible versioning approaches, service assemblies...

All these contributes effectively to the separation of the interface from the implementation, by a large margin. Of course it requires that a) you understand why you need that and b) how these capabilities effectively separate the interface from the implementation.

It actually supports this separation so effectively that it enables orchestration. In case you have not noticed, all operations of a service (inbound or *outbound*) are wired into a single ochestration implementation. Just try to do that with REST or your favorite OO language. Because of complex bi-directional interface and I can now efficiently assemble services to perform a unit of work.

With REST? sorry, you get none of that, no bi-directional interfaces, no orchestration, no message orientation, but... it works really well with your favorite OO runtime, unless you prefer to CRUD all day.

Unfortunately, the JBI model and the early ESB vendors had to deal with the lack of standardization at the protocol level (security, reliable messaging, transaction...). Now that these specs are well established the topology is no longer the one of a bus, but the one of a container. ESB or ESCs expose services which can be invoked (of course also by services hosted in the same container), but the reality is that ESCs are the last mile of service orientation, they support the loose coupling between the service interface and the service implementation. Now if you want to believe that because it is called a Bus it implies a particular topology you can. But at the end of the day, and ESB today is just a Service Container. An SCA implementation is a Service container, a very smart one, WCF and Axis are too.

As long as you will bolt the interface to the implementation you will get the same side effects of the past whether you call it REST, CORBA or JEE. That is the problem, there is no smart encoding that can resolve that problem. You need a true separation of the interface and the implementation. Roy's REST works well in the browser-to-server context because the interface is projected into the browser and interpreted by a human. As soon as you move to a server-to-server context, you are back to where we were 20 years ago. These systems will be just as brittle.

Re: Sorry Mark, but thumbs down by Mark Fisher

I see your points, and it wasn't my intention to end up no the REST side of a debate actually... I was just commenting about the interface vs. implementation distinction being at a different layer. I personally think there is no *one size fits all* solution to integration, and the options involve tradeoffs. In my view, as long as the approach focuses on "service" it will not achieve the same degree of loose-coupling that can be achieved with a messaging approach.

Re: Sorry Mark, but thumbs down by Boris Lublinsky

Its not that anything is wrong in the manifesto. From my point of view, there is not much there at all - a set of statements, which can be interpreted any way you want it. And this discussion is a great testament to it. And here is another funny part. According to the manifesto:

Business value over technical strategy

is one of the main principles, and yet, the majority of comments are by deeply technical guys and are technical in nature

Manifesto Critiqued by jordan braunstein

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

37 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT