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

Reply via email to