incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
Subject Re: [VOTE] Accept Glasgow into Incubator
Date Thu, 03 Aug 2006 22:03:38 GMT
-1

I think that this project is premature until the spec is in an open,
inclusive process or at an acceptable standards body with compatible
licensing terms. I would embrace this project were it so.

The project is supposed to be implementations of a "standard protocol"
but the protocol in question is proprietary and is under the control of
a group of companies whose employees make up the initial committer list.
It is impossible for individuals to join the protocol specification
body, and even then the means of decision making is not specified.

While it is a proprietary, closed-group protocol it cannot be called a
standard, and the project is, in fact, implementing a protocol under
the control of a subset of the employers of the contributors to the
project.

If the protocol were being developed under an open, inclusive process
which was compatible with how Apache works in general (which includes
processes in standards bodies which conduct business in that way, or
which have established sufficient reputation to allay these worries) I
would be very much in favor of this proposal.

-Brian


On Aug 3, 2006, at 9:52 AM, Cliff Schmidt wrote:

> I believe all open questions about the Glasgow proposal (originally
> submitted as "Blaze") have now been addressed enough to call a vote
> for accepting the project for incubation.
>
> Therefore, as the champion of this project, I am calling a vote.  As
> usual, the binding votes will be those case by Incubator PMC members
> (since the project is requesting sponsorship from the Incubator PMC);
> however all participants on this list are encouraged to vote if they
> have a strong feeling one way or another.
>
> The traditional 72-hour voting period would end during a weekend for
> most timezones; so I propose extending that by an additional day, with
> the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see
> http://www.timeanddate.com/worldclock/fixedtime.html? 
> month=8&day=7&year=2006&hour=17&min=0&sec=0&p1=0)
>
> Please vote on the Glasgow proposal, as described below, which can
> also be found at:
> http://wiki.apache.org/incubator/GlasgowProposal?action=recall&rev=1.
>
> Note the old wiki page (with the full history of changes since the
> original proposal) can be found here:
> http://wiki.apache.org/incubator/Blaze
>
> Cliff
>
> ----
> = Glasgow Proposal (renamed from Blaze) =
>
> == RATIONALE ==
> Glasgow provides multiple language implementations of the Advanced
> Messaged Queuing Protocol (AMQP) specification and related
> technologies including PGM, transaction management, queuing,
> distribution, security, management and heterogeneous multi-platform
> support for messaging (links to these specifications are in the
> "Initial Source" section of this proposal.)
> Glasgow's overall goal is to create an open and interoperable
> implementation for messaging which implements the emerging AMQP
> specification, in keeping with the philosophy of the Foundation. This
> implementation will provide a messaging solution that will be language
> and platform agnostic by using a well defined wire specification.
> Providing both libraries for the framing and protocol in addition to
> brokers in both Java and C/C++ allows for integration with Apache and
> non-Apache projects in a manner that facilitates heterogeneous
> deployment with full interoperability for SOA & distributed systems.
> The seed code for the project will consist of in-progress C/C++ and
> Java implementations of the AMQP specification that we intend to
> continue development on in conjunction with other Apache communities.
> More information on the scope of the seed code can be found in
> subsequent sections of this proposal.
>
> == CRITERIA ==
> === Meritocracy: ===
> The Glasgow committers recognize the desirability and necessity of
> running this project as a full meritocracy; indeed, the scope of the
> project's technical aspects are so varied that we find it hard to
> envision success any other way. One of the most important lessons that
> can be derived from the historic evolution of middleware is that
> specifications architected in isolation from real usable code that has
> been developed to solve tangible, real world problems or amongst a
> narrowly restricted list of contributors often do not see widespread
> adoption. Our goal in crafting this implementation and providing our
> learning to the specification team is to develop the best possible
> language agnostic advanced message queuing platform.  We understand
> that in order to do so, we will need to engage all interested  members
> of the community and operate to the standard of meritocracy that
> characterizes successful Apache projects.
>
> === Community: ===
> The project's primary objective is to build a vibrant community of
> users and active contributors.  Although Glasgow is not based on an
> existing open source community, many of the initial contributors have
> experience participating in and building other open source
> communities.  Several of the contributors have previously participated
> in Apache communities. We understand that Apache's community
> governance protocols are a unique contributor to the success of
> Apache's project communities and we are eager to learn from our
> Incubator mentors so that we can evolve Glasgow into a healthy and
> sustainable community.
> === Core Developers: ===
> Most of the initial committers are members of Red Hat, IONA, and JP
> Morgan Chase's (JPMC) development teams. Additional developers will be
> added through the Apache community process.
> === Alignment: ===
> An initial implementation has been written in Java and C++, which will
> be refactored into this project to form the initial code base.  We
> have had a few exploratory conversations about integration with
> individuals of other communties such as Apache Geronimo, Tuscany,
> ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards
> future collaboration with these communities. Our current
> implementation makes extensive use of projects from the Apache Jakata
> Commons, Mina and other Apache infrastructure projects. A
> compatibility binding for JMS also exists. It is however important to
> note that this is NOT a JMS project and aims to solve a different
> problem space, providing language and platform independent and
> interoperable messaging, driven by a protocol specification which may
> ultimately be commoditized in hardware.
>
> The scope of the project is broader than just Java and C++ as the
> project will also look at providing bindings in other languages such
> as PHP and Python.Additionally, bindings have already been created for
> test automation.
> As Glasgow's broad goal is to create a standardized, widely available,
> and  interoperable messaging solution based on the AMQP protocol,
> there are numerous potential collaboration opportunities with many
> other Apache projects including:
> * Transport support for Geronimo
>  * Interoperability integration with ActiveMQ(JMS)
> * Integration with Axis for SOAP messaging over an asynchronous  
> transport
>  * Language/platform neutral interoperable messaging for projects
> like Synapse and ServiceMix
>
> == AVOIDING THE WARNING SIGNS ==
> === Orphaned products: ===
> The initial code submission is based on active code developed and we
> believe that through its continued evolution in an open community will
> lead to a stronger, more widely accepted foundation for development of
> middleware and be valuable to many other Apache and community
> projects.
> === Inexperience with open source: ===
> Many of the initial committers have experience working on open source
> projects and several are committers on other Apache projects. Each of
> the companies involved in the initial submission has prior success
> building or contributing to open source projects. Moreover, some of
> the initial companies involved focus exclusively on developing open
> source software.  This depth and diversity of experience fosters a
> deep understanding of managing and running open source projects.
> === Homogenous developers: ===
> The current list of committers includes developers from several
> different companies who are geographically distributed across the U.S.
> and Europe. They are experienced with working in a distributed
> environment and with resolving technical differences outside the scope
> of a common employer.
> === Reliance on salaried developers: ===
> Most of the initial developers are paid by their employers to
> contribute to this project; however, this submission includes
> employers with track records for ongoing investment in open source
> communities (including Apache, Eclipse, ObjectWeb and Fedora).
> === No ties to other Apache products: ===
> As described in the Alignment section,this framework already leverages
> existing Apache projects. by making use of  other Apache projects for
> infrastructure building blocks. The initial codebase will be licensed
> under the Apache License 2.0.
> === A fascination with the Apache brand: ===
> The committers are intent on developing a strong open source community
> around what we hope will be a best-in-class, enterprise-grade high
> performance messaging framework.  We believe that the Apache Software
> Foundation's emphasis on community open development makes it the most
> suitable choice for such a project. We understand that the Apache
> brand has become synonymous with the values of quality, meritocracy,
> and community, and we endeavor to make our project worthy of such an
> affiliation. We also commit to working proactively with the Public
> Relations Committee to ensure that any marketing or promotional
> activities we pursue are in compliance with the ASF's policies.
>
> == SCOPE OF SUBPROJECTS ==
> The initial contributors envision an active community of related
> projects sharing a common of commodity and interoperable middleware
> but targeting specific technical areas:
> Glasgow will be seeded with several projects based on donated material
> (see the next section):
> * a Java implementation of the wire level framing
> * a C++ implementation of the wire level framing
> * a Java implementation of a broker
>  * a Java implementation of a JMS interface
>  * a C++ implementation of a portability layer, which will be
> refactored to be pluggable
>  * an implementation of the broker with will be refactrored into C++,
> for existing work and possible use of GCJ
> To assist in community building, the committers have identified
> several key technology areas that will allow new contributors points
> of entry to actively engage in the project. These include:
>  * integration with other Apache projects (Tuscany, ActiveMQ,
> ServiceMix, Apache Axis)
>  * integration with security and both local and distributed  
> transactions (XA)
>  * support heterogeneous API bindings in C, C++, Java, PHP, Python  
> and BPEL
>  * support for cross memory or RDMA transports
>  * support for in process IPC clients or IPC transport bindings
>  * support for broadcast and relay from PGM <--> AMQP
>  * integration with payload marshilling toolkits
>  * Declarative policy based API's
> These initial projects are intended merely as starting points and
> should not be taken as bounding the scope of the Glasgow project as a
> whole. Some other potential projects may include:
>  * Integration with rich middleware frameworks (such as Celtix or  
> ServiceMix).
> * Support and integration of Security.
> * Management tools.
> * Support for additional class frames such as tunneling
>
> == INITIAL SOURCE ==
> A group of companies are developing a set of specifications relating
> to the creation of commodity enterprise class messaging, collectively
> called Advanced Message Queuing Protocol (AMQP). In progress versions
> are available at:
> * http://www.envoytech.org/spec/amqp/
> * http://www.iona.com/opensource/amqp/
> * http://www.redhat.com/solutions/specifications/amqp/
> * http://www.twiststandards.org/tiki-index.php?page=AMQ
> * http://www.faqs.org/rfcs/rfc3208.html
>
>
> The initial contributors have been developing Java and C++ code bases
> (licensed under the Apache License 2.0) which implement aspects of
> these specifications, and intend to donate it to Apache. The current
> working svn is available at:
> https://etp.108.redhat.com/source/browse/etp/trunk/blaze
>
> Although the Glasgow project expects to bootstrap using these
> materials and in the case of specifications, to provide feedback that
> will be incorporated into their ongoing development, we expect and
> encourage the open source community to take the project in new
> directions not envisioned by them to create a world class
> implementation of the AMQP specification and related technologies.
>
> == Interactions with the specifications ==
> The specification is being developed by group of companies, under a
> contract that requires the resulting work to be published to a
> standards body. This model has been chosen to assure that anyone that
> contributes to the specification grants a copyright and patient
> license to all contributions made to the specification on every
> publication (draft or final). This ensures that the specification will
> always be open and implementable by anyone without royalties or
> commercial limitations. We feel that this is a very strong model for
> keeping this work entirely open and will fit well with the Apache
> project enabling innovations to pass in both directions across the
> extended community.
>
> Dealing with feedback from the Glasgow project to specifications
> It is key that the best implementation and specifications be created
> based on technical merit and practicalities for adoption by both the
> parties developing the specification and the committers within the
> Apache community. Given this, one of the important aspects is how
> issues discovered during the development of this implementation are
> incorporated back into the specifications.  The following feedback
> loop exists to ensure that any specification input incuding the
> Glasgow community can have their feedback incorporated into the
> specifications.
> === MECHANISMS FOR FEEDBACK ===
> a.) In the same way anyone can issue a JIRA on any Apache project
> having signed the Apache CLA, anyone can issue a "JIRA" to the
> specification working group through the RLA (Reviewer License
> Agreement). This agreement provides a license to that IP so that the
> specification team can incorporate it and the specifaction as they
> like and the specifications can remain entirely open and royalty free.
> b.) In the same spirit of Apache, if an individual has shown
> understanding of the project and substantive contribution to the
> specification, a vote based on technical merit and understanding of
> the goals of the work can be initiated to have that parties Employer
> join the specification working group. On such acceptance the employer
> is required to sign an agreement to make sure that employer also
> grants the ongoing and consistent licenses to the work as posted in
> specifications.
>
> The Reviewer License Agreement (RLA) can be viewed from the AMQP
> specification page of any of the members as listed above.
>
> == ASF resources to be created ==
> mailing list(s)
>  * glasgow-dev
>  * glasgow-commits
> Subversion repository
>  * https://svn.apache.org/repos/asf/incubator/glasgow
> Jira
> * Glasgow (GLASGOW)
>
> === INITIAL COMMITTERS ===
>  * Rajith Attapattu (Red Hat)
>  * Mark Atwell (JPMC)
> * Bela Ban (Red Hat)
>  * Bhupendra Bardwaj (JPMC)
> * Alan Conway (Red Hat)
>  * Tejeswar Das (IONA)
>  * Ovidiu Feodorov  (Red Hat)
> * Tim Fox (Red Hat)
>  * Paul Fremantle (WSO2)
>  * Eoghan Glynn (IONA)
>  * Robert Greig (JPMC)
>  * Chamikara Jayalath (WSO2)
> * Sam Joyce (IONA)
>  * John O'Hara (JPMC)
> * Frank Lynch (IONA)
>  * Marnie McCormack (JPMC)
>  * Martin Ritchie (JPMC)
>  * Rafael Schloming (Red Hat)
>  * Archit Shah (Red Hat)
>  * Stephen Shaw (JPMC)
> * Gordon Sim (Red Hat)
>  * James Strachan (LogicBlaze)
>  * Manik Surtani (Red Hat)
> * Paul Taylor (IONA)
>  * Carl Trieloff (Red Hat)
>  * Kim van der Riet (Red Hat)
>  * Steve Vinoski (IONA)
>  * Sergey Yedrikov (IONA)
>
> === APACHE SPONSOR ===
> The Glasgow team will make the submission to the incubator as the
> sponsor for incubation.
>
> Champion
> * Cliff Schmidt (consultant to Red Hat)
> Mentors:
>  * James Strachan
> * Cliff Schmidt (consultant to Red Hat)
>  * Paul Fremantle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message