On 3/21/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
Hi, I am glad you brought this point up. You mentioned about constant confrontation between two sets of people. I would say, unfortunately, this has been caused by a lack of diversity in the community. I hope most of these confrontations are based on technical differences. For the first group, who I understand all work for a specific vendor, the push has always been just on simple spec compliance, with no emphasis on value adds, end user experience etc. I am not saying that spec compliance is an inconsequential issue; however, there are other issues that are as important. To give an example, some of the work that has been happening on distributed heterogeneous federation is something which I think is a key differentiator for Tuscany. This has been discussed heavily on the list, and unfortunately only three of the committers, who don't work for a specific vendor, that took any interest in this discussion. I sincerely hope the technical direction within Tuscany is not purely shaped by a given vendor's aspirations for getting their product suite SCA-compliant. Otherwise, independent committers like me would be wasting our time on this. I would say we need to generate better community interest and bring in more independent committers, so that there is a better balance on technical debates. Unfortunately, these constant conflicts have been putting people off. I don't think the differences are irreconcilable; however, there should be a willingness from both sides to have an open discussion, leaving other vested interests out, purely based on what is best for us as a community to build Tuscany. Thanks Meeraj -----Original Message----- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 1:31 PM To: tuscany-dev@ws.apache.org Subject: Revolutions or a Mess!! Folks, I don't really like what's going on. Too much conflicts between people. Whatever be the issue of the day, I see 2 sets of people in constant confrontation. The constant branching/merging is not healthy or productive. Is there any effort or hope of reconciliation or should we start looking at other options? Thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. ***************************************************** You can find us at www.voca.com ***************************************************** This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi
I'm looking at this as someone who has been nibbling away at the edges of the java implementation for a while. I'm not currently a user neither have I been a full on developer of the java code. I've spent my time working on a PHP implementation of SCA (or at least a simplified version of SCA) and on the Tuscany Native SCA implementation. I guess my personal motivation is to understand how SCA is realized in more that one environment and how they play together. For that reason (and because it's pretty cool stuff) I am interested in the success of the Java implementation and have started getting involved. Primarily I want to see SCA be accepted as a useful tool in all of its guises. If we only support a small subset of our potential users with SCA then we are not really living up to the promise of SOA. For this to happen I think we need people to actually use the software, we need them to feed back requirements, problems, enhancements etc and we need to encourage them to get involved directly in the community. I realize that Tuscany is incubation and we may be looking for the tech savvy user but we can't just wish for this. To make this happen we need an effective development environment where working software can be released regularly in a form that is consumable by users with a wide variety of requirements. It's great that we get to build interesting stuff but we really don't do ourselves justice if people can't download and run it easily and update it regularly. Looking at the mail list I see people trying to do good work in a project they believe in. By careful design we have a runtime with a core and extensions which build on the core. The frustration I see people express is, I believe, primarily around stability and consumability of all of the various pieces and also understanding how they are intended to work together. A lot of work has gone into making the software as a whole more consumable in terms of the way parts of it are released but, as a relative outsider, I don't see a consensus on how the project as a whole reaches the goal of being able to deliver regular drops of quality code and, more importantly, how development happens between these drops that encourages the innovation that the project needs. Maybe I am wrong and there is concensus (I can certainly see discussion on the list from last year about his whole subject) but I don't see it being put into practice across the board. Why is this? This is ground I think that needs to be revisited. It's natural in projects that people have different priorities. As a project we have a baseline of implementing the SCA specifications but to get people interested we have to add some value over and above that. There are lots of people doing SOA infrastructure projects. What is our differentiator? Having said that, value I want to add may not be interesting to others involved. The really great thing about the work done to date is that we seem to be on the brink of being able to support this readily, i.e. the core/extension split means I could go off and construct new function which nobody else is interested in but which will not affect them in any way whatsoever. Has this work reached its conclusion? What is the smallest set of function we can build that is common across all users? Again we might be there, I don't know, I'm not qualified to answer that today as I've not read every mail on the subject. I would say that its always a good sign if we can agree together what to throw away, particularly if it leads to a simpler solution. Agreement on the state of play here is important, in my view, as it sets the tone for all future development. This is not particularly relevant to this thread but if anybody were to ask, these would be my priorities (in no particular order) Useability: consumability, ease of use, good samples documentation, great first use experience in many environments from single standalone helloworld program for the novice to the full function federated node support. Variety: of component implementation, bindings, databindings, runtimes etc. Heterogeneity: cooperation between the various runtimes. It feels to me like it would be a good exercise to get some of these out on the table again, debate them and have people decide what they want to work on. I admit I am a fan of the shopping list approach to development and I recognize that others are not. Given that Dims asks about what he perceives as a divide in the community I think it would be good to understand why that is so, what characterizes the perception in terms of everyone's technical interests and objectives and how we fix any issues if any surface. I really believe that SCA is a great opportunity for us all and that what we really need is to encourage good honest technical debate. In particular I'd be keen to understand why there are numerous technical mails that arrive on the list that are not as actively debated as you might expect. Is this just because the areas in discussion are not well understood by everyone? Anyhow, just some observations and questions. Reading back it looks like I'm suggesting lots of navel gazing here. As techies we would probably all rather be heads down building stuff. The extensible nature of SCA means that at some point we will likely be working on things that only a small subset of the community has an interest in or understands at a particular time. I don't think endless navel gazing is required however I do think we at least need to maintain a working consensus about the common threads of what we are doing otherwise it just won't hang together. Regards Simon