You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Adam Peller <ap...@us.ibm.com> on 2005/12/20 15:03:59 UTC
AJAX Toolkit Framework Proposal
AJAX Toolkit Framework Proposal
0. Rationale
While the term AJAX (Asynchronous Javascript and XML) has only recently
been coined, the underlying web standards and technologies (JavaScript
a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
Although the term is used in a variety of ways, AJAX typically describes
techniques towards developing interactive applications on the web client
including asynchronous messaging, use of XML grammar in client-side
applications, incremental page updates, and improved user interface
controls. AJAX applications combine the rich UI experience of programmed
clients with the low-cost lifecycle management of web-based applications.
AJAX has raised awareness of the high potential of web applications, it has
encouraged companies to adopt rich web-based interfaces over traditional
"fat" clients, and it has spawned development activity to create toolkits
and abstractions to make AJAX-style development easier and more powerful.
This is an important trend for open source. The client itself can be
composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
Konqueror, and does not require any particular operating system, helping to
make a more level playing field for all development. More importantly,
AJAX is back-end agnostic as transactions are done over HTTP. Keeping the
client open forces vendors to keep the communication channel open as well,
and this can only continue as long as the client technology keeps pace with
proprietary alternatives. The open, standards based communications channel
is what drives many technologies inside Apache, so success of the open
client is vital to Apache. The mission of this project is to encourage
innovation around enterprise-strength client runtimes and tools and build a
community which can select and nurture a select set which will be most
beneficial to the web.
0.1 Criteria
Meritocracy:
Apache was chosen for an incubator primarily because of the guidance the
community can provide. The two subprojects put forth are among the first
attempts to formalize this style of development. Additional ideas, tools
or entire runtimes may come forward and indeed would be welcomed to the
project, either wholesale as new subprojects or incorporated into the
existing code.
Community:
The contributed work was inspired by open source development but needs a
strong and diverse community to validate its mission and carry it forward.
A primary objective of the project is to build a vibrant community of users
and active contributors.
Core Developers:
All of the initial committers are members of Zimbra and IBM development
teams. All developers have worked on open source projects before and have
experience and understanding of open source principles.
Alignment:
Initial implementation consists of two sub projects.
The AJAX Toolkit Framework will provide a strategic framework for
Interactive Development Environments (IDEs) for the many different AJAX
toolkit offerings in the market. It provides a rich set of tools for the
AJAX / DHTML developer including: a JavaScript editor with edit-time syntax
checking; Mozilla web browser; integrated DOM browser; integrated
JavaScript debugger; and wizards and development aides tuned to specific
libraries and toolkits. The Framework is extensible to support other AJAX
toolkits and has a wizard-based tool to facilitate the integration of new
toolkits in the framework.
The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
Plugin extensions to Eclipse. It embeds 4 other open source components:
Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
4 open source components specified. They are incorporated to accommodate
Eclipse plugin architecture and distributed as-is by repackaging them as
part of the AJAX Toolkit Framework.
The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
framework, provides a rich client library, similar in style to traditional
object-oriented widget libraries like Eclipse's SWT. This toolkit hides
implementation details and browser quirks and makes web development more
accessible to the enterprise developer. It provides
* User interface development
* Network communications (both synchronous and asynchronous)
* SOAP programming
* XML document creation and manipulation
* UI event handling and management
For further information, please see the Zimbra AjaxTK whitepaper:
http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
0.2 Warning signs
Orphaned products:
The initial code submission is based on colloborative work between IBM and
Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
environment and provide additional enhancements. Both the companies believe
that taking a joint approach and making it available through open source
will make it widely accepted and create a community and unify Industry
momentum to consolidate requirements and accelerate community growth and
enhance the toolkit to ease development of AJAX applications.
Inexperience with open source:
Both the companies and several of the commiters are very experienced in
Open Source environment. All efforts will be made to ensure that the work
done and momentum will be in strict adherence to open source guidelines.
Homogenous developers:
The current list of committers includes developers who are geographically
distributed. They are experienced with working in a distributed
environment, and with resolving technical differences.
Reliance on salaried developers:
All of the initial developers are paid by their employers to contribute to
this project and the employers track records for ongoing investment in open
source communities well known.
No ties to other Apache products:
The initial codebase will be licensed under the Apache License 2.0.The
dependencies on other external projects are defined in the alignment
section. While there are no direct build dependencies on other Apache
projects, the development of AJAX clients will often be driven by Apache
middleware and will have a positive impact on the open source movement as
described in the "Rationale" section.
A fascination with the Apache brand:
The committers are intent on developing a strong open source community. We
believe that the Apache Software Foundation's emphasis on community
development makes it the most suitable choice.
1. Scope of the subprojects
The subprojects will include development tools necessary to encourage
browser-based, AJAX-style development for individual users as well as in
the enterprise. The tools will be driven by an extensible IDE Framework
and may include utilities to assist in code development, analysis, and
testing. The tools will be adaptable to different AJAX runtimes, some of
which will also be subprojects in the incubator. The initial submission
includes an IDE and one such runtime.
These initial projects are intended merely as starting points and should
not be taken as bounding the scope of the project as a whole. Some other
potential projects may include:
* WYSIWYG tools for building AJAX-style interfaces
* Declarative grammars or abstractions for AJAX programming
* A common data model to facilitate efficient server communication with
Javascript or DOM access
2. Identify the initial source from which the subprojects are to be
populated
AJAX Toolkit Framework was developed at IBM as a set of plugins based on
the Eclipse Framework and WebTools Project. Zip files containing snapshots
of CVS directories are provided with this proposal at
http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
The Zimbra AjaxTK is available today in open source, and can be downloaded
as part of the Zimbra Collaboration Suite (choose the source code version)
at
http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
toolkit code is provided at http://www.apache.org/~rubys/ajax/Ajax.tar.gz
2.1 External Dependencies of the project
AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
Plugin extensions to Eclipse. It embeds four other open source components
Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
four open source components specified. They are incorporated to accommodate
Eclipse plugin architecture and distributed as is by repackaging them as
part of AJAX Toolkit Framework. In the future any AJAX toolkit that is to
be supported can be included as another plugin.
3. Identify the ASF resources to be created
3.1 mailing list(s)
* ajaxtk-ppmc
* ajaxtk-dev
* ajaxtk-commits
* ajaxtk-user
3.2 Subversion repository
* [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
3.3 Bugzilla
* AJAXTK (AJAXTK)
4. Identify the initial set of committers:
* Craig Becker
* Leugim Bustelo
* Andrew Clark
* Conrad Damon
* Ross Dargahi
* Becky Gibson
* Javier Pedemonte
* Adam Peller
* Roland Schemers
* Donald Sedota
* Parag Shah
* Greg Solovyev
5. Identify Apache sponsoring individual
We request that the Apache Incubator PMC sponsor the AJAX Toolkit Framework
as an
incubating project, with the eventual goal of graduation as a TLP. The
initial contributors feel the scope of the project doesn't clearly
overlap with any existing TLP, and is broad enough to justify eventual
TLP status.
Champion: Sam Ruby
Mentors: ??
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
Sanjiva,
My bad. I just meant the AJAX toolkit portion of Zimbra.
-adam
Sanjiva
Weerawarana
<sanjiva@opensour To
ce.lk> general@incubator.apache.org
cc
12/21/2005 03:33 Andy Pflaum
AM <an...@zimbra.com>, Chris
Boni <ch...@zimbra.com>, David
Boloker/Somers/IBM@IBMUS, Krishna
Please respond to Akella/Austin/IBM@IBMUS, Ross
general Dargahi <ro...@zimbra.com>, Sam
Ruby/Raleigh/IBM@IBMUS, scott
dietzen <sc...@zimbra.com>,
Craig Becker/Austin/IBM@IBMUS,
Leugim A Bustelo/Austin/IBM@IBMUS,
Becky Gibson/Westford/IBM@Iris,
Javier H
Pedemonte/Austin/IBM@IBMUS, Donald
Sedota/Austin/IBM@IBMUS
Subject
Re: AJAX Toolkit Framework Proposal
On Tue, 2005-12-20 at 23:18 -0500, Adam Peller wrote:
>
> 2) The other subproject is Zimbra itself, but there may be other runtimes
> here as well. As you say, the main goal here is to provide layers of
> abstraction to hide the traditional browser tricks and quirk modes to
make
> browser-based programming more productive, and Zimbra does this well.
Did you really mean all of Zimbra or just the toolkit part?? I believe
Zimbra includes an email client platform as well .. and something
they're pushing with a dual license model (which clearly does not sit
well with us once code starts coming in from other contributors).
Thanks for the long explanation!
Sanjiva.
---------------------------------------------------------------------
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
Re: AJAX Toolkit Framework Proposal
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-12-20 at 23:18 -0500, Adam Peller wrote:
>
> 2) The other subproject is Zimbra itself, but there may be other runtimes
> here as well. As you say, the main goal here is to provide layers of
> abstraction to hide the traditional browser tricks and quirk modes to make
> browser-based programming more productive, and Zimbra does this well.
Did you really mean all of Zimbra or just the toolkit part?? I believe
Zimbra includes an email client platform as well .. and something
they're pushing with a dual license model (which clearly does not sit
well with us once code starts coming in from other contributors).
Thanks for the long explanation!
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
Hey Sanjiva! Yeah, it's been a while. I've been trying to follow your
projects and blogs over the years. Sounds like all is going well.
No secret agendas here :) Happy to answer.
>So this may not be an appropriate part of the discussion for deciding
>whether to accept this for incubation or not but I'm concerned about
>complexity. A key reason for the evolution of AJAX is that the "old way"
>was too damned complicated. This proposal appears to be offering a
>framework to layer over frameworks! Is that correct? If so why do you
>believe that anyone other than the Zimbra toolkit (which is part of this
>proposal) will in fact come and port their framework to this world.
For starters, I have to apologize for the names. "Toolkits" and
"Frameworks" are likely to be misinterpreted, and yes, it almost sounds
circular. Hopefully we can come up with a better name for the tooling
subproject, but any time we come up with something, it gets shot down
internally as an existing trademark. We're open to suggestions :)
There's really no meta-framework here, per se, and nothing to port. Here's
what we're trying to do:
1) The tooling subproject consists of some generic DHTML/AJAX tooling that
ought to be applicable to just about anyone. We then provide plugins (you
might think of them as adapters) to support various runtimes, like Zimbra.
(The submission has implementations for Zimbra and Rico, and we're working
on support for Dojo as well) The plugins start out by handling the
mechanics of creating projects, structuring directories, deploying projects
and the like. We all know how painful these things can be to do manually.
In addition to this, there are wizards to guide you through code creation,
snippets and templates for repetitive tasks, etc. Typically this does not
require any change to the runtimes, though in the case of Zimbra we did
shuffle the directory structure around a bit. The tooling "framework" is
extensible so that support for other runtimes can be added. We even
provide tooling to create the tooling. This starts with a boilerplate
process, driven by a wizard, which asks for things like the location of the
libraries, naming patterns and templates for empty pages, etc. The result
is a set of plugins which act as adapters to the new runtime. I hope that
runtime authors would jump at the chance to write adapters so that their
users could enjoy the benefits of IDE integration.
2) The other subproject is Zimbra itself, but there may be other runtimes
here as well. As you say, the main goal here is to provide layers of
abstraction to hide the traditional browser tricks and quirk modes to make
browser-based programming more productive, and Zimbra does this well.
>Also, is the proposed framework intended as a client side platform? That
>is, is it basically an alternative to using a browser on the client side
>as a host for AJAX applications? Or is it just some kind of tooling
>framework?
Just a tooling framework. The browser is always the intended client.
>I've looked at the Zimbra SOAP stuff (very) briefly and its pretty
>primitive. Do you expect to continue to develop that into a fully
>fledged SOAP infrastructure (supporting addressing, security, RM and all
>that WS -* stuff) or depend on someone else?
Yes, the SOAP layer in Zimbra is pretty basic, though I don't know of many
web-based clients that have gone further. I think the intent is to expand
on it. Though given that we are targeting the browser and not some
alternate platform, there are probably going to be limits on what we can do
and what makes sense. Do you think a full-fledged SOAP model would be
useful from a web client? Much of the time, as you say, the simple
XML/JSON/REST model works well enough for the client, especially when you
have restrictions like the browser's same domain policy. The
infrastructure for security doesn't seem to be there on the client, and I'm
not sure anyone really wants it there? Similarly, it's hard to imagine
implementing everything required to support attachments and encryption from
JavaScript, but I guess anything is possible? Perhaps proxying messages
with JSON/REST and doing SOAP on the backend, pushing issues like security
and state to the server is the way to go? I think it might be best to
leave this as an open question. I think this is exactly the sort of thing
we'd like to learn from the incubator -- which AJAX messaging models make
sense, and where do we focus our development efforts?
Regarding Mozilla:
>Are they contributing code and/or committers too?
No, Mozilla is not a contributor or committer here, at least not now.
>Or did you mean in the
>sense that the proposed project depends on XUL and its runtime? (Is that
>a Java thing BTW or is there a plan to do some JNI bridge to it from
>Eclipse WTP?)
Funny you should ask... Yes, there is a dependency on xulrunner, but there
is also a Mozilla XPCOM to Java bridge (javaconnect) which was developed by
at IBM by Javier Pedemonte and was contributed back to mozilla.org. Part
of it is in our posting as a 3rd party contribution but will eventually it
will all be hosted at mozilla.org -- note that besides Mozilla being a
logical home for this code functionally, there are actually very tight
build dependencies, unlike the Eclipse work. This is an enabling layer for
our tooling but it has many other uses.
We've used javaconnect to implement our debugger and DOM inspector which
write to the same native XPCOM APIs as their JavaScript counterparts
Venkman and the Mozilla DOM Inspector, but instead have Eclipse integration
points. This tight integration with Mozilla can enable some powerful
tooling, maybe even some test automation? Lots of possibilities. And
while we're doing all this tight integration with Mozilla, I should point
out that it is only to enable tooling and should not impact the runtimes.
We of course do NOT advocate writing code to any one browser.
Regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-12-20 at 09:03 -0500, Adam Peller wrote:
Hi Adam! Haven't run into you since the early BSF days .. boy that was
like 7 years ago??! Looks like you're doing well and keeping busy ...
good!
I have some questions on the proposal:
> The AJAX Toolkit Framework will provide a strategic framework for
> Interactive Development Environments (IDEs) for the many different AJAX
> toolkit offerings in the market. It provides a rich set of tools for the
> AJAX / DHTML developer including: a JavaScript editor with edit-time syntax
> checking; Mozilla web browser; integrated DOM browser; integrated
> JavaScript debugger; and wizards and development aides tuned to specific
> libraries and toolkits. The Framework is extensible to support other AJAX
> toolkits and has a wizard-based tool to facilitate the integration of new
> toolkits in the framework.
>
> The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
> Plugin extensions to Eclipse. It embeds 4 other open source components:
> Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> 4 open source components specified. They are incorporated to accommodate
> Eclipse plugin architecture and distributed as-is by repackaging them as
> part of the AJAX Toolkit Framework.
So this may not be an appropriate part of the discussion for deciding
whether to accept this for incubation or not but I'm concerned about
complexity. A key reason for the evolution of AJAX is that the "old way"
was too damned complicated. This proposal appears to be offering a
framework to layer over frameworks! Is that correct? If so why do you
believe that anyone other than the Zimbra toolkit (which is part of this
proposal) will in fact come and port their framework to this world.
Also, is the proposed framework intended as a client side platform? That
is, is it basically an alternative to using a browser on the client side
as a host for AJAX applications? Or is it just some kind of tooling
framework?
If its an alternate client platform, can you expand a bit on plans to
build stuff with it? (Again you can reply with "Not your damned business
as it has nothing to do with the incubation process" but I'm just
looking for more info.)
> The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
> framework, provides a rich client library, similar in style to traditional
> object-oriented widget libraries like Eclipse's SWT. This toolkit hides
> implementation details and browser quirks and makes web development more
> accessible to the enterprise developer. It provides
>
> * User interface development
> * Network communications (both synchronous and asynchronous)
> * SOAP programming
> * XML document creation and manipulation
> * UI event handling and management
I've looked at the Zimbra SOAP stuff (very) briefly and its pretty
primitive. Do you expect to continue to develop that into a fully
fledged SOAP infrastructure (supporting addressing, security, RM and all
that WS -* stuff) or depend on someone else?
The reason I'm asking is obvious .. I'd like you to use Axis2/C and
Axis2/Java for that part :). If the first part is about an alternate
client platform then I imagine you'd want to use Axis2/Java and plug it
into Rhino (obviously you can as-is but a more native binding would of
course be nicer). We already have the start of a Rhino provider BTW
(courtesy of Sylvain during ApacheCon!).
We've already started on a PHP binding for Axis2/C and would like to see
folks bind it to as much other stuff out there as possible. That way you
get a full function SOAP stack on the browser .. so instead of just
getting a bit of SOAP (which BTW doesn't make much sense; then one might
as well do pure XML/HTTP(S) and be happy and lighter) you get the whole
deal.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-12-20 at 18:27 -0500, Sam Ruby wrote:
>
> Adam can certainly speak to the technical aspects of this than I can,
> but AJAX certainly causes one to rethink the traditional client/server
> boundary, in fact it tends to blur it. One can pick off small pieces
> and say this definately belongs on the server, and that could ship with
> eclipse, but there are also gray area pieces that we could pick a spot
> based on our current understanding, but over time or with the inclusion
> of new members and their points of view, our understanding may shift.
> It would be advantageous if everything were licensened identically so
> that such decisions could be made on a purely technical basis, and not
> based on other considerations.
+1.
> Life is hard enough as is.
:)
> P.S. If this isn't complicated enough, there is a third party: Mozilla
> involved. At least there the line seems somewhat clearer.
Are they contributing code and/or committers too? Or did you mean in the
sense that the proposed project depends on XUL and its runtime? (Is that
a Java thing BTW or is there a plan to do some JNI bridge to it from
Eclipse WTP?)
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Davanum Srinivas <da...@gmail.com>.
Got it! thanks
-- dims
On 12/20/05, Mike Milinkovich <mi...@eclipse.org> wrote:
>
>
>
> > Please pardon me for being blunt, I don't really care about
> > what happens inside IBM/Eclipse or who said what/when.
>
> Dims,
>
> Trust me, no one hates that bullshit more than I. I was just reacting to
> Sam's assertion that Eclipse was fully informed and happy with outcome and
> wanted to be precise in my response.
>
> At the risk of pointing out the obvious, Eclipse is no longer part of IBM,
> and has not been for almost two years. We've been an independent Foundation
> since Jan. '04. So "...inside IBM/Eclipse..." does not happen any more than
> "...inside IBM/Apache...".
>
> I realize this is unrelated to the topic at hand, but just wanted to clear
> up any confusion.
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Ted Husted <te...@gmail.com>.
On 12/21/05, Ted Leung <tw...@sauria.com> wrote:
> I'd love to have a good AJAX project here at Apache, but I'm not at
> all convinced that this is the best way to get it. I also talked to
> Alex Russell at Dojo about coming to the ASF (at this year's OSCON),
> and the overhead thing was already on his radar. Perhaps we ought
> to be more concerned about making ourselves attractive to projects
> like Dojo. We already know that the corporations see the value of
> the Apache brand. Ask yourself why a small innovative project like
> Dojo would rather stay out of the ASF.
In my experience, it's because the developers on those projects
haven't actually worked with Apache committers, only heard what other
people say about us. :)
I remember seeing a statistic once that said if a person is involved
in one open-source projects, then they are likely to be involved in
more than one open source project. I think a very valid source of new
ASF projects -- perhaps the best source -- are the other software
projects that we ourselves join.
If Dojo (or anyone else) is a good fit for for the ASF, then ASF
committers and members should be able to join that community first.
And, having joined that community, it should be a smaller step for
Dojo (or anyone else) to turn around and join the ASF.
I do think ASF members should be inviting projects to join us -- if
they are projects that we ourselves use, and if they are projects that
we can see are a good fit for the Foundation.
But, I'm not sure if we should be accepting for incubution unproven
projects with no community track record and no prexisting ASF
participants. There are other hosts where a project can get started,
and when that project grows up and proves itself as a collaborative
entity, then that's a good time to come join the ASF.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 12/21/05, Ted Leung <tw...@sauria.com> wrote:
> I'd love to have a good AJAX project here at Apache, but I'm not at
> all convinced that this is the best way to get it. I also talked to
> Alex Russell at Dojo about coming to the ASF (at this year's OSCON),
> and the overhead thing was already on his radar. Perhaps we ought
> to be more concerned about making ourselves attractive to projects
> like Dojo. We already know that the corporations see the value of
> the Apache brand. Ask yourself why a small innovative project like
> Dojo would rather stay out of the ASF. Wouldn't they benefit more
> from the Apache name than IBM and Zimbra? An Apache branded AJAX
> toolkit would be seriously looked at just because of the branding.
> I would hate to be a party to helping a so-so AJAX toolkit displace a
> really good one, just because the so-so one came to the incubator and
> the other one didn't.
+1
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Ted Leung <tw...@sauria.com>.
On Dec 21, 2005, at 12:56 AM, Sanjiva Weerawarana wrote:
> On Tue, 2005-12-20 at 22:10 -0800, Cliff Schmidt wrote:
>
> However, after having been on the other side of this discussion during
> the Synapse startup with the hullabaloo caused by ObjectWeb folks, I
> have no patience for any kind of "this space is mine, you keep to
> yours"
> type nonsense. I totally agree that the only discussion here should be
> does ASF want to take this on or not, not on whether Eclipse folks
> feel
> it "rightfully" belongs there or not. (No Mike, I'm not saying you
> said
> that!)
>
>> I strongly believe that the ASF is not an island in the
>> world of open source, and that it is good for us and all participants
>> in open source if we do what we can to minimize communication
>> problems
>> about projects that others may have an interest in.
>
> Indeed. However, the corporate interest of a foundation has much
> lesser
> weight in my book than what other ASFers think in evaluating this
> stuff.
I don't think it's that simple. There's also the corporate interest
of IBM and Zimbra in bringing this to Apache. Generally speaking, I
consider any open source foundation to be more my ally than any
corporation or group of corporations. I've been doing a lot more in
the broader open source community recently, and discovered that
Apache is not universally well-regarded. I have heard it suggested
that we are becoming the Microsoft of open source. If part of the
core Apache values are around community, why shouldn't that extend to
the broader open source community as well?
I'd love to have a good AJAX project here at Apache, but I'm not at
all convinced that this is the best way to get it. I also talked to
Alex Russell at Dojo about coming to the ASF (at this year's OSCON),
and the overhead thing was already on his radar. Perhaps we ought
to be more concerned about making ourselves attractive to projects
like Dojo. We already know that the corporations see the value of
the Apache brand. Ask yourself why a small innovative project like
Dojo would rather stay out of the ASF. Wouldn't they benefit more
from the Apache name than IBM and Zimbra? An Apache branded AJAX
toolkit would be seriously looked at just because of the branding.
I would hate to be a party to helping a so-so AJAX toolkit displace a
really good one, just because the so-so one came to the incubator and
the other one didn't.
I haven't looked at the code in question and I'm not a Javascript
expert by any means. But if Martin's analysis of the codebase is
correct, then I'd vote no.
----
Ted Leung Blog: <http://www.sauria.com/blog>
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-12-20 at 22:10 -0800, Cliff Schmidt wrote:
>
> My second reason for asking was as a polite gesture towards the
> Eclipse Foundation, being another respectable, non-profit, open source
> organization.
I have ABSOLUTELY nothing against the Eclipse Foundation or their
products; I'm myself a very happy Eclipse user myself and fully
appreciate that there's such a high quality free product available for
me!
However, after having been on the other side of this discussion during
the Synapse startup with the hullabaloo caused by ObjectWeb folks, I
have no patience for any kind of "this space is mine, you keep to yours"
type nonsense. I totally agree that the only discussion here should be
does ASF want to take this on or not, not on whether Eclipse folks feel
it "rightfully" belongs there or not. (No Mike, I'm not saying you said
that!)
> I strongly believe that the ASF is not an island in the
> world of open source, and that it is good for us and all participants
> in open source if we do what we can to minimize communication problems
> about projects that others may have an interest in.
Indeed. However, the corporate interest of a foundation has much lesser
weight in my book than what other ASFers think in evaluating this stuff.
I do share many of Martin Cooper's concerns about this project however,
especially the last one.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Cliff Schmidt <cl...@gmail.com>.
On 12/20/05, Davanum Srinivas <da...@gmail.com> wrote:
> Mike,
>
> Some one comes to ASF with a proposal, typically we give it our full
> consideration. I can understand why cliff asked about eclipse option
> (Beehive/Eclipse stuff!),
Actually, I had two purposes behind my question. One was to learn
more about why the people behind the proposal wanted to come to
Apache. Although it is nice to hear from Sam, as the project
champion, I was addressing Adam because I thought it would be nice to
hear from someone listed as a project committer as to why they thought
Apache community was a better fit.
My second reason for asking was as a polite gesture towards the
Eclipse Foundation, being another respectable, non-profit, open source
organization. I strongly believe that the ASF is not an island in the
world of open source, and that it is good for us and all participants
in open source if we do what we can to minimize communication problems
about projects that others may have an interest in. I probably don't
need to say any more about the relevancy of that issue to this
thread...but even when a miscommunication has nothing to do with the
ASF, I would prefer that it is addressed before the proposal becomes a
project associated with Apache.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by Mike Milinkovich <mi...@eclipse.org>.
> Please pardon me for being blunt, I don't really care about
> what happens inside IBM/Eclipse or who said what/when.
Dims,
Trust me, no one hates that bullshit more than I. I was just reacting to
Sam's assertion that Eclipse was fully informed and happy with outcome and
wanted to be precise in my response.
At the risk of pointing out the obvious, Eclipse is no longer part of IBM,
and has not been for almost two years. We've been an independent Foundation
since Jan. '04. So "...inside IBM/Eclipse..." does not happen any more than
"...inside IBM/Apache...".
I realize this is unrelated to the topic at hand, but just wanted to clear
up any confusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Davanum Srinivas <da...@gmail.com>.
Mike,
Some one comes to ASF with a proposal, typically we give it our full
consideration. I can understand why cliff asked about eclipse option
(Beehive/Eclipse stuff!), but i can understand Adam/Sam's view
completely as I am on the "ASL 2.0 is good" band-wagon and i do want
ASF's stamp on everything i do. I really don't mind if Apache gets
into Eclipse tools/plugins. We do have Eclipse plugins in Axis2
project. We also have another plugin for running Geronimo inside WTP.
So it's not a new thing and the proposal has my +1.
Please pardon me for being blunt, I don't really care about what
happens inside IBM/Eclipse or who said what/when. All i know is that
we have a proposal in front of us and as a community we take it or
leave it or ask for changes if we think they are needed. As far as i
can see "since we did it before, we should do so again" is not a
strong argument for requesting a change to the proposal. FWIW, i've
been on the receiving end of unpleasant surpises as well. Take
ServiceMix/Geronimo for example. It's a fact of life here and we all
have learned to deal with it :)
Thanks,
dims
On 12/20/05, Mike Milinkovich <mi...@eclipse.org> wrote:
>
> > In particular, why would taking Solomon's advice and dividing
> > the child in half be benefitial (sic) to anybody?
>
> Interesting question. So your assertion is that all open source code should
> be done at Apache and there are no reasonable scenarios in which another
> open source community can or should attempt to co-operate with Apache?
>
> I would point out that the "runtime at Apache and tools at Eclipse" is not a
> new scenario. It has been repeated numerous times with great success for
> both our communities and their mutual consumers.
>
> Solomon has decided many times in the past. With a strikingly different
> conclusion than what you are proposing here.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mike Milinkovich wrote:
> > > So your assertion is that all open source code should be done at
> > > Apache and there are no reasonable scenarios in which another open
> > > source community can or should attempt to co-operate with Apache?
> > I don't believe that Sam said anything of the sort.
> Can you tell me what your interpretation of the Solomon reference would
> be, given the numerous precedents of mutual co-operation that predate
> this proposal?
It is one thing to question the wisdom of splitting a project, if one
perceives it that way, from going so far as to say that "all open source
code should be done at Apache and there are no reasonable scenarios in which
another open source community can or should attempt to co-operate with
Apache." As I see it, you started from a specific example, provided an
extreme generalization, and questioned the extreme. I would question that
extreme, too! :-)
See: http://en.wikipedia.org/wiki/Reductio_ad_absurdum
Personally, my view has been that if a community wants to come to the ASF,
to Eclipse, or to any other place, they should be able to do so, assuming
that the organization they wish to join is willing. And I always encourage
collaboration, and convergence where appropriate.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by Mike Milinkovich <mi...@eclipse.org>.
> > So your assertion is that all open source code should be done at
> > Apache and there are no reasonable scenarios in which another open
> > source community can or should attempt to co-operate with Apache?
>
> I don't believe that Sam said anything of the sort.
Really? I am truly not meaning to be argumentative. Can you tell me what
your interpretation of the Solomon reference would be, given the numerous
precedents of mutual co-operation that predate this proposal?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mike Milinkovich wrote:
> So your assertion is that all open source code should be
> done at Apache and there are no reasonable scenarios in
> which another open source community can or should attempt
> to co-operate with Apache?
I don't believe that Sam said anything of the sort.
> Solomon has decided many times in the past.
Just because it irks me to see references abused, I'd like to remind
everyone that Solomon's suggestion was a trick, and that Solomon awarded the
child to the woman (the real mother) who would rather give it up than see it
killed. That isn't to say anything about the merits of the on-going
discussion. Just wanted to put the reference back into its proper context.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by Mike Milinkovich <mi...@eclipse.org>.
> In particular, why would taking Solomon's advice and dividing
> the child in half be benefitial (sic) to anybody?
Interesting question. So your assertion is that all open source code should
be done at Apache and there are no reasonable scenarios in which another
open source community can or should attempt to co-operate with Apache?
I would point out that the "runtime at Apache and tools at Eclipse" is not a
new scenario. It has been repeated numerous times with great success for
both our communities and their mutual consumers.
Solomon has decided many times in the past. With a strikingly different
conclusion than what you are proposing here.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sam Ruby <ru...@apache.org>.
Mike Milinkovich wrote:
[snip]
> (I appreciate that you were not directly engaged with Eclipse prior to this
> proposal being made public.)
[snip]
> The last talk we had with IBM concerning this project was on October 20th
First, thank you very much for posting posting here. I'm confident that
together we can work through this. Apparently, neither of us have a
complete history.
Meanwhile:
There is some code posted at http://people.apache.org/~rubys/ajax/
There is a proposal posted at http://tinyurl.com/9ctml
I posted why I believe that a single cohesive community centered around
a codebase with a single, liberal, sub-licenseable license would be a
good thing.
At least one ASF member has +1'ed that reasoning.
Care to make an equally concrete proposal?
In particular, why would taking Solomon's advice and dividing the child
in half be benefitial to anybody?
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by Mike Milinkovich <mi...@eclipse.org>.
> -----Original Message-----
> Now to directly Cliff's question: yes, we considered
> proposing this to Eclipse. And we talked with a number of
> people there. And surprisingly enough - we thought those
> discussions were settled but they seem to have sprung back up
> again after Adam sent in the proposal.
Sam,
This is absolutely incorrect. If you were surprised, you were misinformed.
(I appreciate that you were not directly engaged with Eclipse prior to this
proposal being made public.)
But we categorically deny the assertion that discussions were settled or
that this proposal was anything other than a complete and unpleasant
surprise to Eclipse.
The last talk we had with IBM concerning this project was on October 20th
and was to the affect that the runtime components would go to Apache and the
tools components would go to Eclipse. Runtime at Apache, tools at Eclipse. A
pattern we have all seen executed succesfully before.
An email from me to IBM regarding the status of this proposal dated Dec.
15th went unanswered until 6:15 ET this evening, after this proposal was
launched at Apache, and this conversation on the mailing list ensued.
What or who made you think discussions were "settled"?
Mike Milinkovich
Executive Director,
Eclipse Foundation, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Closed for renovations" (was:Re: AJAX Toolkit Framework
Proposal)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2005-12-21 at 03:01 -0800, Leo Simons wrote:
>
> I have this urge to set up an "Under construction" sign on the incubator front
> page with a subtitle along the lines of "closed for renovations"...
+1, to give us a bit of soul searching time. We should put a cap on the
renovation time - 2 weeks seems ok to me given the holiday season.
[With lots of apologies to the proponents of the project :(.]
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/21/05, Leo Simons <ma...@leosimons.com> wrote:
<snip>
> The ASF isn't very good at "saying no", at least not very loudly. All our
> processes are geared at "saying yes" the right way and only if we feel
> comfortable. It seems we have something to learn here, and its a bit scary
> since this may have further negative impact on the subject at hand (you can
> just imagine all the bile..."Man, this project really sucks! Even the ASF
> didn't want it, and they ship more crap than any other open source
> organisation!").
LOL
or maybe: "ASF has turned this project down! Must be great! We've
found the next JBoss." ;)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 21 déc. 05, à 12:01, Leo Simons a écrit :
> On Tue, Dec 20, 2005 at 04:49:29PM -0800, Martin Cooper wrote:
>> Some comments:
> <snip/>
>
> On Wed, Dec 21, 2005 at 10:54:03AM +0100, Raphaël Luta wrote:
>> To me it raises all the possible incubation warning bells:
> <snip/>
Same feelings here, I agree with Martin's and Raphaël's concerns.
> ...I feel a bit sorry for the Zimbra guys..
To me the right thing to do if you were an "outside" company trying to
join the ASF with a cool project, would be to build interest inside the
ASF first and to get to know each other.
In other words, if I were Zimbra (but I'm not ;-) I'd get involved with
some ASF projects where my stuff makes sense (Cocoon, JSF, Tapestry,
you name it) to show us how good that stuff is, and most importantly to
build relationships before coming up with a proposal where we (or most
of us at least) recognize no one.
(I hope) the ASF is (still) about communities, not primarily code.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
"Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)
Posted by Leo Simons <ma...@leosimons.com>.
On Tue, Dec 20, 2005 at 04:49:29PM -0800, Martin Cooper wrote:
> Some comments:
<snip/>
On Wed, Dec 21, 2005 at 10:54:03AM +0100, Rapha�l Luta wrote:
> To me it raises all the possible incubation warning bells:
<snip/>
Two convincing posts.
> In summary I see this proposal as a high risk, low value offer to the ASF
> and would definitely pass on it.
We might summarise other comments so far as concerns about a "low value" not
just for the ASF but for the larger open source community in general.
Hmm. This is a new thing for us here at the incubator. Eg we've seen "high
risk, low value" proposals before, but those were generally greeted with a
lack of interest in the problem space all-around. Judging by the amount and
length of the emails, there's a bunch of people really interested in this
AJAX thing.
The ASF isn't very good at "saying no", at least not very loudly. All our
processes are geared at "saying yes" the right way and only if we feel
comfortable. It seems we have something to learn here, and its a bit scary
since this may have further negative impact on the subject at hand (you can
just imagine all the bile..."Man, this project really sucks! Even the ASF
didn't want it, and they ship more crap than any other open source
organisation!").
I feel a bit sorry for the Zimbra guys being caught in the middle (in general
I have a hard time feeling sorry for IBM, because its, well, IBM, and too big
too have any feelings towards except "too big") of what is essentially the ASF
doing some soul-searching and navel-staring with regard to the incubation
process. I can fully imagine how the people that worked on this proposal spent
weeks in excitement at the prospect of joining up with the ASF and all the good
stuff that would come of it, and now they're getting a cold shower.
I have this urge to set up an "Under construction" sign on the incubator front
page with a subtitle along the lines of "closed for renovations"...
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Raphaël Luta <ra...@apache.org>.
Sam Ruby wrote:
> Raphaël Luta wrote:
> <snip>
>
> Overall, there is clearly strong interest in AJAX at the ASF, whether it
> be based on Zimbra or Dojo or whatever. Furthermore, the proposal needs
> to be revised, particularly to incorporate the people who have expressed
> an interest in participating and creating ties to other projects.
>
I completely agree that there's a strong interest in AJAX from many Apache
communities, Portals included. It's something many people in many communities
are trying to figure out how to best tackle, however so far I've never seen
Zimbra mentioned in an Apache community in this regard.
> -------------------------------------------------------------------------------
>
>> Criteria
>> ========
>>
<sniping some parts to keep mail shorter>
>> * Community:
>>
>> none
>
>
> A bit overstated. There is a community, but it has yet to be incubated
> and certified as following the Apache way.
>
I can't see any existing community described in the proposal, I can't find
any public forum about Zimbra AJAX toolkit and everything I get from Google is
press releases, whitepapers and conferences.
If you could point me to an existing online public community, I'll gladly admit
I am overstating the current situation.
>> * Core developers:
>>
>> no existing Apache committer or Apache member
>
>
> That's the initial proposal. The proposal was immediately was met with
> several volunteers.
>
It was indeed met with interest from several Apache committers, that doesn't
make them core developers though since they are not part of the current
development effort.
It does show a potential for community building.
>> Warning signs
>> =============
>>
>> * Orphaned products:
>>
>> Apparently no
>
>
> I'm not certain what you are trying to say here.
>
Trying to express that the toolkit doesn't seem to be orphaned as it is probably
actively used by Zimbra other products.
>> * Homogenous developers/salaried developers:
>>
>> Definitely yes, all work for 2 companies with strong hierarchical
>> ties in
>> the proposed committer base
>
>
> Again, the proposal was immediately met with volunteers. I will state
> that everybody involved fully understands that the current level of
> diversity certainly would not meet the incubator's exit criteria for a
> project - and everybody supports the goal of building a diverse community.
>
My point was more than given the huge number of initial committers I would
expect it to grow to at least 35-30 committers with all new committers from
external parties before such a community could be called "balanced".
Starting from scratch and getting to this level is a *huge* task, especially
if you don't have another established community as a userbase.
>
> To help you see it another way, take a look at the following link:
>
> http://ajaxian.com/archives/2005/12/apache_ajax_too.html
>
> AJAX is hot. People outside are watching. IBM and Zimbra will
> undoubtably get a lot of press people asking questions. My experience
> has been that such people are well trained in saying "no comment", but
> the fact is that there is interest, and at some point it makes sense to
> meet such interest with facts.
>
I'm seeing and am actually actively looking because Ajax has some
critical impact on web applications and portals in particular.
One of the key comments I frequently see is:
Why does <this/that project> have to be in the ASF ?
and frankly I can't think of a good reason why the ASF would want to
kickstart a brand new AJAX community. Several other exists, are working
well and are compatible with our IP, why create something new within the
ASF rather than join those existing communities ?
>> As is, I can't see a single reason to support the proposal ans see
>> several to
>> vote a strong -1 on it in its current form :
>>
>> - The proposal is too large to incubate, it's hard enough to create a
>> community
>> from scratch around a single well-defined goal and codebase, rolling 2
>> together is suicide in my book.
>
>
> I don't mean to minimize the concern, but we have incubated larger. As
> we have seen in this and other donations - IP lawyers are very
> interested in clearly delineating the precise origins of each component.
> As such, we've overstressed the separate nature of these pieces.
>
> Just to be clear: the goal is to build one community.
>
Yes we have incubated larger but not always to very good results and
tackling something with as many different pieces is definitely a big
challenge.
>> - I don't see any benefit for the ASF and several drawbacks (more
>> hard work and strain on resources, possible PR complications,
>> additionnal
>> strain on friendly relations with other OSS groups like Eclipse)
>
>
> There definitely is interest in AJAX at the ASF. If not Zimbra, then
> Dojo. And as Sanjiva and Dims have eloquently put it
>
> I have no patience for any kind of "this space is mine, you keep to
> yours" type nonsense. I totally agree that the only discussion here
> should be does ASF want to take this on or not, not on whether
> Eclipse folks feel it "rightfully" belongs there or not.
>
> and
>
> I really don't mind if Apache gets into Eclipse tools/plugins. We do
> have Eclipse plugins in Axis2 project. We also have another plugin
> for running Geronimo inside WTP. So it's not a new thing and the
> proposal has my +1. Please pardon me for being blunt, I don't
> really care about what happens inside IBM/Eclipse or who said
> what/when. All i know is that we have a proposal in front of us and
> as a community we take it or leave it or ask for changes if we think
> they are needed.
>
I personnally feel otherwise: one of the ASF pillar is open cooperation.
We do our best to make it happen within our communities and I feel we
should do our best to make it happen with external communities as well.
There are some reasons sometimes when ASF decides to start a project
that can be percieved as unecessarily competing with other established
groups, IP being the primary one, and I have no problem with that.
However, simply disregarding the opinions of other communities is to
me the opposite of open cooperation and consensus based approach we're
trying to promote.
I think it's a worthwhile goal of spreading our vision to newly incubated
communities but if it just makes us look as arrogant bastards from the
rest of the world, I definitely feel we should restrain.
>> - There's no mentor yet ! Bad sign...
>
>
> Again, two volunteers within moments of posting alone.
>
None of them qualified under the current incubation policy.
>
>> In summary I see this proposal as a high risk, low value offer to the ASF
>> and would definitely pass on it.
>
>
> I don't want to minimize the risk, but I do think you have
> underestimated the interest/value.
>
I think I understand the value and interest of AJAX. I just don't see
how this proposal brings value to the ASF. Can you tell me what you
see as benefits (for the ASF) for incubating this project ?
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sam Ruby <ru...@intertwingly.net>.
Raphaël Luta wrote:
Excellent post! It is nice to see somebody take the time to review the
actual proposal.
Overall, there is clearly strong interest in AJAX at the ASF, whether it
be based on Zimbra or Dojo or whatever. Furthermore, the proposal needs
to be revised, particularly to incorporate the people who have expressed
an interest in participating and creating ties to other projects.
-------------------------------------------------------------------------------
> Criteria
> ========
>
> * Meritocracy:
>
> I don't believe it looking at the committer list.
> Who's going to argue with his VP of engineering ? To create a real
> meritocracy, you can't have an established hierarchy in the committership.
Valid concern - needs to be worked.
> * Community:
>
> none
A bit overstated. There is a community, but it has yet to be incubated
and certified as following the Apache way.
> * Core developers:
>
> no existing Apache committer or Apache member
That's the initial proposal. The proposal was immediately was met with
several volunteers.
> * Alignment:
>
> no simple mission statement but trying two roll out 2 complementary
> sub projects into a single community.
My fault for not catching that one. I have stated that the goal is to
build a single community. See below.
> Warning signs
> =============
>
> * Orphaned products:
>
> Apparently no
I'm not certain what you are trying to say here.
> * Inexperience with open-source:
>
> Limited experience if I judge by the number of OSS related hits tied to the
> proposed committer names on Google. Only 3 names get some hits.
> You can also how Zimbra as a corp currently gets it here:
> http://www.zimbra.com/community/
Valid concern.
> * Homogenous developers/salaried developers:
>
> Definitely yes, all work for 2 companies with strong hierarchical ties in
> the proposed committer base
Again, the proposal was immediately met with volunteers. I will state
that everybody involved fully understands that the current level of
diversity certainly would not meet the incubator's exit criteria for a
project - and everybody supports the goal of building a diverse community.
> * No ties to Apache products:
>
> True
Again, immediately upon seeing the initial post, several people
suggested a number of possible ties.
> * Fascination with Apache brand:
>
> True, just see prc@ activity.
I understand how you could see it that way. For those not on the PRC, I
sent a draft email yesterday which essentially said that discussions
were underway with the ASF and gave an overview of what AJAX is.
To help you see it another way, take a look at the following link:
http://ajaxian.com/archives/2005/12/apache_ajax_too.html
AJAX is hot. People outside are watching. IBM and Zimbra will
undoubtably get a lot of press people asking questions. My experience
has been that such people are well trained in saying "no comment", but
the fact is that there is interest, and at some point it makes sense to
meet such interest with facts.
> As is, I can't see a single reason to support the proposal ans see several to
> vote a strong -1 on it in its current form :
>
> - The proposal is too large to incubate, it's hard enough to create a community
> from scratch around a single well-defined goal and codebase, rolling 2
> together is suicide in my book.
I don't mean to minimize the concern, but we have incubated larger. As
we have seen in this and other donations - IP lawyers are very
interested in clearly delineating the precise origins of each component.
As such, we've overstressed the separate nature of these pieces.
Just to be clear: the goal is to build one community.
> - I don't see any benefit for the ASF and several drawbacks (more
> hard work and strain on resources, possible PR complications, additionnal
> strain on friendly relations with other OSS groups like Eclipse)
There definitely is interest in AJAX at the ASF. If not Zimbra, then
Dojo. And as Sanjiva and Dims have eloquently put it
I have no patience for any kind of "this space is mine, you keep to
yours" type nonsense. I totally agree that the only discussion here
should be does ASF want to take this on or not, not on whether
Eclipse folks feel it "rightfully" belongs there or not.
and
I really don't mind if Apache gets into Eclipse tools/plugins. We do
have Eclipse plugins in Axis2 project. We also have another plugin
for running Geronimo inside WTP. So it's not a new thing and the
proposal has my +1. Please pardon me for being blunt, I don't
really care about what happens inside IBM/Eclipse or who said
what/when. All i know is that we have a proposal in front of us and
as a community we take it or leave it or ask for changes if we think
they are needed.
> - There's no mentor yet ! Bad sign...
Again, two volunteers within moments of posting alone.
> - The odds of this project of successfully exiting the Incubator based on the
> diversity of community criteria seem very low to me: there are too many
> initial committers and most of them will have strong internal communication
> channels which will be invisible from the community.
This will all move to mailing lists.
> - I don't believe most of the proposed committers would get committership
> on their own merit and I would hate the Incubator to become an easy way to
> bypass the meritocratic model of the ASF: work at IBM and get a free
> committership when they donate the codebase to the ASF ! Most of the time
> you end up with paid-for-committers that only last as long as they're told
> to work on the project. (This is not pure paranoia ;) just look at Pluto if
> you want to see it in effect)
Valid concern.
> In summary I see this proposal as a high risk, low value offer to the ASF
> and would definitely pass on it.
I don't want to minimize the risk, but I do think you have
underestimated the interest/value.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Raphaël Luta <ra...@apache.org>.
Martin Cooper wrote:
> <snip>
> Personally, I am less than happy at seeing yet another large project
> proposed from a corporate source (and IBM at that), along with a dozen new
> committers who have not earned their merit at the ASF as most committers
> have. I feel the ASF is losing its way, and becoming a repository for
> corporate open-sourcing along with taking on responsibility for building
> communities around corporate code bases. I suspect I'm in the minority at
> the ASF, and I'm undoubtedly in the minority here in the incubator. But
> there doesn't seem to be a way for the incubator to say "no thanks", other
> than by a podling failing the incubation process, and that seems wrong to
> me.
>
You may be in the minority but you're not alone, I'll admit to being *very*
uneasy on this proposal.
To me it raises all the possible incubation warning bells:
Criteria
========
* Meritocracy:
I don't believe it looking at the committer list.
Who's going to argue with his VP of engineering ? To create a real
meritocracy, you can't have an established hierarchy in the committership.
* Community:
none
* Core developers:
no existing Apache committer or Apache member
* Alignment:
no simple mission statement but trying two roll out 2 complementary
sub projects into a single community.
Warning signs
=============
* Orphaned products:
Apparently no
* Inexperience with open-source:
Limited experience if I judge by the number of OSS related hits tied to the
proposed committer names on Google. Only 3 names get some hits.
You can also how Zimbra as a corp currently gets it here:
http://www.zimbra.com/community/
* Homogenous developers/salaried developers:
Definitely yes, all work for 2 companies with strong hierarchical ties in
the proposed committer base
* No ties to Apache products:
True
* Fascination with Apache brand:
True, just see prc@ activity.
As is, I can't see a single reason to support the proposal ans see several to
vote a strong -1 on it in its current form :
- The proposal is too large to incubate, it's hard enough to create a community
from scratch around a single well-defined goal and codebase, rolling 2
together is suicide in my book.
- I don't see any benefit for the ASF and several drawbacks (more
hard work and strain on resources, possible PR complications, additionnal
strain on friendly relations with other OSS groups like Eclipse)
- There's no mentor yet ! Bad sign...
- The odds of this project of successfully exiting the Incubator based on the
diversity of community criteria seem very low to me: there are too many
initial committers and most of them will have strong internal communication
channels which will be invisible from the community.
- I don't believe most of the proposed committers would get committership
on their own merit and I would hate the Incubator to become an easy way to
bypass the meritocratic model of the ASF: work at IBM and get a free
committership when they donate the codebase to the ASF ! Most of the time
you end up with paid-for-committers that only last as long as they're told
to work on the project. (This is not pure paranoia ;) just look at Pluto if
you want to see it in effect)
In summary I see this proposal as a high risk, low value offer to the ASF
and would definitely pass on it.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sylvain Wallez <sy...@apache.org>.
Martin Cooper wrote:
> Some comments:
>
<snip/>
+1 to all your points.
> Personally, I am less than happy at seeing yet another large project
> proposed from a corporate source (and IBM at that), along with a dozen new
> committers who have not earned their merit at the ASF as most committers
> have. I feel the ASF is losing its way, and becoming a repository for
> corporate open-sourcing along with taking on responsibility for building
> communities around corporate code bases. I suspect I'm in the minority at
> the ASF, and I'm undoubtedly in the minority here in the incubator. But
> there doesn't seem to be a way for the incubator to say "no thanks", other
> than by a podling failing the incubation process, and that seems wrong to
> me.
>
+1. And rather than a minority, this looks more like a silent majority
to me.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 20, 2005 at 04:49:29PM -0800, Martin Cooper wrote:
> Some comments:
>
> 1) This appears to be two proposals rolled into one. One is to incubate a
Yup. And Adam responded with the dreaded "subproject" word.
We determined a good while back that "umbrella" projects are bad. So
*starting* a project with the notion of subprojects is not necessarily
a good thing. Thankfully, this proposal lumps them into one community
(while the umbrellas divided them, which was the primary failing). But
lumping these two (somewhat disparate) project spaces into one seems
like it could be a problem. Especially given words about "pluggable"
and "no special tie-in". So if there isn't intended to be any special
tie-in between the two sides, then why shove the two communities
together?
It would seem this proposal ought to be divided into two.
>...
> 2) Various comments have been made regarding multiple ASF projects
> addressing the same area being OK, and indeed a good thing. While I
Yeah, although that has (historically) been based on taking different
approaches to a problem space, rather than simply tackling it with
different lines of code. I seriously doubt the AJAX space is
well-developed enough to identify very different strategies which
would lead to it being "acceptable" to kickstart two competitive
projects at Apache.
We're also about community here, so I would *expect* that if Dojo
decided to arrive at Apache, then it would go in *this* community
rather than start a second. Keep the communities together and working
on the space. If there is a real determination that the two think
about the approach dramatically different(!), then okay... maybe two
projects, but I'm a bit doubtful.
>...
> Personally, I am less than happy at seeing yet another large project
> proposed from a corporate source (and IBM at that), along with a dozen new
> committers who have not earned their merit at the ASF as most committers
> have. I feel the ASF is losing its way, and becoming a repository for
> corporate open-sourcing along with taking on responsibility for building
> communities around corporate code bases. I suspect I'm in the minority at
> the ASF, and I'm undoubtedly in the minority here in the incubator.
I share this concern, and Sanjiva also agreed with your concern.
A *lot* of code has been arriving at the ASF and many companies have
been seeking to do PR around those contributions and activities. I've
been starting to lean to a mode where (maybe) we simply won't provide
quotes to third parties about code they've provided. If it isn't an
Apache project (yet), then why should we talk about it?
And yeah: arriving via the Incubator is also a neat way to avoid our
standard meritocratic process. Diversity is also a question, and
whether there is true diversity in thought rather than simply in
numbers of committers.
Is there a solution? Nothing objective, I'd think. Maybe the Incubator
should only accept projects which have already established themselves
as open source projects? But what do we do about brand new ideas that
people want to spin up within the Incubator? Or what about projects
that the ASF determines that it really wants to be involved with?
(J2EE and J2SE to name our two precedents) Should the Incubator just
handle small-ish projects that are software-granted and destined to
existing PMCs?
I don't have an answer, but I share your unease with the spate of
corporate contributions over the past year or so.
Cheers,
-g
p.s. for those on this list who are not familiar with my protocol, I'm
sending this as gstein@lyra.org rather than my apache address; that
means I'm speaking as "Greg" rather than in my official capacity;
thus, don't read any ASF policy/leanings into the above.
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Mads Toftum <ma...@toftum.dk>.
On Wed, Dec 28, 2005 at 03:53:31PM -0500, Davanum Srinivas wrote:
> +1 to 3 ASF Members/Officers as mentors
> +1 to require Incubator PMC vote for *ALL* incoming projects
> +1 to require Incubator PMC vote even on simpler IP imports
>
yeah, sounds good to me. More mentors / oversight is likely to help
quite a bit.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to 3 ASF Members/Officers as mentors
+1 to require Incubator PMC vote for *ALL* incoming projects
+1 to require Incubator PMC vote even on simpler IP imports
thanks,
dims
On 12/28/05, Noel J. Bergman <no...@devtech.com> wrote:
> Steven Noels wrote:
>
> > The Incubator PMC only needs to care about IP and legal blahblah,
> > thus the receiving PMCs are tasked with community and brand abuse
> > stuff.
>
> Not true. If there is community development, the Incubator PMC had better
> be involved. We're going to have to adjust things, such as Mentorship and
> votes to leave the Incubator, e.g.,
>
> - a minimum of 3 ASF Members and/or Officers who have differing
> corporate affiliations as Mentors per project. The sponsoring
> PMC must identify those ASF Members. Projects who lose one or
> more sponsors -- even if they just go quiet -- must make sure
> that they regain the minimum of 3. Existing projects that are
> not meeting the quorum will not be permitted to release any
> code, regardless of otherwise meeting Incubator release guidelines.
>
> - the Board will determine if there is an Incubator PMC vote to
> accept a new project, but at the moment, any PMC can vote to
> bring a new project into the Incubator, assuming that they
> otherwise meet the guidelines. There are still guidelines
> regarding candidacy, and the Board will be encouraged to
> take a dim view of any PMC trying to game the system.
>
> - the Incubator PMC having the sole vote on all graduations from
> the Incubator. The target PMC votes to accept first, and then
> notifies us that they are ready for our vote.
>
> It is a talking point, but we may have to perform that vote even on simpler
> IP imports, just to prevent gaming the system, e.g., "well, it's not really
> a new project". Actually, all of those are talking points.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Davanum Srinivas <da...@gmail.com>.
Yes, I agree with Justin. More eyes the better. Especially ones with
"outsider" perspective will help.
-- dims
On 12/30/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Fri, Dec 30, 2005 at 10:21:59AM -0500, Geir Magnusson Jr wrote:
> > Agreed, but the Tuscany proposal was an independent proposal, not
> > sponsored (at the time) by any PMC.
>
> Dims mentioned that they had planned to approve that proposal through the
> WS PMC - so if it had been sponsored by them, there would have been no
> change permitted by the Incubator PMC to address concerns like Roy's.
>
> > >The Incubator PMC
> > >should also be able to make a judgment ("certification"?) of the
> > >process proposed by the PMC - such as whether a code base should be
> > >under full incubation or just use the IP clearance form.
> > >
> > >I think that making it clear that the Incubator PMC can do this would
> > >go a long way to addressing some of the concerns already mentioned.
> >
> > Agreed - although in general, if a PMC just ignored the input of the
> > Incubator PMC on a PMCs suggested incubation, it's an indication of a
> > problem anyway...
>
> As Greg said, that's for the board to deal with. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Dec 30, 2005 at 10:21:59AM -0500, Geir Magnusson Jr wrote:
> Agreed, but the Tuscany proposal was an independent proposal, not
> sponsored (at the time) by any PMC.
Dims mentioned that they had planned to approve that proposal through the
WS PMC - so if it had been sponsored by them, there would have been no
change permitted by the Incubator PMC to address concerns like Roy's.
> >The Incubator PMC
> >should also be able to make a judgment ("certification"?) of the
> >process proposed by the PMC - such as whether a code base should be
> >under full incubation or just use the IP clearance form.
> >
> >I think that making it clear that the Incubator PMC can do this would
> >go a long way to addressing some of the concerns already mentioned.
>
> Agreed - although in general, if a PMC just ignored the input of the
> Incubator PMC on a PMCs suggested incubation, it's an indication of a
> problem anyway...
As Greg said, that's for the board to deal with. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Justin Erenkrantz wrote:
> On 12/29/05, Greg Stein <gs...@lyra.org> wrote:
>
>>If another PMC decides a project should be incubated, they must
>>provide the people to make that happen (so we achieve proper scaling
>>and to put the effort on those who want the results). The Incubator
>>can't refuse the project outright, but if the STATUS page or
>>proposal/charter or whatever doesn't meet the guidelines, then the
>>Incubator can certainly require that it be amended. But you should not
>>simply be able to kill it outright.
>
>
> +1. I think that's an important distinction to make.
>
> Proposals should require the "advice and consent" of the Incubator
> PMC. I agree that while the Incubator PMC shouldn't be able to kill
> the project, they can and should be able to say "Your charter sucks.
> Rewrite it. We won't sign off until that happens."
>
> It's about the form than the content. Roy's comments about Tuscany
> proposal are what I'd characterize in this mold.
Agreed, but the Tuscany proposal was an independent proposal, not
sponsored (at the time) by any PMC.
> The Incubator PMC
> should also be able to make a judgment ("certification"?) of the
> process proposed by the PMC - such as whether a code base should be
> under full incubation or just use the IP clearance form.
>
> I think that making it clear that the Incubator PMC can do this would
> go a long way to addressing some of the concerns already mentioned.
Agreed - although in general, if a PMC just ignored the input of the
Incubator PMC on a PMCs suggested incubation, it's an indication of a
problem anyway...
geir
> -- justin
>
> ---------------------------------------------------------------------
> 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
Re: Is the incubator out of control?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 12/29/05, Greg Stein <gs...@lyra.org> wrote:
> If another PMC decides a project should be incubated, they must
> provide the people to make that happen (so we achieve proper scaling
> and to put the effort on those who want the results). The Incubator
> can't refuse the project outright, but if the STATUS page or
> proposal/charter or whatever doesn't meet the guidelines, then the
> Incubator can certainly require that it be amended. But you should not
> simply be able to kill it outright.
+1. I think that's an important distinction to make.
Proposals should require the "advice and consent" of the Incubator
PMC. I agree that while the Incubator PMC shouldn't be able to kill
the project, they can and should be able to say "Your charter sucks.
Rewrite it. We won't sign off until that happens."
It's about the form than the content. Roy's comments about Tuscany
proposal are what I'd characterize in this mold. The Incubator PMC
should also be able to make a judgment ("certification"?) of the
process proposed by the PMC - such as whether a code base should be
under full incubation or just use the IP clearance form.
I think that making it clear that the Incubator PMC can do this would
go a long way to addressing some of the concerns already mentioned.
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Dec 28, 2005 at 03:16:42PM -0500, Noel J. Bergman wrote:
>...
> - the Board will determine if there is an Incubator PMC vote to
> accept a new project, but at the moment, any PMC can vote to
> bring a new project into the Incubator, assuming that they
> otherwise meet the guidelines.
Yup. And that's the way that I think it should be. The Incubator is
not "close enough" to the problem to make a determination *against*
another PMCs rightful decision that a project would be beneficial for
the ASF. Recognize that other PMCs are *also* operating within the
best interests of the Foundation. That should be a given, and if you
think a PMC is *not* operating that way, then you bring it to the
Board. You don't exercise your displeasure by interfering with the
work that they are trying to accomplish [to benefit the Foundation].
If another PMC decides a project should be incubated, they must
provide the people to make that happen (so we achieve proper scaling
and to put the effort on those who want the results). The Incubator
can't refuse the project outright, but if the STATUS page or
proposal/charter or whatever doesn't meet the guidelines, then the
Incubator can certainly require that it be amended. But you should not
simply be able to kill it outright. Go to the Board for that because
the implication is that the PMC is not acting in the Foundation's best
interests, and THAT is for the Board to handle. Not the Incubator.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Steven Noels wrote:
> The Incubator PMC only needs to care about IP and legal blahblah,
> thus the receiving PMCs are tasked with community and brand abuse
> stuff.
Not true. If there is community development, the Incubator PMC had better
be involved. We're going to have to adjust things, such as Mentorship and
votes to leave the Incubator, e.g.,
- a minimum of 3 ASF Members and/or Officers who have differing
corporate affiliations as Mentors per project. The sponsoring
PMC must identify those ASF Members. Projects who lose one or
more sponsors -- even if they just go quiet -- must make sure
that they regain the minimum of 3. Existing projects that are
not meeting the quorum will not be permitted to release any
code, regardless of otherwise meeting Incubator release guidelines.
- the Board will determine if there is an Incubator PMC vote to
accept a new project, but at the moment, any PMC can vote to
bring a new project into the Incubator, assuming that they
otherwise meet the guidelines. There are still guidelines
regarding candidacy, and the Board will be encouraged to
take a dim view of any PMC trying to game the system.
- the Incubator PMC having the sole vote on all graduations from
the Incubator. The target PMC votes to accept first, and then
notifies us that they are ready for our vote.
It is a talking point, but we may have to perform that vote even on simpler
IP imports, just to prevent gaming the system, e.g., "well, it's not really
a new project". Actually, all of those are talking points.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Steven Noels <st...@outerthought.org>.
On 21 Dec 2005, at 10:50, Ted Leung wrote:
> Unfortunately, I don't agree with that. I think that the incubation
> process is setting an incredibly low bar for access to the Apache
> brand name, and this is a bad thing. Corporations see the value of
> the brand name, that's why they want to come here and are willing to
> put up with all our overhead.
I agree but i believe we're picking the wrong example. For me, the low
bar is because many code donations are happening in the folds of
other-than-the-Incubator PMC: The Incubator PMC only needs to care
about IP and legal blahblah, thus the receiving PMCs are tasked with
community and brand abuse stuff. Combine this with mentors preferring
to read and use the system as it has been designed and drafted
literally, rather than according to what the (somewhat intangible)
Apache Way dictates, and this is bound to create tension.
Quite frankly, I don't have the slightest idea anymore what is
happening in the WebServices and Geronimo corner of Apache. That's
either an indication of the fact that I should read more mail (yeah
right), or something slightly more worrying. Too much, too fast, too
eager, too soon. That way, we'll burn out rather than fade away. :)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought Open Source Java & XML
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
In theory, the sponsor and mentors are doing that continuously.
geir
On Dec 21, 2005, at 10:51 AM, Rob Davies wrote:
>
> I Also share these concerns - is there currently a process to have
> continuous reviews throughout the entire life-cycle of all new and
> existing projects - to ensure that everything under the 'apache'
> brand is and will continue to be 'worthy' ?
>
> Sorry if there's already a process in place - I'm new :)
>
> cheers,
>
> Rob
>
>
> On 21 Dec 2005, at 15:18, Mads Toftum wrote:
>
>> On Wed, Dec 21, 2005 at 01:50:28AM -0800, Ted Leung wrote:
>>> The merits of the particular proposal aside, I wanted to comment on
>>> this paragraph. This year at ApacheCon I was surprised to find
>>> that
>>> a number of people also feel that the ASF is growing far too
>>> quickly. I know that are some people who believe that the growth
>>> that we are experiencing is indicative of our success.
>>> Unfortunately, I don't agree with that. I think that the
>>> incubation process is setting an incredibly low bar for access to
>>> the
>>> Apache brand name, and this is a bad thing.
>>
>> Very much agreed - I've been worried about the same for quite a
>> while.
>>
>> vh
>>
>> Mads Toftum
>> --
>> `Darn it, who spiked my coffee with water?!' - lwall
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Rob Davies <ra...@gmail.com>.
I Also share these concerns - is there currently a process to have
continuous reviews throughout the entire life-cycle of all new and
existing projects - to ensure that everything under the 'apache'
brand is and will continue to be 'worthy' ?
Sorry if there's already a process in place - I'm new :)
cheers,
Rob
On 21 Dec 2005, at 15:18, Mads Toftum wrote:
> On Wed, Dec 21, 2005 at 01:50:28AM -0800, Ted Leung wrote:
>> The merits of the particular proposal aside, I wanted to comment on
>> this paragraph. This year at ApacheCon I was surprised to find that
>> a number of people also feel that the ASF is growing far too
>> quickly. I know that are some people who believe that the growth
>> that we are experiencing is indicative of our success.
>> Unfortunately, I don't agree with that. I think that the
>> incubation process is setting an incredibly low bar for access to the
>> Apache brand name, and this is a bad thing.
>
> Very much agreed - I've been worried about the same for quite a while.
>
> vh
>
> Mads Toftum
> --
> `Darn it, who spiked my coffee with water?!' - lwall
>
>
> ---------------------------------------------------------------------
> 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
Re: Is the incubator out of control?
Posted by Mads Toftum <ma...@toftum.dk>.
On Wed, Dec 21, 2005 at 01:50:28AM -0800, Ted Leung wrote:
> The merits of the particular proposal aside, I wanted to comment on
> this paragraph. This year at ApacheCon I was surprised to find that
> a number of people also feel that the ASF is growing far too
> quickly. I know that are some people who believe that the growth
> that we are experiencing is indicative of our success.
> Unfortunately, I don't agree with that. I think that the
> incubation process is setting an incredibly low bar for access to the
> Apache brand name, and this is a bad thing.
Very much agreed - I've been worried about the same for quite a while.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 21, 2005, at 4:50 AM, Ted Leung wrote:
> On Dec 20, 2005, at 4:49 PM, Martin Cooper wrote:
>
>> Personally, I am less than happy at seeing yet another large project
>> proposed from a corporate source (and IBM at that), along with a
>> dozen new
>> committers who have not earned their merit at the ASF as most
>> committers
>> have. I feel the ASF is losing its way, and becoming a repository for
>> corporate open-sourcing along with taking on responsibility for
>> building
>> communities around corporate code bases. I suspect I'm in the
>> minority at
>> the ASF, and I'm undoubtedly in the minority here in the
>> incubator. But
>> there doesn't seem to be a way for the incubator to say "no
>> thanks", other
>> than by a podling failing the incubation process, and that seems
>> wrong to
>> me.
>
> The merits of the particular proposal aside, I wanted to comment
> on this paragraph. This year at ApacheCon I was surprised to find
> that a number of people also feel that the ASF is growing far too
> quickly. I know that are some people who believe that the growth
> that we are experiencing is indicative of our success.
> Unfortunately, I don't agree with that. I think that the
> incubation process is setting an incredibly low bar for access to
> the Apache brand name, and this is a bad thing. Corporations see
> the value of the brand name, that's why they want to come here and
> are willing to put up with all our overhead.
>
Unless we are very careful, Incubator will become a much
larger mess than the Jakarta project ever was... Which
would be quite ironic.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Sam Ruby <ru...@apache.org>.
Ted Leung wrote:
> On Dec 20, 2005, at 4:49 PM, Martin Cooper wrote:
>
> Corporations see the value of the brand name, that's why
> they want to come here and are willing to put up with all our overhead.
I can't speak for all corporations, but I can speak to the proposals
that I have dealt with at my corporation.
IBM is fully aware that places like DeveloperWorks and SourceForge
exist. The prevalent view is that such places tend to end up being
fishbowls whereby developers can work and be observed. By contrast, the
ASF is viewed as a place to build a diverse and sustainable community.
This discussion, the attendant angst and so called "overhead", are
recognized as part of the package, i.e., necessary to establish the
desired diversity and community involvement.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 23, 2005, at 11:26 AM, Davanum Srinivas wrote:
> Hmmm...But the deal is if the PMC wants a change to its charter it
> needs to VOTE on it and formally adopt it. right? AND if the PMC does
> not have one then it needs to adhere to the board resolution. right?
>
> You know where i am going with this, if you read between the lines...
There's lots of places to go with this :) I guess we need to clarify
if we are talking about the charter as from the baord "Thou shalt do
webservices" which I do think is up to the board to change (in
conjunction with the PMC) or the project bylaws/guidlines setup
entirely by the PMC "We shalt to webservices in this manner...."
I believe that many projects do not conform precisely to their
project charter but still work in healthy and collaborative ways...
geir
>
> -- dims
>
> On 12/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>> Every TLP has an explicit charter when created by the board in the
>> resolution that creates them. How they interpret that and change
>> with the shifting sands of technology style is up to them....
>>
>> geir
>>
>> On Dec 23, 2005, at 10:31 AM, Davanum Srinivas wrote:
>>
>>> Sounds good to me (hopefully all our TLP's will have charters
>>> soon!!).
>>>
>>> -- dims
>>>
>>> On 12/23/05, Sam Ruby <ru...@apache.org> wrote:
>>>> Davanum Srinivas wrote:
>>>>> Sam,
>>>>>
>>>>> it's not just a question of content and significance. It's also a
>>>>> question of fitting with existing projects and check to make sure
>>>>> that
>>>>> the project still adheres to the the charter of the PMC. These are
>>>>> better checked by outsiders ("Incubator PMC"), since the insiders
>>>>> ("WS
>>>>> PMC") may be biased.
>>>>
>>>> I don't believe that it is the incubator's job to watch to make
>>>> sure
>>>> that existing projects stay to their charters - that's the job of
>>>> the board.
>>>>
>>>>> Another thing i can think of is, for example, when HTTPComponents
>>>>> (by
>>>>> internal people) was being set up there was resistance from tomcat
>>>>> folks. But the scope got resolved by active participation by folks
>>>>> from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC
>>>>> already voted to accept something even before Incubator PMC knows
>>>>> about it (not to mention the other PMC's who may significant
>>>>> input).
>>>>
>>>> Again, I don't believe that it is the incubator's job to enforce
>>>> scope.
>>>> Furthermore, acceptance by the incubator is the start of a
>>>> process,
>>>> not the end of it. There should be adequate opportunity for
>>>> people to
>>>> provide input during the course of incubation.
>>>>
>>>> - Sam Ruby
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas : http://wso2.com/blogs/
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Dec 23, 2005 at 11:26:38AM -0500, Davanum Srinivas wrote:
> Hmmm...But the deal is if the PMC wants a change to its charter it
> needs to VOTE on it and formally adopt it. right? AND if the PMC does
> not have one then it needs to adhere to the board resolution. right?
>
> You know where i am going with this, if you read between the lines...
I'd have no problem saying that any podling seeking TLP status from the
Board must have a charter and project bylaws written up before graduation.
We've learned our lesson in that projects without these go iffy. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Davanum Srinivas <da...@gmail.com>.
Hmmm...But the deal is if the PMC wants a change to its charter it
needs to VOTE on it and formally adopt it. right? AND if the PMC does
not have one then it needs to adhere to the board resolution. right?
You know where i am going with this, if you read between the lines...
-- dims
On 12/23/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> Every TLP has an explicit charter when created by the board in the
> resolution that creates them. How they interpret that and change
> with the shifting sands of technology style is up to them....
>
> geir
>
> On Dec 23, 2005, at 10:31 AM, Davanum Srinivas wrote:
>
> > Sounds good to me (hopefully all our TLP's will have charters soon!!).
> >
> > -- dims
> >
> > On 12/23/05, Sam Ruby <ru...@apache.org> wrote:
> >> Davanum Srinivas wrote:
> >>> Sam,
> >>>
> >>> it's not just a question of content and significance. It's also a
> >>> question of fitting with existing projects and check to make sure
> >>> that
> >>> the project still adheres to the the charter of the PMC. These are
> >>> better checked by outsiders ("Incubator PMC"), since the insiders
> >>> ("WS
> >>> PMC") may be biased.
> >>
> >> I don't believe that it is the incubator's job to watch to make sure
> >> that existing projects stay to their charters - that's the job of
> >> the board.
> >>
> >>> Another thing i can think of is, for example, when HTTPComponents
> >>> (by
> >>> internal people) was being set up there was resistance from tomcat
> >>> folks. But the scope got resolved by active participation by folks
> >>> from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC
> >>> already voted to accept something even before Incubator PMC knows
> >>> about it (not to mention the other PMC's who may significant input).
> >>
> >> Again, I don't believe that it is the incubator's job to enforce
> >> scope.
> >> Furthermore, acceptance by the incubator is the start of a process,
> >> not the end of it. There should be adequate opportunity for
> >> people to
> >> provide input during the course of incubation.
> >>
> >> - Sam Ruby
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Every TLP has an explicit charter when created by the board in the
resolution that creates them. How they interpret that and change
with the shifting sands of technology style is up to them....
geir
On Dec 23, 2005, at 10:31 AM, Davanum Srinivas wrote:
> Sounds good to me (hopefully all our TLP's will have charters soon!!).
>
> -- dims
>
> On 12/23/05, Sam Ruby <ru...@apache.org> wrote:
>> Davanum Srinivas wrote:
>>> Sam,
>>>
>>> it's not just a question of content and significance. It's also a
>>> question of fitting with existing projects and check to make sure
>>> that
>>> the project still adheres to the the charter of the PMC. These are
>>> better checked by outsiders ("Incubator PMC"), since the insiders
>>> ("WS
>>> PMC") may be biased.
>>
>> I don't believe that it is the incubator's job to watch to make sure
>> that existing projects stay to their charters - that's the job of
>> the board.
>>
>>> Another thing i can think of is, for example, when HTTPComponents
>>> (by
>>> internal people) was being set up there was resistance from tomcat
>>> folks. But the scope got resolved by active participation by folks
>>> from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC
>>> already voted to accept something even before Incubator PMC knows
>>> about it (not to mention the other PMC's who may significant input).
>>
>> Again, I don't believe that it is the incubator's job to enforce
>> scope.
>> Furthermore, acceptance by the incubator is the start of a process,
>> not the end of it. There should be adequate opportunity for
>> people to
>> provide input during the course of incubation.
>>
>> - Sam Ruby
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Davanum Srinivas <da...@gmail.com>.
Sounds good to me (hopefully all our TLP's will have charters soon!!).
-- dims
On 12/23/05, Sam Ruby <ru...@apache.org> wrote:
> Davanum Srinivas wrote:
> > Sam,
> >
> > it's not just a question of content and significance. It's also a
> > question of fitting with existing projects and check to make sure that
> > the project still adheres to the the charter of the PMC. These are
> > better checked by outsiders ("Incubator PMC"), since the insiders ("WS
> > PMC") may be biased.
>
> I don't believe that it is the incubator's job to watch to make sure
> that existing projects stay to their charters - that's the job of the board.
>
> > Another thing i can think of is, for example, when HTTPComponents (by
> > internal people) was being set up there was resistance from tomcat
> > folks. But the scope got resolved by active participation by folks
> > from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC
> > already voted to accept something even before Incubator PMC knows
> > about it (not to mention the other PMC's who may significant input).
>
> Again, I don't believe that it is the incubator's job to enforce scope.
> Furthermore, acceptance by the incubator is the start of a process,
> not the end of it. There should be adequate opportunity for people to
> provide input during the course of incubation.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Sam Ruby <ru...@apache.org>.
Davanum Srinivas wrote:
> Sam,
>
> it's not just a question of content and significance. It's also a
> question of fitting with existing projects and check to make sure that
> the project still adheres to the the charter of the PMC. These are
> better checked by outsiders ("Incubator PMC"), since the insiders ("WS
> PMC") may be biased.
I don't believe that it is the incubator's job to watch to make sure
that existing projects stay to their charters - that's the job of the board.
> Another thing i can think of is, for example, when HTTPComponents (by
> internal people) was being set up there was resistance from tomcat
> folks. But the scope got resolved by active participation by folks
> from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC
> already voted to accept something even before Incubator PMC knows
> about it (not to mention the other PMC's who may significant input).
Again, I don't believe that it is the incubator's job to enforce scope.
Furthermore, acceptance by the incubator is the start of a process,
not the end of it. There should be adequate opportunity for people to
provide input during the course of incubation.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Davanum Srinivas <da...@gmail.com>.
Sam,
it's not just a question of content and significance. It's also a
question of fitting with existing projects and check to make sure that
the project still adheres to the the charter of the PMC. These are
better checked by outsiders ("Incubator PMC"), since the insiders ("WS
PMC") may be biased.
Another thing i can think of is, for example, when HTTPComponents (by
internal people) was being set up there was resistance from tomcat
folks. But the scope got resolved by active participation by folks
from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC
already voted to accept something even before Incubator PMC knows
about it (not to mention the other PMC's who may significant input).
Thanks,
dims
On 12/23/05, Sam Ruby <ru...@apache.org> wrote:
> Jim Jagielski wrote:
> >
> > On Dec 22, 2005, at 6:23 PM, Roy T. Fielding wrote:
> >
> >> On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
> >>
> >>> So nobody has the right but you do? Or how can your smack-down of
> >>> the Tuscany proposal be interpreted?
> >>
> >> Because Tuscany was proposed to the incubator PMC (not another PMC)
> >> and I do have a vote here.
> >
> > It's interesting to note that if Dims would have, as he suggested
> > in one of his Email messages, to simply have the WS PMC vote
> > on the proposal as is, and it would have passed it, Roy's
> > concerns would have been totally moot. So no matter how good
> > or vague the proposal, if voted on by a PMC, it's allowed.
>
> A bunch of hypotheticals in there.
>
> If the WS-PMC had voted to approve a proposal that was "empty of
> significant content", then I would question the viability of that PMC.
>
> But as it is, that never happened. A draft proposal was created, it was
> reviewed by others, updated, and the objection based on lack of content
> was dropped. That could very well have happened in the WS PMC as well
> as here.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Sam Ruby <ru...@apache.org>.
Jim Jagielski wrote:
>
> On Dec 22, 2005, at 6:23 PM, Roy T. Fielding wrote:
>
>> On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
>>
>>> So nobody has the right but you do? Or how can your smack-down of
>>> the Tuscany proposal be interpreted?
>>
>> Because Tuscany was proposed to the incubator PMC (not another PMC)
>> and I do have a vote here.
>
> It's interesting to note that if Dims would have, as he suggested
> in one of his Email messages, to simply have the WS PMC vote
> on the proposal as is, and it would have passed it, Roy's
> concerns would have been totally moot. So no matter how good
> or vague the proposal, if voted on by a PMC, it's allowed.
A bunch of hypotheticals in there.
If the WS-PMC had voted to approve a proposal that was "empty of
significant content", then I would question the viability of that PMC.
But as it is, that never happened. A draft proposal was created, it was
reviewed by others, updated, and the objection based on lack of content
was dropped. That could very well have happened in the WS PMC as well
as here.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 23, 2005, at 5:14 AM, Jim Jagielski wrote:
> On Dec 22, 2005, at 6:23 PM, Roy T. Fielding wrote:
>> On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
>>>
>>> So nobody has the right but you do? Or how can your smack-down of
>>> the Tuscany proposal be interpreted?
>>
>> Because Tuscany was proposed to the incubator PMC (not another PMC)
>> and I do have a vote here.
>
> It's interesting to note that if Dims would have, as he suggested
> in one of his Email messages, to simply have the WS PMC vote
> on the proposal as is, and it would have passed it, Roy's
> concerns would have been totally moot. So no matter how good
> or vague the proposal, if voted on by a PMC, it's allowed.
Yes, and I trust the other PMCs to be responsible for their
own actions.
I think people forget that the Incubator is just a place where
people incubate their own projects. The PMC doesn't incubate them.
The PMC is just the collective dude with a finger on the
good egg/bad egg reject button.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 22, 2005, at 6:23 PM, Roy T. Fielding wrote:
> On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
>>
>> So nobody has the right but you do? Or how can your smack-down of
>> the Tuscany proposal be interpreted?
>
> Because Tuscany was proposed to the incubator PMC (not another PMC)
> and I do have a vote here.
It's interesting to note that if Dims would have, as he suggested
in one of his Email messages, to simply have the WS PMC vote
on the proposal as is, and it would have passed it, Roy's
concerns would have been totally moot. So no matter how good
or vague the proposal, if voted on by a PMC, it's allowed.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 22, 2005, at 6:23 PM, Roy T. Fielding wrote:
> On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
>> On 21.12.2005, at 21:57, Roy T. Fielding wrote:
>>> On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
>>>> How is this possible when any other PMC can vote to bring a
>>>> project in without approval of the incubator PMC? Just look at
>>>> the raft of projects being brought in via Geronimo and the WS
>>>> PMC. There's not a thing I can do, regardless of the merits.
>>>> The only thing I can say is whether or not their community is
>>>> good enough to merit graduation.
>>>
>>> Right, and that's the only thing you are qualified to do. You don't
>>> have the right to tell other people what they can or cannot do at
>>> the ASF. You don't have the right to say that one project is more
>>> deserving of our resources than some other project. What you do
>>> have
>>> is the right to be involved, to help their incubation (or not), and
>>> to vote against their graduation if you so desire.
>>
>> So nobody has the right but you do? Or how can your smack-down of
>> the Tuscany proposal be interpreted?
>
> Because Tuscany was proposed to the incubator PMC (not another PMC)
> and I do have a vote here. In any case, I objected to the proposal
> because it was empty of significant content, and removed by objection
> once it was filled. I did not prevent them from working on an
> architecture that I still believe to be a waste of time -- I only
> made sure that they all agreed on what they wanted to work on,
> because I think that is a minimum for any collaboration.
As the sponsor/champion of Tuscany, I'll be the first to admit that
Roy was actually right on with his criticism.
The proposal didn't reflect what the proposers were actually
thinking, and it forced the team to review and rewrite, and the
result is IMO a stronger, clearer proposal and statement of intent.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Erik Abele wrote:
> Roy T. Fielding wrote:
>>> What you do have is the right to vote against their graduation if
>>> you so desire.
> The second sentence does exactly what the first sentence forbids, no?
> It tells people what they cannot do at the ASF.
It is established that the Incubator is the sole authority on new entry
into the ASF. The talking point is the barrier into the vestibule, if you
will.
Roy wants an open policy, others are concerned that there is too much
chaos and confusion in the antechambers. Worse, they are concerned that
projects under the Incubator may be causing confusion about what is and is
not under the imprimatur of the ASF.
We can revisit branding, but I don't believe that a totally non-ASF brand
is at all warranted, as explained by Justin.
--- Noel
Re: Is the incubator out of control?
Posted by Erik Abele <er...@codefaktor.de>.
On 23.12.2005, at 00:23, Roy T. Fielding wrote:
> On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
>> On 21.12.2005, at 21:57, Roy T. Fielding wrote:
>>> On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
>>>> How is this possible when any other PMC can vote to bring a
>>>> project in without approval of the incubator PMC? Just look at
>>>> the raft of projects being brought in via Geronimo and the WS
>>>> PMC. There's not a thing I can do, regardless of the merits.
>>>> The only thing I can say is whether or not their community is
>>>> good enough to merit graduation.
>>>
>>> Right, and that's the only thing you are qualified to do. You don't
>>> have the right to tell other people what they can or cannot do at
>>> the ASF. You don't have the right to say that one project is more
>>> deserving of our resources than some other project. What you do
>>> have
>>> is the right to be involved, to help their incubation (or not), and
>>> to vote against their graduation if you so desire.
>>
>> So nobody has the right but you do? Or how can your smack-down of
>> the Tuscany proposal be interpreted?
>
> Because Tuscany was proposed to the incubator PMC (not another PMC)
> and I do have a vote here. In any case, I objected to the proposal
> because it was empty of significant content, and removed by objection
> once it was filled. I did not prevent them from working on an
> architecture that I still believe to be a waste of time -- I only
> made sure that they all agreed on what they wanted to work on,
> because I think that is a minimum for any collaboration.
That's all fine and to be honest I didn't expect a detailed answer to
my exaggerated question - what I wanted to show is that your
authoritative sounding reply to Ted did contain a very conflictive
view and I think that might confuse a lot of people:
>>> You don't have the right to tell other people what they can or
>>> cannot do at the ASF.
vs.
>>> What you do have is the right to vote against their graduation if
>>> you so desire.
The second sentence does exactly what the first sentence forbids, no?
It tells people what they cannot do at the ASF.
Maybe I'm too picky or this is a language thing, not sure - just
wanted to point that out.
>> Sorry, I may be a pain in the ass, but that's all very conflictive
>> IMHO...
>
> Pay attention to the details.
I do.
Cheers,
Erik
Re: Is the incubator out of control?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 22, 2005, at 10:53 AM, Erik Abele wrote:
> On 21.12.2005, at 21:57, Roy T. Fielding wrote:
>> On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
>>> How is this possible when any other PMC can vote to bring a
>>> project in without approval of the incubator PMC? Just look at
>>> the raft of projects being brought in via Geronimo and the WS
>>> PMC. There's not a thing I can do, regardless of the merits.
>>> The only thing I can say is whether or not their community is
>>> good enough to merit graduation.
>>
>> Right, and that's the only thing you are qualified to do. You don't
>> have the right to tell other people what they can or cannot do at
>> the ASF. You don't have the right to say that one project is more
>> deserving of our resources than some other project. What you do have
>> is the right to be involved, to help their incubation (or not), and
>> to vote against their graduation if you so desire.
>
> So nobody has the right but you do? Or how can your smack-down of
> the Tuscany proposal be interpreted?
Because Tuscany was proposed to the incubator PMC (not another PMC)
and I do have a vote here. In any case, I objected to the proposal
because it was empty of significant content, and removed by objection
once it was filled. I did not prevent them from working on an
architecture that I still believe to be a waste of time -- I only
made sure that they all agreed on what they wanted to work on,
because I think that is a minimum for any collaboration.
> Sorry, I may be a pain in the ass, but that's all very conflictive
> IMHO...
Pay attention to the details.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Erik Abele <er...@codefaktor.de>.
On 21.12.2005, at 21:57, Roy T. Fielding wrote:
> On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
>> How is this possible when any other PMC can vote to bring a
>> project in without approval of the incubator PMC? Just look at
>> the raft of projects being brought in via Geronimo and the WS
>> PMC. There's not a thing I can do, regardless of the merits.
>> The only thing I can say is whether or not their community is good
>> enough to merit graduation.
>
> Right, and that's the only thing you are qualified to do. You don't
> have the right to tell other people what they can or cannot do at
> the ASF. You don't have the right to say that one project is more
> deserving of our resources than some other project. What you do have
> is the right to be involved, to help their incubation (or not), and
> to vote against their graduation if you so desire.
So nobody has the right but you do? Or how can your smack-down of the
Tuscany proposal be interpreted?
On 30.11.2005, at 21:43, Roy T. Fielding wrote:
> As much as I would enjoy seeing two umbrella projects duel over
> an amorphous set of marketing terms invented by IBM, I think the
> ASF should be developing products, not architectural styles.
> Although, calling SOA an architectural style would imply that it has
> some constraints -- does anyone know what they are?
>
> I think we need to reorganize around federations, but that's a
> very long discussion that I have no time for right now. We certainly
> don't need more than one WS/SOA federation.
>
> Please make the proposal specific to a single, technical product
> line that has objective criteria against which you can make basic
> decisions about what to release and when it is ready to release.
> That way we aren't just sponsoring a bunch of individuals, each
> working on their own solo project within an opaque mist of vague
> relationships.
So why don't you get involved instead or vote against their
graduation if you so desire?
Sorry, I may be a pain in the ass, but that's all very conflictive
IMHO...
Cheers,
Erik
Re: Is the incubator out of control?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Dec 21, 2005 at 12:57:59PM -0800, Roy T. Fielding wrote:
> On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
> >How is this possible when any other PMC can vote to bring a project
> >in without approval of the incubator PMC? Just look at the raft of
> >projects being brought in via Geronimo and the WS PMC. There's
> >not a thing I can do, regardless of the merits. The only thing I
> >can say is whether or not their community is good enough to merit
> >graduation.
>
> Right, and that's the only thing you are qualified to do. You don't
> have the right to tell other people what they can or cannot do at
> the ASF. You don't have the right to say that one project is more
> deserving of our resources than some other project. What you do have
> is the right to be involved, to help their incubation (or not), and
> to vote against their graduation if you so desire.
Exactly. The other PMCs are authorized to perform actions on the ASF's
behalf, in the interests of the ASF. If they determine that bringing
Project FOO to the ASF is the best choice, then it is a done deal
unless overridden by the Board. And I will note that the Board will
give extreme prejudice to the authorizing PMC, so any appeal to the
Board better have some good reasoning :-)
The Incubator *is* charged with ensuring that the legal needs have
been met, and that there has been appropriate teaching about how
Apache projects are run. The Board *has* authorized them with
performing those actions.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 23 December 2005 21:55, Geir Magnusson Jr. wrote:
> There are lots of bad reasons to come to the ASF and high on my list
> is "to take advantage of the brand".
A safe bet is that there are a lot of "brand talks" involved in the
discussions "let's move to Apache".
I am sure that there are "brand leveraging" going on in existing projects and
their 'affiliated' companies. I am sure individuals leverage the brand for
private awards, be it speaker engagements, consultancy jobs or what not.
ASF can not escape "the brand" due to its success in various projects. It
needs to embrace that this is a reality, and deal with it in a dilligent
manner. Saying "fascination of the Apache brand" disqualifies a project for
Incubation is far too naive, leading to acceptance of those projects that
manages to mask or hide such "fascination". IMHO, rules that can be broken
without detection is effectively of no use.
A sidenote to that; It is interesting to notice that many projects seeking
incubation, make the assertion that "ASF is strong in building
communities" (which seems to sooth ASF a lot), yet projects are expected to
have strong communities prior to being accepted.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by David Crossley <cr...@apache.org>.
Jochen Wiedmann wrote:
> robert burrell donkin wrote:
>
> >IMHO it would be better to ask pmc'er to vote not for a passive sponsorship
> >but an active promise to commit resources to provide oversight for the
> >podling.
>
> When asked to vote for a new podling on the WS PMC, I never understood a
> +1 to mean something different?
Yes, i reckon that you are onto something there, Robert.
In my book, a +1 vote means "yes i want it to happen
and i will help to make it happen". Otherwise vote +0
to mean "i don't feel strongly about it, but I'm okay with it".
Reading between the lines of the definitions at
http://www.apache.org/foundation/voting.html
seems to support that.
I have never helped mentor a project, but imagine
that it would hard without more old-hands helping
to lead the way for the community and procedural
side of things.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jochen Wiedmann <jo...@gmail.com>.
robert burrell donkin wrote:
> IMHO it would be better to ask pmc'er to vote not for a passive sponsorship
> but an active promise to commit resources to provide oversight for the
> podling.
When asked to vote for a new podling on the WS PMC, I never understood a
+1 to mean something different?
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/23/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
<snip>
If any ASF PMC believes it is in the best interest of the Foundation to
> accept a podling and they are willing to dedicate resources ("people") -
> then anyone on the Incubator PMC has no standing to challenge that
> decision. When a PMC approves a podling, the only thing the Incubator PMC
> can decide is whether the project can "leave" the Incubator.
IMO this highlights one of the problems: ATM pmc's do not need to commit to
anything other than a vague promise that they'll consider accepting the
podling after graduation. if they decide that they don't want the podling
then they can just ask that it becomes a TLP. so, voting +1 has no cost to
the pmc.
IMHO it would be better to ask pmc'er to vote not for a passive sponsorship
but an active promise to commit resources to provide oversight for the
podling.
- robert
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 23, 2005, at 4:07 AM, Justin Erenkrantz wrote:
> That's the fundamental problem I have with this entire thread: people
> are trying to limit the growth or exclude projects. How? On what
> basis?
>
In my mind, there are 2 considerations: What is in the best interest
of the PMC, and what is in the best interest of the ASF. For
the vast majority of the time, the 2 dovetail v. nicely, and
there are no problems. However, it is possible for things to
conflict, and something that a PMC wants to not coincide with
the best interests of the ASF. Again, I would remind people
of the origin problems with Jakarta as an example.
I feel that the board has the responsibility to look after
what is in the best interests of the ASF. I also feel that
they have delegated this responsibility, as far as "monitoring
and regulating" new projects to the Incubator.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 23, 2005, at 10:57 AM, Justin Erenkrantz wrote:
> On Fri, Dec 23, 2005 at 09:11:55AM -0500, Geir Magnusson Jr. wrote:
>> I am no longer convinced of this. Having the Incubator PMC there as
>> a "check and balance" is a good thing as it requires engagement from
>> others interested in this aspect of ASF life. It prevents one
>> individual or one PMC from being able to make significant social or
>> technological change, or at least ensure that there is a
>> theoretically impartial observer keeping track. It allows interested
>> members and other community members to "put their money where their
>> mouth is" on this topic, and join the Incubator PMC to help out.
>
> I don't think that can scale appropriately.
>
> Why would the Incubator PMC know more about whether mod_ftp is a
> good fit
> for the Foundation than the entire HTTP Server PMC?
I certainly agree that in 99% of the cases, this would be the case,
and I would never expect the Incubator PMC to ever stand in the way
of any proposal unless there is good reason of broader scope.
Healthy PMCs will IMO always do the right thing.
I was thinking more along the lines of the Incubator having to vote
and therefore do some due-diligence. It also does give the Incubator
PMC some control over rate of growth. I'm worried about growth, but
not anti-, but certainly worry about the incubator being stretched
too thin to effectively provide the legal oversight and community
shaping. Our incoming rate is faster than the outgoing rate - at
what point do we have more than we can handle?
Imagine if every PMC did what the Geronimo PMC just did, and invited
in say 5 new projects (as is their right).
That's about 150 new podlings at once. How would we deal with that?
I don't expect this to happen, but maybe you can see my point.
>
>> I think that there's little downside to this. A check on the
>> Incubator PMC is the board - any member or PMC could appeal to the
>> board in the event that they believed their proposals were not being
>> treated fairly, or if the Incubator PMC was behaving in general in a
>> way they disagreed with.
>>
>> And the board has to answer to the membership.
>
> I believe that there is *major* downside to having the Incubator PMC
> second-guess the decisions of other PMCs.
>
> If someone doesn't like the decision of a PMC, they shouldn't be
> able to
> use the Inucbator PMC as cover for their attacks. People who don't
> like
> what's going on in that PMC should confront that PMC directly. If
> they
> don't like what's going on in that PMC and have tried to redress their
> grievances directly, they can go to the Board.
I'm assuming a healthy Incubator PMC here - not one in which one
person can leverage to attack a PMC.
> Although, the Board is rightly wary of interposing itself in technical
> decisions. We have no idea what makes technical sense or not either.
Right - I wouldn't think that the Incubator PMC would want to make
decisions based on technical merit either. That's a non-starter - we
have to assume that each PMC is the most clueful in their technology
domain.
But code sources, committer diversity, availability of volunteer
resources in and around the incubator all are things we can
consider. Like it or not, the INcubator PMC is the locus of these
efforts, and it's real resources that are needed for each podling.
>
>>> Cynics like me are the *worst* possible judges of what's cool and
>>> what's
>>> not. That's the fundamental problem I have with this entire
>>> thread: people
>>> are trying to limit the growth or exclude projects. How? On what
>>> basis?
>>
>> I agree here - I would never want to exclude based on technology. I
>> do the thought experiment from time to time and ask myself which
>> projects I would have excluded if ordered to limit growth at the ASF,
>> and I never have a good answer. Maybe not let those "toaster language
>> bytecode people" in? I think our current java communities are a
>> *huge* asset. How about the pointy-bracket folks?
>>
>> We need to actually increase our technical diversity here - we have
>> no real Ruby-oriented communities, nor any coherent .NET identity,
>> and I think that's going to hurt us in the long run.
>
> That's why this talk about limiting growth is so dangerous. The
> foundation
> should go where our PMCs and our members want. -- justin
It's dangerous, but it's also a consideration of a vocal and active
part of the membership. It can't be ignored.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by David Crossley <cr...@apache.org>.
Justin Erenkrantz wrote:
>
> That's why this talk about limiting growth is so dangerous. The foundation
> should go where our PMCs and our members want. -- justin
I reckon that the way to handle it is to document our
processes properly. If each new podling got involved
in fine-tuning the content of the Incubator site docs
then we would quickly streamline the process for those
that follow. Everything would organically get easier.
A lot of time seems to be wasted in confusion about
what it means to be in the Incubator, how to get in,
how to exit, what needs to be learned before getting out,
operating principles, etc. We need some dot points.
The existing website content is a start, but it is in
dire need of attention. Thanks to Jean for the new energy.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/23/05, Erik Abele <er...@codefaktor.de> wrote:
> On 23.12.2005, at 16:57, Justin Erenkrantz wrote:
>
> > On Fri, Dec 23, 2005 at 09:11:55AM -0500, Geir Magnusson Jr. wrote:
> > ...
> >> I think that there's little downside to this. A check on the
> >> Incubator PMC is the board - any member or PMC could appeal to the
> >> board in the event that they believed their proposals were not being
> >> treated fairly, or if the Incubator PMC was behaving in general in a
> >> way they disagreed with.
> >> And the board has to answer to the membership.
> >
> > I believe that there is *major* downside to having the Incubator PMC
> > second-guess the decisions of other PMCs.
>
> +1.
>
> > If someone doesn't like the decision of a PMC, they shouldn't be
> > able to
> > use the Inucbator PMC as cover for their attacks. People who don't
> > like
> > what's going on in that PMC should confront that PMC directly. If
> > they
> > don't like what's going on in that PMC and have tried to redress their
> > grievances directly, they can go to the Board.
>
> +1.
requiring a vote by the incubator pmc would not be about second
guessing the wishes of a pmc but applying a second set of criteria.
these would be a subset of the criteria that the incubator pmc applies
to graduation. in most cases, this should be a formality but i believe
that these is sufficient concern amongst the membership to justify
adding this additional bit of ceremony.
(and yes, i do know that this sucks in many ways and this extra
ceremony will hamper community based proposals but i think that our
hand has been forced. we should deal with the problems surrounding
innovation and ceremony separately.)
IMO given that podlings are being aggressively publicised
(unfortunately now sometimes even before they are born) and strongly
associated with the ASF in the minds of the public, there is now a
certain level of due diligence which can no longer be left to be
sorted out once the podling has been accepted for incubation.
in particular:
1 project names (it's no longer good enough to enter the incubator
with a legally suspect name)
2 lack of oversight energy
3 that the initial legal paperwork is in order
4 any other issues which would give the podling no hope of graduating
including a formal vote from the incubator pmc would have (i believe)
additional process advantages: it will give a clear line for
evangelists - no talking about a potential podlings as if it were an
apache project until this vote is passed.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Growth Summary
Posted by Sam Ruby <ru...@apache.org>.
Justin Erenkrantz wrote:
> --On December 23, 2005 12:47:26 PM -0500 Jim Jagielski <ji...@jaguNET.com>
> wrote:
>
>> Q: The Incubator controls who leaves... who controls who
>> enters? It seems like both are needed.
>> A: Yes, and there are controls for who enters as well.
>> Applicants must be sponsored by a current PMC, or
>> the board. There is currently some discussion on
>
> I thought the Board delegated the initial proposal approval of new TLP
> projects (i.e. no sponsoring PMC) to the Incubator PMC? As a
> checkpoint, the Board will certify the *exit* of podling's TLPs after
> the Incubator certifies again. When a project has PMC approval, the
> Incubaotr PMC alone can do the certification of exit.
It effectively works out that way.
As a current PMC, the incubator can sponsor a proposal. In fact, the
incubator policy[1] explicitly calls out this case.
I don't expect the board to ever sponsor a project again - but then
again the board hasn't given up the right to do so.
- Sam Ruby
[1] http://incubator.apache.org/incubation/Incubation_Policy.html#Sponsor
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Growth Summary
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 23, 2005, at 5:34 PM, Justin Erenkrantz wrote:
> --On December 23, 2005 12:47:26 PM -0500 Jim Jagielski
> <ji...@jaguNET.com> wrote:
>
>> Q: The Incubator controls who leaves... who controls who
>> enters? It seems like both are needed.
>> A: Yes, and there are controls for who enters as well.
>> Applicants must be sponsored by a current PMC, or
>> the board. There is currently some discussion on
>
> I thought the Board delegated the initial proposal approval of new
> TLP projects (i.e. no sponsoring PMC) to the Incubator PMC? As a
> checkpoint, the Board will certify the *exit* of podling's TLPs
> after the Incubator certifies again. When a project has PMC
> approval, the Incubaotr PMC alone can do the certification of exit.
>
The board has always reserved the right to sponsor a new project. That
doesn't go away, even when we want the Incubator to do it.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Growth Summary
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On December 23, 2005 12:47:26 PM -0500 Jim Jagielski <ji...@jaguNET.com>
wrote:
> Q: The Incubator controls who leaves... who controls who
> enters? It seems like both are needed.
> A: Yes, and there are controls for who enters as well.
> Applicants must be sponsored by a current PMC, or
> the board. There is currently some discussion on
I thought the Board delegated the initial proposal approval of new TLP
projects (i.e. no sponsoring PMC) to the Incubator PMC? As a checkpoint,
the Board will certify the *exit* of podling's TLPs after the Incubator
certifies again. When a project has PMC approval, the Incubaotr PMC alone
can do the certification of exit.
Nice synergy there, methinks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Growth Summary
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'd like summarize the discussion so far, with comments
regarding my own PoV...
Q: Is the Incubator out of control?
A: No, it's not. The Incubator is actually working out
quite well, and performing its duties. Yes, occasionally
some things slip through the cracks, but "out of
control" hardly describes it. Note that whether or
not the Incubator is in or out of control is a
different question that anything regarding growth.
Q: Ok Mister Smart guy, is the ASF growing too quickly?
A: I'm sure that some members feel that we may be doing
so. I feel we are growing quickly, but wouldn't say
that it is "too" quickly. Certainly from a board
perspective, we could grow quite a bit (say double
the current size) with no real impact. And
Infrastructure is currently making plans on how
to handle growth and scale issues.
Q: Is the ASF doing anything to control growth?
A: There are 2 ways that the ASF grows. One is the addition
of additional members, PMC members and committers to the
community. I don't think that people, right now, are
too concerned about this type of growth, except maybe from
the membership aspect, and that's mostly for quorum legal
reasons (but again, I'm sure that some members likely
have some concerns about members being added before they
"should" be). No, it appears that most of the concern
is about growth of the number of projects, and I'm guessing
that this is what your question is really concerned about...
Q: Yes, it is. So, what's the answer?
A: All new projects (and incoming codebases) arrive at the
ASF via the Incubator. Without going into too much detail,
Incubated projects do not become ASF projects until
the are voted on graduation by the Incubator PMC. Thus,
the Incubator PMC serves as a gatekeeper for new ASF
projects.
Q: The Incubator controls who leaves... who controls who
enters? It seems like both are needed.
A: Yes, and there are controls for who enters as well.
Applicants must be sponsored by a current PMC, or
the board. There is currently some discussion on
whether the Incubator can (or should) also have some
say in this. Some feel that such a thing is either
outside of the "powers" given to the Incubator, or would
constitute undue influence of one PMC over another.
Others feel that the Incubator would be serving as
the eyes and ears of the board to ensure the continued
health of the ASF overall by having some say, a form
of "checks and balances."
Q: Sounds like a control issue... What's wrong with these
people!?
A: No, it's not. The people discussing this have a very deep
affinity for the ASF. They want what's best for the ASF,
and as with most things in life, sometimes people have
different points of views. It's unfair and inaccurate
to describe people as either careless (at the one end
of the spectrum) or control freaks (at the other).
Q: So why all the discussion?
A: The worst time to come to a consensus about an issue,
is when it is imminent. Being proactive is always a
good thing.
Q: So who decides?
A: The members do.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Erik Abele <er...@codefaktor.de>.
On 23.12.2005, at 16:57, Justin Erenkrantz wrote:
> On Fri, Dec 23, 2005 at 09:11:55AM -0500, Geir Magnusson Jr. wrote:
> ...
>> I think that there's little downside to this. A check on the
>> Incubator PMC is the board - any member or PMC could appeal to the
>> board in the event that they believed their proposals were not being
>> treated fairly, or if the Incubator PMC was behaving in general in a
>> way they disagreed with.
>> And the board has to answer to the membership.
>
> I believe that there is *major* downside to having the Incubator PMC
> second-guess the decisions of other PMCs.
+1.
> If someone doesn't like the decision of a PMC, they shouldn't be
> able to
> use the Inucbator PMC as cover for their attacks. People who don't
> like
> what's going on in that PMC should confront that PMC directly. If
> they
> don't like what's going on in that PMC and have tried to redress their
> grievances directly, they can go to the Board.
+1.
> ...
>> We need to actually increase our technical diversity here - we have
>> no real Ruby-oriented communities, nor any coherent .NET identity,
>> and I think that's going to hurt us in the long run.
>
> That's why this talk about limiting growth is so dangerous. The
> foundation
> should go where our PMCs and our members want. -- justin
I agree that it is very dangerous talking about limits ab initio -
but on the other hand I think it is very important to talk about
growth. I'm not sure what the outcome of this discussion will bring,
but I think we have seen enough concerns that it at least warrants a
discussion (not conclusions!).
Maybe we find out it is enough to more efficently control PR
activities or to require two or more mentors or ... I don't know but
I'd like to explore the possibilities.
(I've written about all the mentioned concerns on members@ but
unfortunately nobody picked up the list so far.)
Cheers,
Erik
Re: Is the incubator out of control?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Dec 23, 2005 at 09:11:55AM -0500, Geir Magnusson Jr. wrote:
> I am no longer convinced of this. Having the Incubator PMC there as
> a "check and balance" is a good thing as it requires engagement from
> others interested in this aspect of ASF life. It prevents one
> individual or one PMC from being able to make significant social or
> technological change, or at least ensure that there is a
> theoretically impartial observer keeping track. It allows interested
> members and other community members to "put their money where their
> mouth is" on this topic, and join the Incubator PMC to help out.
I don't think that can scale appropriately.
Why would the Incubator PMC know more about whether mod_ftp is a good fit
for the Foundation than the entire HTTP Server PMC?
> I think that there's little downside to this. A check on the
> Incubator PMC is the board - any member or PMC could appeal to the
> board in the event that they believed their proposals were not being
> treated fairly, or if the Incubator PMC was behaving in general in a
> way they disagreed with.
>
> And the board has to answer to the membership.
I believe that there is *major* downside to having the Incubator PMC
second-guess the decisions of other PMCs.
If someone doesn't like the decision of a PMC, they shouldn't be able to
use the Inucbator PMC as cover for their attacks. People who don't like
what's going on in that PMC should confront that PMC directly. If they
don't like what's going on in that PMC and have tried to redress their
grievances directly, they can go to the Board.
Although, the Board is rightly wary of interposing itself in technical
decisions. We have no idea what makes technical sense or not either.
> >Cynics like me are the *worst* possible judges of what's cool and
> >what's
> >not. That's the fundamental problem I have with this entire
> >thread: people
> >are trying to limit the growth or exclude projects. How? On what
> >basis?
>
> I agree here - I would never want to exclude based on technology. I
> do the thought experiment from time to time and ask myself which
> projects I would have excluded if ordered to limit growth at the ASF,
> and I never have a good answer. Maybe not let those "toaster language
> bytecode people" in? I think our current java communities are a
> *huge* asset. How about the pointy-bracket folks?
>
> We need to actually increase our technical diversity here - we have
> no real Ruby-oriented communities, nor any coherent .NET identity,
> and I think that's going to hurt us in the long run.
That's why this talk about limiting growth is so dangerous. The foundation
should go where our PMCs and our members want. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 23, 2005, at 4:07 AM, Justin Erenkrantz wrote:
>
> If any ASF PMC believes it is in the best interest of the
> Foundation to
> accept a podling and they are willing to dedicate resources
> ("people") -
> then anyone on the Incubator PMC has no standing to challenge that
> decision. When a PMC approves a podling, the only thing the
> Incubator PMC
> can decide is whether the project can "leave" the Incubator.
>
> Even without a PMC, if *one* of our members out there thinks a
> project is
> worth doing and they can write something mildly resembling a
> charter down
> on paper, that's all I need to hear for a +1. The project *they*
> believe
> in deserves the institutional support of the Foundation. We can
> not be
> second-guessing people's motives as to why they believe it's a good
> idea.
I am no longer convinced of this. Having the Incubator PMC there as
a "check and balance" is a good thing as it requires engagement from
others interested in this aspect of ASF life. It prevents one
individual or one PMC from being able to make significant social or
technological change, or at least ensure that there is a
theoretically impartial observer keeping track. It allows interested
members and other community members to "put their money where their
mouth is" on this topic, and join the Incubator PMC to help out.
I think that there's little downside to this. A check on the
Incubator PMC is the board - any member or PMC could appeal to the
board in the event that they believed their proposals were not being
treated fairly, or if the Incubator PMC was behaving in general in a
way they disagreed with.
And the board has to answer to the membership.
>
> Cynics like me are the *worst* possible judges of what's cool and
> what's
> not. That's the fundamental problem I have with this entire
> thread: people
> are trying to limit the growth or exclude projects. How? On what
> basis?
I agree here - I would never want to exclude based on technology. I
do the thought experiment from time to time and ask myself which
projects I would have excluded if ordered to limit growth at the ASF,
and I never have a good answer. Maybe not let those "toaster language
bytecode people" in? I think our current java communities are a
*huge* asset. How about the pointy-bracket folks?
We need to actually increase our technical diversity here - we have
no real Ruby-oriented communities, nor any coherent .NET identity,
and I think that's going to hurt us in the long run.
>
> To do so is to bang our collective heads on the wall: closing our
> borders
> is to forget where we came from and why we're here at all. -- justin
>
+1
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> If any ASF PMC believes it is in the best interest of the Foundation to
> accept a podling and they are willing to dedicate resources ("people") -
> then anyone on the Incubator PMC has no standing to challenge that
> decision. When a PMC approves a podling, the only thing the Incubator
> PMC can decide is whether the project can "leave" the Incubator.
A fair summation, although there are people who believe that the Incubator
PMC should have more of a say in the entry of a project for Incubation.
Jim and Geir both raise the hypothetical of what would have happened if
Tuscany were submitted as a fait accompli by the WS PMC, rather than being
critiqued here. Following up on some comments and other examples from Dims,
I'd say that this raises a separate issue, which is something to address
Foundation-wide: how to push for more synergy and cooperation where
appropriate between our projects, without excluding cooperation with
external ones. To date, that has only been something promoted by
individuals, such as myself, who want to see ASF projects collaborating.
> Even without a PMC, if *one* of our members out there thinks a project is
> worth doing and they can write something mildly resembling a charter down
> on paper, that's all I need to hear for a +1.
That has been my policy, too, although if we adopt the notion that there
must be 3 Members/Officers as project mentors, it would take more than one
such mentor for a project to start.
I don't know whether or not that would satisfy Geir, unless we did something
about not having all of those mentors from the same PMC. There seem to be
concerns that some other PMC could become out of control, and game the rules
in the absence of some balance. Personally, I would hope for better from an
ASF Member, and will consider whether future candidates would make good
Incubator Mentors.
> That's the fundamental problem I have with this entire thread: people
> are trying to limit the growth or exclude projects. How? On what basis?
Agreed. We must plan for scale, and ensure that AS WE SCALE, that the
proper processes are in place.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Dec 23, 2005 at 01:43:11PM +0600, Sanjiva Weerawarana wrote:
> With a lot of due respect Roy, I think the argument that unless one
> helps with infra one does not have a right to belly-ache is absurd. Not
> everyone is infra-savvy and/or infra-interested. I refuse to accept that
> not contributing to infra reduces Ted's or my contributions to the
> foundation or the incubator.
I believe that misses Roy's point: it's not about infra - it's about
dictating an individual's effort towards or against a particular project.
The ASF has never been about telling someone else what to do. The comments
that are being made in this thread are along the lines of "I know better
than you and you shouldn't work on this project because I think it's bad or
XYZ is better." That is not who we are or are about: you can not make that
value decision for anyone else.
If any ASF PMC believes it is in the best interest of the Foundation to
accept a podling and they are willing to dedicate resources ("people") -
then anyone on the Incubator PMC has no standing to challenge that
decision. When a PMC approves a podling, the only thing the Incubator PMC
can decide is whether the project can "leave" the Incubator.
Even without a PMC, if *one* of our members out there thinks a project is
worth doing and they can write something mildly resembling a charter down
on paper, that's all I need to hear for a +1. The project *they* believe
in deserves the institutional support of the Foundation. We can not be
second-guessing people's motives as to why they believe it's a good idea.
Cynics like me are the *worst* possible judges of what's cool and what's
not. That's the fundamental problem I have with this entire thread: people
are trying to limit the growth or exclude projects. How? On what basis?
To do so is to bang our collective heads on the wall: closing our borders
is to forget where we came from and why we're here at all. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2005-12-22 at 21:19 -0800, Ted Leung wrote:
> >
> > Right now, however, all I hear is belly-aching by people who have not
> > been doing any of the Incubator's work, nor that of infrastructure,
> > so have little basis to complain about anything.
>
> I was the mentor and co-sponsor for XMLBeans, which graduated from
> the incubator, after being there for about a year. As member of
> the incubator PMC, I feel that it is part of my responsibility to ask
> whether what we have is working for the foundation or not.
+1.
I too am on the incubator PMC and am mentoring 2 projects: Woden and
Synapse.
With a lot of due respect Roy, I think the argument that unless one
helps with infra one does not have a right to belly-ache is absurd. Not
everyone is infra-savvy and/or infra-interested. I refuse to accept that
not contributing to infra reduces Ted's or my contributions to the
foundation or the incubator.
I care a lot about the future of ASF and I have lots of concerns about
the incubation process and what it means to the ASF. I will pick up that
discussion on the members list.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Corporations and the incubator
Posted by Martin Sebor <se...@roguewave.com>.
Sanjiva Weerawarana wrote:
> On Sat, 2005-12-24 at 13:00 -0700, Martin Sebor wrote:
>
>>>Don't do a press release. An incubating project is not officially part
>>>of the ASF, and a press release will imply that the project is part of
>>>the ASF. This one really makes ASF members angry, so don't go here.
>>
>>-1
>>
>>Press releases are a means for companies to announce noteworthy
>>events to the public.
>
> ...
>
>>>Don't "just" print some t-shirts with the ASF logo or the incubating
>>>project's logo. See "Don't do a press release" for reasons.
>>
>>-1
>>
>>I see nothing wrong with printing T-shirts or other promotional
>>items as long as their design is approved by the ASF.
>
>
> I disagree on both counts - while going thru incubation it is important
> to recognize that a project is *not* part of the ASF until it completes
> incubation. If we allow people to do press releases, print t-shirts and
> coffee mugs etc., then the rest of the world has no way to distinguish
> between a real ASF project and an incubating one.
I would be surprised if anyone made a decision of any consequence
based on what they saw on a T-shirt or a coffee mug :) I certainly
don't see that happening if the mug or T-shirt simply urges people
to check the project out and get involved in its development, and
when it carries the required disclaimer.
>
> We don't allow code releases from the incubator except with carefully
> minted words.
The requirements I know of are the word "incubating" in the name
of the tarball and the disclaimer at the top of the project's README.
With that and with the approval of the Incubator PMC, podlings are
permitted to do releases. So if that's good enough for the actual
code why not for the mug or T-shirt, especially when the approval
comes from the Board itself?
> Given we can't do that with t-shirts,
Pardon my ignorance but how is that a given? I ask because I've read
two contradictory opinions. When asked informally, at least three
ASF members (one of them a Board member, and one of them our mentor)
responded favorably to our request to print T-shirts promoting the
STDCXX podling.
> its best to just say
> no. Press releases could have the disclaimer text- but the reality is
> that when the story gets carried by various folks they drop that stuff-
> the story simply isn't powerful enough with a disclaimer. So we end up
> losing.
My concern is that by restricting how we can talk about new efforts
in the incubator and to whom, the ASF makes it exceedingly difficult
for podlings to build up communities around them. Since the ASF has
accepted the donated projects I would expect it to want to do its
best to help them succeed. Instead, my impression from discussions
such as this one is that there is an atmosphere of distrust of new
projects, especially those donated by third parties.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Corporations and the incubator
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 12/25/2005 6:03 PM, Sanjiva Weerawarana wrote:
>On Sat, 2005-12-24 at 13:00 -0700, Martin Sebor wrote:
>
>
>>>Don't do a press release. An incubating project is not officially part
>>>of the ASF, and a press release will imply that the project is part of
>>>the ASF. This one really makes ASF members angry, so don't go here.
>>>
>>>
>>-1
>>
>>Press releases are a means for companies to announce noteworthy
>>events to the public.
>>
>>
>...
>
>
>>>Don't "just" print some t-shirts with the ASF logo or the incubating
>>>project's logo. See "Don't do a press release" for reasons.
>>>
>>>
>>-1
>>
>>I see nothing wrong with printing T-shirts or other promotional
>>items as long as their design is approved by the ASF.
>>
>>
>
>I disagree on both counts - while going thru incubation it is important
>to recognize that a project is *not* part of the ASF until it completes
>incubation. If we allow people to do press releases, print t-shirts and
>coffee mugs etc., then the rest of the world has no way to distinguish
>between a real ASF project and an incubating one.
>
>We don't allow code releases from the incubator except with carefully
>minted words. Given we can't do that with t-shirts, its best to just say
>no. Press releases could have the disclaimer text- but the reality is
>that when the story gets carried by various folks they drop that stuff-
>the story simply isn't powerful enough with a disclaimer. So we end up
>losing.
>
>So I agree with Dain's proposals!
>
>
These reflect my sentiments as well.
Regards,
Alan
Re: Corporations and the incubator
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, 2005-12-24 at 13:00 -0700, Martin Sebor wrote:
> > Don't do a press release. An incubating project is not officially part
> > of the ASF, and a press release will imply that the project is part of
> > the ASF. This one really makes ASF members angry, so don't go here.
>
> -1
>
> Press releases are a means for companies to announce noteworthy
> events to the public.
...
> > Don't "just" print some t-shirts with the ASF logo or the incubating
> > project's logo. See "Don't do a press release" for reasons.
>
> -1
>
> I see nothing wrong with printing T-shirts or other promotional
> items as long as their design is approved by the ASF.
I disagree on both counts - while going thru incubation it is important
to recognize that a project is *not* part of the ASF until it completes
incubation. If we allow people to do press releases, print t-shirts and
coffee mugs etc., then the rest of the world has no way to distinguish
between a real ASF project and an incubating one.
We don't allow code releases from the incubator except with carefully
minted words. Given we can't do that with t-shirts, its best to just say
no. Press releases could have the disclaimer text- but the reality is
that when the story gets carried by various folks they drop that stuff-
the story simply isn't powerful enough with a disclaimer. So we end up
losing.
So I agree with Dain's proposals!
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Corporations and the incubator
Posted by Martin Sebor <se...@roguewave.com>.
Steven Noels wrote:
[...]
> IMHO, actually very _few_ companies issue PR around their ASF
> involvement, considering the fact that the ASF biosphere is one of a
> myriad of tiny (one-person), small (a few people), and then larger
> companies employing individuals which contribute to ASF projects, quite
> a few of them during company hours.
Doesn't that imply that there is no problem with press releases, then,
and thus no reason to prohibit donor companies from putting them out?
[...]
>
> Are the companies not issuing PR lazy asses, or plain dumb? Not willing
> to inform the public?
I would be more inclined to think that they simply do not consider
it worthwhile. Donating a 100 KLOC project and the time of a handful
of developers may not be a big deal to a billion dollar company, but
it most likely is for a company that's fraction of the size. Especially
one that doesn't seek to derive significant immediate revenue from doing
so.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Corporations and the incubator
Posted by Steven Noels <st...@outerthought.org>.
On 24 Dec 2005, at 21:00, Martin Sebor wrote:
> Press releases are a means for companies to announce noteworthy
> events to the public. Certainly, donating a substantial code base
> and committing to maintaining and typically also supporting that
> code base free of charge while at the same time taking on the task
> of building a diverse community around the donated project and
> shepherding it through the incubation process is a noteworthy
> event and can be a significant financial undertaking on the part
> of the donating organization that the public has the right to know
> about.
Snif. "the right to know about"
IMHO, actually very _few_ companies issue PR around their ASF
involvement, considering the fact that the ASF biosphere is one of a
myriad of tiny (one-person), small (a few people), and then larger
companies employing individuals which contribute to ASF projects, quite
a few of them during company hours.
Just for starters, crosscheck the affiliations listed on
http://www.apache.org/foundation/members.html against a PR News search
tool. And that's only ASF members.
Are the companies not issuing PR lazy asses, or plain dumb? Not willing
to inform the public?
> And they do -- their software :)
Sorry to say, but: big deal. Compare that with the value of the ASF
brand for the donating entity. Lines of code are a side-effect of
developer team-work, and it's much more difficult to grow a team and a
brand than to actually code.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought Open Source Java & XML
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Corporations and the incubator
Posted by Martin Sebor <se...@roguewave.com>.
Dain Sundstrom wrote:
[...]
> I suggest we add a "For corporations" section to the "Incubator
> Guidelines Documentation" which would contain things, like:
+1 so far. I agree that better, more detailed guidelines would help
organizations or communities not familiar with the process prevent
confusion and avoid misunderstanding.
>
> Don't do a press release. An incubating project is not officially part
> of the ASF, and a press release will imply that the project is part of
> the ASF. This one really makes ASF members angry, so don't go here.
-1
Press releases are a means for companies to announce noteworthy
events to the public. Certainly, donating a substantial code base
and committing to maintaining and typically also supporting that
code base free of charge while at the same time taking on the task
of building a diverse community around the donated project and
shepherding it through the incubation process is a noteworthy
event and can be a significant financial undertaking on the part
of the donating organization that the public has the right to know
about.
If there is a perceived problem with these types of announcements
wouldn't a better approach be for the Apache PRC to anticipate and
proactively try to prevent them, perhaps by offering to help with
the press release? A set of guidelines describing what is and isn't
appropriate for such a press release would be helpful as well.
>
> Don't "just" print some t-shirts with the ASF logo or the incubating
> project's logo. See "Don't do a press release" for reasons.
-1
I see nothing wrong with printing T-shirts or other promotional
items as long as their design is approved by the ASF. Companies
need to be able to make use of their resources to promote the
donated projects in an honest effort to build a community around
them. It doesn't just help the project, it's also free advertising
for the ASF. Since the ASF gets to approve or reject a request
for the use of its trademarks I don't see any risk here.
>
> Do move copyright notices from all source files to the NOTICE file.
+1
I'm not sure exactly what this means but I am certainly in favor
of documenting the process of copyright transfer even better than
it is now.
>
> Do donate to the ASF :)
And they do -- their software :)
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Corporations and the incubator
Posted by Leo Simons <ma...@leosimons.com>.
On Sat, Dec 24, 2005 at 11:05:05AM -0800, Dain Sundstrom wrote:
> On Dec 22, 2005, at 9:19 PM, Ted Leung wrote:
>
> >To us an Apache project is an effort of the ASF. To the majority
> >of people out there, being an Apache project (rightly or wrongly)
> >is branding stamp. You might not like it, but that's how many
> >people treat it. And that's why one of the first things a company
> >wants do when it proposes incubation is issue a press release.
>
> I keep seeing this sentiment repeated on this list and I think we
> should address this concern directly.
+1.
> I've dealt with a few companies involved with projects being
> incubated, and everyone of them was very concerned about doing the
> right thing. The last thing they want to do is anger the ASF right
> when they are getting involved. The problem I have found is that
> they are just not familiar with the incubator, and make bad
> assumption.
Yep, that often seems to be the case.
> I bet that if we let the corporations know the "Dos and
> Don'ts" of working with the incubator, they will be followed (at
> least more often then they are now :)
I bet this bet is the very mistake we've made in the past.
> I suggest we add a "For corporations" section to the "Incubator
> Guidelines Documentation"
that could make sense.
> which would contain things, like:
>
> Don't do a press release. An incubating project is not officially
> part of the ASF, and a press release will imply that the project is
> part of the ASF. This one really makes ASF members angry, so don't
> go here.
>
> Don't "just" print some t-shirts with the ASF logo or the incubating
> project's logo. See "Don't do a press release" for reasons.
>
> Do move copyright notices from all source files to the NOTICE file.
>
> Do donate to the ASF :)
>
> I'm sure there are many more.
>
> What do you think?
I've been mulling on this for some time. I don't know how to phrase this
just yet. But since you asked, I will try anyway.
I think it is a pipe dream that having things like lots of checklists,
lots of process documentation, ISO 2000-compliant processes (FWIW,
ISO 2000 and the ASF don't mesh well, we are based on self-driven
volunteers not on management or top down process monitoring), or anything
like that is ever going to address this kind of concern.
The ASF is not like a corporation and its processes are not like those of
a corporation. Corporations that want to be part of the open source community
need to change a whole lot.
This documentation should be a little more like:
"""The below advice is for technical managers, project managers, PR staff,
quality assurance staff, marketing staff, and people in other kinds of
corperate roles who will be involved with the open sourcing of a corporate
project through the ASF.
To understand the incubation process you should take a look at a few
years of open source development and incubation history at the ASF. Read
all of the documentation on http://www.apache.org/, in particular the
'How things work' documentation. Read all of the documentation on
http://incubator.apache.org/. Understand that this documentation is and
always will be behind on actual practice. Read all of the email from the
general@jakarta.apache.org mailing list archives that has to do with
the incubation of the Tapestry project. Read most of the email from the
general@incubator.apache.org archives. Pay attention to some of the
"process threads". Make a case study of one or two projects that
graduated successfully (I recommend looking at SpamAssassin, a mature
open source project that proceeded through the incubation process very
successfully), read their dev-list archives as well (both before they came
to the ASF, during incubation, and afterwards).
If you are new to open source community development in the apache way
(hint: its likely that you are), be prepared to spend a full work week
reading about this stuff, thinking about it, etc. You will have questions
to which you can't find the answer. Send e-mail to
general@incubator.apache.org with your question. You will likely receive
several answers, often not completely compatible. Get used to this.
If you are somewhat new to open source in general, also read at least
* "the cathedral and the bazaar" by Eric S. Raymond
* "Open Source Licensing" by Lawrence Rosen
* "the cluetrain manifesto" by a variety of authors
* "Subversion Version Control : Using the Subversion Version Control
System in Development Projects" by William Nagel
I'll also recommend watching the movie "FUD". Watch it together with all of
your collegues and discuss it afterwards.
these sources will contain a variety of details which may be a lot more
technical than you're used to and/or far more materials which are not so
close to your day job at your corporation. Get used to this too. To
continue to be productive at your job with respect to this to-be-open-source
project, you will need to understand "how open source works", which involves
understanding the moral principles underlying it, its chaotic process and
work environment. You will most likely need to get used to using some
"programmer tools", including SVN and Jira.
Be prepared to embark on a personal path down the open source road that will
take you several months to start. Most likely, you'll try to be walking it for
the rest of your life if you make it that far.
If you're in charge of your corporate open source efforts, you'll understand
and recognize that all of the above is going to take your staff many many hours
over the course a several months, and has the possibility of resulting in some
radical changes to your corporate processes. Yup.
"""
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Corporations and the incubator
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 22, 2005, at 9:19 PM, Ted Leung wrote:
> To us an Apache project is an effort of the ASF. To the majority
> of people out there, being an Apache project (rightly or wrongly)
> is branding stamp. You might not like it, but that's how many
> people treat it. And that's why one of the first things a company
> wants do when it proposes incubation is issue a press release.
I keep seeing this sentiment repeated on this list and I think we
should address this concern directly.
I've dealt with a few companies involved with projects being
incubated, and everyone of them was very concerned about doing the
right thing. The last thing they want to do is anger the ASF right
when they are getting involved. The problem I have found is that
they are just not familiar with the incubator, and make bad
assumption. I bet that if we let the corporations know the "Dos and
Don'ts" of working with the incubator, they will be followed (at
least more often then they are now :)
I suggest we add a "For corporations" section to the "Incubator
Guidelines Documentation" which would contain things, like:
Don't do a press release. An incubating project is not officially
part of the ASF, and a press release will imply that the project is
part of the ASF. This one really makes ASF members angry, so don't
go here.
Don't "just" print some t-shirts with the ASF logo or the incubating
project's logo. See "Don't do a press release" for reasons.
Do move copyright notices from all source files to the NOTICE file.
Do donate to the ASF :)
I'm sure there are many more.
What do you think?
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 23, 2005, at 12:19 AM, Ted Leung wrote:
>
> On Dec 21, 2005, at 12:57 PM, Roy T. Fielding wrote:
>>
>>
>> That's because an Apache project is an EFFORT of the ASF. It is not
>> some diploma that people receive at the end of graduation.
>> Everything
>> done at the ASF is an Apache project. Some are organized better than
>> others, and some are allowed to make their own release decisions, but
>> all of them are collaborative projects using ASF infrastructure and
>> following the literal meaning of Contributor as defined in our
>> license.
>> And, when needed, the board can terminate a project whether it is in
>> the incubator or not.
>
> To us an Apache project is an effort of the ASF. To the majority
> of people out there, being an Apache project (rightly or wrongly)
> is branding stamp. You might not like it, but that's how many
> people treat it. And that's why one of the first things a company
> wants do when it proposes incubation is issue a press release.
There are lots of bad reasons to come to the ASF and high on my list
is "to take advantage of the brand".
Maybe then we address that issue head-on, and simply ask that a
contributing company doesn't do a press release for n months after
entering incubation? And when the project graduates, we do a good
job assisting them with a joint release or something as the reward.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Ted Leung <tw...@sauria.com>.
On Dec 21, 2005, at 12:57 PM, Roy T. Fielding wrote:
> On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
>> How is this possible when any other PMC can vote to bring a
>> project in without approval of the incubator PMC? Just look at
>> the raft of projects being brought in via Geronimo and the WS
>> PMC. There's not a thing I can do, regardless of the merits.
>> The only thing I can say is whether or not their community is good
>> enough to merit graduation.
>
> Right, and that's the only thing you are qualified to do. You don't
> have the right to tell other people what they can or cannot do at
> the ASF. You don't have the right to say that one project is more
> deserving of our resources than some other project. What you do have
> is the right to be involved, to help their incubation (or not), and
> to vote against their graduation if you so desire.
I understand how the rules currently work. I don't agree that they
are working well for us.
>
>>>> I think that the incubation process is setting an incredibly
>>>> low bar for access to the Apache brand name
>
> Methinks you have forgotten that there was no bar before incubator
> existed -- the code was just copied to cvs.
No, I remember, and I wouldn't choose to go back to those days.
>
>>> And we require disclaimers and clear notice that projects ARE in the
>>> Incubator. Look at how the folks are complaining that we are
>>> trying to make
>>> the projects look different by being in the Incubator. They ARE
>>> different.
>>> And they MUST be Incubator branded, and follow Incubation rules.
>>
>> Most people in the world are unaware of the difference between an
>> incubated project and an Apache project. Roy has also stated that
>> once a project is in the incubator it ought to be regarded as an
>> Apache project.
>
> That's because an Apache project is an EFFORT of the ASF. It is not
> some diploma that people receive at the end of graduation. Everything
> done at the ASF is an Apache project. Some are organized better than
> others, and some are allowed to make their own release decisions, but
> all of them are collaborative projects using ASF infrastructure and
> following the literal meaning of Contributor as defined in our
> license.
> And, when needed, the board can terminate a project whether it is in
> the incubator or not.
To us an Apache project is an effort of the ASF. To the majority of
people out there, being an Apache project (rightly or wrongly) is
branding stamp. You might not like it, but that's how many people
treat it. And that's why one of the first things a company wants do
when it proposes incubation is issue a press release.
>
> If people believe that the Incubator should not accept any new
> projects,
> then they should convince the board to make it so. The incubator is
> the place where people wanting to work on new projects can do so
> within a neutral environment with limited risk to the foundation.
> If you think that such things should be done at SourceForge instead,
> and that the ASF should only accept fully-formed communities after
> they have a questionable track-record of IP contributions, then go
> ahead and ask the board to shut down the incubator.
>
> Right now, however, all I hear is belly-aching by people who have not
> been doing any of the Incubator's work, nor that of infrastructure,
> so have little basis to complain about anything.
I was the mentor and co-sponsor for XMLBeans, which graduated from
the incubator, after being there for about a year. As member of
the incubator PMC, I feel that it is part of my responsibility to ask
whether what we have is working for the foundation or not.
Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 21, 2005, at 11:04 AM, Ted Leung wrote:
> How is this possible when any other PMC can vote to bring a project
> in without approval of the incubator PMC? Just look at the raft of
> projects being brought in via Geronimo and the WS PMC. There's
> not a thing I can do, regardless of the merits. The only thing I
> can say is whether or not their community is good enough to merit
> graduation.
Right, and that's the only thing you are qualified to do. You don't
have the right to tell other people what they can or cannot do at
the ASF. You don't have the right to say that one project is more
deserving of our resources than some other project. What you do have
is the right to be involved, to help their incubation (or not), and
to vote against their graduation if you so desire.
>>> I think that the incubation process is setting an incredibly
>>> low bar for access to the Apache brand name
Methinks you have forgotten that there was no bar before incubator
existed -- the code was just copied to cvs.
>> And we require disclaimers and clear notice that projects ARE in the
>> Incubator. Look at how the folks are complaining that we are
>> trying to make
>> the projects look different by being in the Incubator. They ARE
>> different.
>> And they MUST be Incubator branded, and follow Incubation rules.
>
> Most people in the world are unaware of the difference between an
> incubated project and an Apache project. Roy has also stated that
> once a project is in the incubator it ought to be regarded as an
> Apache project.
That's because an Apache project is an EFFORT of the ASF. It is not
some diploma that people receive at the end of graduation. Everything
done at the ASF is an Apache project. Some are organized better than
others, and some are allowed to make their own release decisions, but
all of them are collaborative projects using ASF infrastructure and
following the literal meaning of Contributor as defined in our license.
And, when needed, the board can terminate a project whether it is in
the incubator or not.
If people believe that the Incubator should not accept any new projects,
then they should convince the board to make it so. The incubator is
the place where people wanting to work on new projects can do so
within a neutral environment with limited risk to the foundation.
If you think that such things should be done at SourceForge instead,
and that the ASF should only accept fully-formed communities after
they have a questionable track-record of IP contributions, then go
ahead and ask the board to shut down the incubator.
Right now, however, all I hear is belly-aching by people who have not
been doing any of the Incubator's work, nor that of infrastructure,
so have little basis to complain about anything.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 27 December 2005 03:45, Rich Bowen wrote:
> Niclas Hedhman wrote:
> > On Friday 23 December 2005 16:23, Justin Erenkrantz wrote:
> >> I'm all in favor of enforcing a strict embargo until the Incubator PMC
> >> approves a proposal, an initial code drop lands, and the mailing lists
> >> are created. Until those happen, any active publicity claiming it to be
> >> a part of the ASF is a flat-out lie.
> >
> > So, that means disqualifying for Incubation and no chance of moving the
> > project to ASF??
>
> It means, IMHO, that they don't yet "get it." Since the purpose of the
> Incubator is to ensure that folks do indeed "get it", it would be
> unfortunate to disqualify for entrance anyone who has demonstrated that
> they don't in fact already get it.
>
> So, no, I'd say that this does not disqualify them for entrance. It does
> mean, however, that someone must approach them and instruct them on
> the ways in which their actions demonstrate a lack of getting it.
IMVHO, Justin's "in favour of enforcing a strict embargo" doesn't sound like
"hit their fingers and say 'Bad boy!', followed by a hug". A simple matrix of
act/consequence can be published on Incubator website, but isn't it necessary
to have some significant deterents? Otherwise, "flat-out lie" will be
accompanied with a "flat-out defiance".
> It seems that this process is already underway, via Ted.
I thought we were speaking "in general" and "pro-actively", since retro-active
measures are not really serving ASF either.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Rich Bowen <rb...@rcbowen.com>.
Niclas Hedhman wrote:
> On Friday 23 December 2005 16:23, Justin Erenkrantz wrote:
>> I'm all in favor of enforcing a strict embargo until the Incubator PMC
>> approves a proposal, an initial code drop lands, and the mailing lists are
>> created. Until those happen, any active publicity claiming it to be a part
>> of the ASF is a flat-out lie.
>
> So, that means disqualifying for Incubation and no chance of moving the
> project to ASF??
It means, IMHO, that they don't yet "get it." Since the purpose of the
Incubator is to ensure that folks do indeed "get it", it would be
unfortunate to disqualify for entrance anyone who has demonstrated that
they don't in fact already get it.
So, no, I'd say that this does not disqualify them for entrance. It does
mean, however, that someone must approach them and instruct them on
the ways in which their actions demonstrate a lack of getting it. It
seems that this process is already underway, via Ted.
--
Rich Bowen
rbowen@rcbowen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 23 December 2005 16:23, Justin Erenkrantz wrote:
> I'm all in favor of enforcing a strict embargo until the Incubator PMC
> approves a proposal, an initial code drop lands, and the mailing lists are
> created. Until those happen, any active publicity claiming it to be a part
> of the ASF is a flat-out lie.
So, that means disqualifying for Incubation and no chance of moving the
project to ASF??
Just curious.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 12/21/2005 11:21 PM, Cliff Schmidt wrote:
>On 12/21/05, Ian Holsman <li...@holsman.net> wrote:
>
>
>>Ted Leung wrote:
>>
>>
>>>On Dec 21, 2005, at 8:22 AM, Noel J. Bergman wrote:
>>>
>>>
>>>
>>>>>I think that the incubation process is setting an incredibly
>>>>>low bar for access to the Apache brand name
>>>>>
>>>>>
>>>>And we require disclaimers and clear notice that projects ARE in the
>>>>Incubator. Look at how the folks are complaining that we are trying
>>>>to make
>>>>the projects look different by being in the Incubator. They ARE
>>>>different.
>>>>And they MUST be Incubator branded, and follow Incubation rules.
>>>>
>>>>
>>>Most people in the world are unaware of the difference between an
>>>incubated project and an Apache project. Roy has also stated that once
>>>a project is in the incubator it ought to be regarded as an Apache project.
>>>
>>>
>>that can be easily resolved.
>>you start up another domain say 'theincubator.org' or something 'proving
>>grounds' related and make sure it has no apache branding, and that no
>>project or PR firm can mention apache there.
>>
>>
>
>Although I'm not sure we should take that step right now, I don't
>think that's such a crazy suggestion. I do believe we should rethink
>the branding of incubating project:
>
>Today, we complain that corporations working on incubating projects
>are taking advantage of the Apache brand. We wonder why the press and
>public aren't aware of the distinction of incubating projects, and yet
>we *require* these projects always preface their name with the same
>master brand we use on fully endorse projects, "Apache".
>
>We can't keep a low bar for incoming incubating projects and allow for
>this confusion. We may indeed need a multibrand strategy when it
>comes to incubating projects.
>
>
I think that this thread has much merit and should be pursued further.
Regards,
Alan
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Cliff Schmidt wrote:
> We can't keep a low bar for incoming incubating projects and allow for
> this confusion. We may indeed need a multibrand strategy when it
> comes to incubating projects.
Branding is orthogonal to the entry barrier.
I realize that some people are concerned about corporate involvement for PR.
Corporate involvement is not a bad thing. Loss of diversity and control is
a concern. Improper use of the brand is a concern. But corporate
involvement is not an a priori concern. Actually, one of the things
concerning me more is a stealth involvement where there is a corporate
involvement with many *undisclosed* tentacles.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> I'm all in favor of enforcing a strict embargo until the Incubator PMC
? approves a proposal, an initial code drop lands, and the mailing lists are
> created. Until those happen, any active publicity claiming it to be a
part
> of the ASF is a flat-out lie. (In the future, the PRC is almost certainly
> going to reject any releases before this happens.)
Then we have a different policy to put into place: NO PR WITHOUT THE
APPROVAL OF THE PRC. And that should be applied to ALL ASF PROJECTS, not
just those in the Incubator. That puts more work on the PRC, which will
need to grow to scale, but I'd go for such an ASF-wide policy. We would
have to document that broadly, and make it clear to donors. That probably
won't help with the "We're planning to donate" type announcements, but ...
> after those steps occur (which should be relatively quickly in the
> order of a few weeks), removing the Apache brand from podlings would
> be incredibly harmful.
+1
> The only reason that these projects can have the 'Apache' brand is because
> a member of the Foundation is willing to act as mentor *and* the Incubator
> PMC approves each interim release. If the mentor isn't keeping the
project
> in line with respect to our values, then the Incubator or the
'destination'
> PMC needs to step in and provide guidance or terminate it.
Hopefully, a 3 active mentor policy will help with this issue.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Dec 21, 2005 at 11:21:47PM -0800, Cliff Schmidt wrote:
> Although I'm not sure we should take that step right now, I don't
> think that's such a crazy suggestion. I do believe we should rethink
> the branding of incubating project:
>
> Today, we complain that corporations working on incubating projects
> are taking advantage of the Apache brand. We wonder why the press and
> public aren't aware of the distinction of incubating projects, and yet
> we *require* these projects always preface their name with the same
> master brand we use on fully endorse projects, "Apache".
>
> We can't keep a low bar for incoming incubating projects and allow for
> this confusion. We may indeed need a multibrand strategy when it
> comes to incubating projects.
This comes out of the two part 'mission' of the Incubator:
- Deal with legal issues around a codebase to certify 'cleanliness'
- Build a community that can stand on its own in 'The Apache Way'
I'm all in favor of enforcing a strict embargo until the Incubator PMC
approves a proposal, an initial code drop lands, and the mailing lists are
created. Until those happen, any active publicity claiming it to be a part
of the ASF is a flat-out lie. (In the future, the PRC is almost certainly
going to reject any releases before this happens.)
However, after those steps occur (which should be relatively quickly in the
order of a few weeks), removing the Apache brand from podlings would be
incredibly harmful. We *want* these projects to grow and to become
full-fledged ASF projects capable of making decisions on their own. How
would they be created without the "Apache" name there in the first place?
There aren't going to be full-fledged projects and communities that just
walk in the door and become versed in our way with the quick blessing or a
nod. If that were the case, they don't have any need for the ASF. They
can stay where they are.
The only reason that these projects can have the 'Apache' brand is because
a member of the Foundation is willing to act as mentor *and* the Incubator
PMC approves each interim release. If the mentor isn't keeping the project
in line with respect to our values, then the Incubator or the 'destination'
PMC needs to step in and provide guidance or terminate it. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Cliff Schmidt <cl...@gmail.com>.
On 12/21/05, Ian Holsman <li...@holsman.net> wrote:
> Ted Leung wrote:
> >
> > On Dec 21, 2005, at 8:22 AM, Noel J. Bergman wrote:
> >
>
> >>
> >>> I think that the incubation process is setting an incredibly
> >>> low bar for access to the Apache brand name
> >>
> >> And we require disclaimers and clear notice that projects ARE in the
> >> Incubator. Look at how the folks are complaining that we are trying
> >> to make
> >> the projects look different by being in the Incubator. They ARE
> >> different.
> >> And they MUST be Incubator branded, and follow Incubation rules.
>
> >
> > Most people in the world are unaware of the difference between an
> > incubated project and an Apache project. Roy has also stated that once
> > a project is in the incubator it ought to be regarded as an Apache project.
>
> that can be easily resolved.
> you start up another domain say 'theincubator.org' or something 'proving
> grounds' related and make sure it has no apache branding, and that no
> project or PR firm can mention apache there.
Although I'm not sure we should take that step right now, I don't
think that's such a crazy suggestion. I do believe we should rethink
the branding of incubating project:
Today, we complain that corporations working on incubating projects
are taking advantage of the Apache brand. We wonder why the press and
public aren't aware of the distinction of incubating projects, and yet
we *require* these projects always preface their name with the same
master brand we use on fully endorse projects, "Apache".
We can't keep a low bar for incoming incubating projects and allow for
this confusion. We may indeed need a multibrand strategy when it
comes to incubating projects.
Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Ian Holsman <li...@holsman.net>.
Ted Leung wrote:
>
> On Dec 21, 2005, at 8:22 AM, Noel J. Bergman wrote:
>
>>
>>> I think that the incubation process is setting an incredibly
>>> low bar for access to the Apache brand name
>>
>> And we require disclaimers and clear notice that projects ARE in the
>> Incubator. Look at how the folks are complaining that we are trying
>> to make
>> the projects look different by being in the Incubator. They ARE
>> different.
>> And they MUST be Incubator branded, and follow Incubation rules.
>
> Most people in the world are unaware of the difference between an
> incubated project and an Apache project. Roy has also stated that once
> a project is in the incubator it ought to be regarded as an Apache project.
that can be easily resolved.
you start up another domain say 'theincubator.org' or something 'proving
grounds' related and make sure it has no apache branding, and that no
project or PR firm can mention apache there.
projects of sufficient stature/passed the test of manhood get initiated
into the apache.org.
ie... it only starts becoming a apache project once it has finished the
incubation... I know technically this sounds identical to what is going
on, and to be honest it is. but for non-tech folks the non-association
is a big thing, and it will be harder for PR folk to say look.. it's an
apache think and make t-shirts for it etc etc
>
> Ted
>
>
> ---------------------------------------------------------------------
> 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
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Ted Leung wrote:
> Noel J. Bergman wrote:
> > > The merits of the particular proposal aside
> > We should always be judging the merits of each proposal.
> > Failing to do so might well be part of the problem.
> How is this possible when any other PMC can vote to bring a project
> in without approval of the incubator PMC? Just look at the raft of
> projects being brought in via Geronimo and the WS PMC. There's not
> a thing I can do, regardless of the merits. The only thing I can say
> is whether or not their community is good enough to merit graduation.
When I say "We", above, I meant the ASF. All of the PMCs have a
responsibility to the Foundation. But are you going to say that the
Incubator PMC should be judging the performance of the other PMCs in living
up to their obligations?
> > And we require disclaimers and clear notice that projects ARE in
> > the Incubator. Look at how the folks are complaining that we
> > are trying to make the projects look different by being in the
> > Incubator. They ARE different. And they MUST be Incubator
> > branded, and follow Incubation rules.
> Most people in the world are unaware of the difference between an
> incubated project and an Apache project.
And we have to correct that lack of awareness.
> Roy has also stated that once a project is in the incubator it
> ought to be regarded as an Apache project.
I wouldn't take Roy's comment out of context. I don't believe that he means
it the way that you imply above.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Ted Leung <tw...@sauria.com>.
On Dec 21, 2005, at 8:22 AM, Noel J. Bergman wrote:
>> The merits of the particular proposal aside
>
> We should always be judging the merits of each proposal. Failing
> to do so
> might well be part of the problem.
How is this possible when any other PMC can vote to bring a project
in without approval of the incubator PMC? Just look at the raft of
projects being brought in via Geronimo and the WS PMC. There's not
a thing I can do, regardless of the merits. The only thing I can say
is whether or not their community is good enough to merit graduation.
>
>> I think that the incubation process is setting an incredibly
>> low bar for access to the Apache brand name
>
> And we require disclaimers and clear notice that projects ARE in the
> Incubator. Look at how the folks are complaining that we are
> trying to make
> the projects look different by being in the Incubator. They ARE
> different.
> And they MUST be Incubator branded, and follow Incubation rules.
Most people in the world are unaware of the difference between an
incubated project and an Apache project. Roy has also stated that
once a project is in the incubator it ought to be regarded as an
Apache project.
Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Davanum Srinivas <da...@gmail.com>.
Let's put htis to the board today
-- dims
On 12/21/05, Noel J. Bergman <no...@devtech.com> wrote:
> Jim Jagielski wrote:
>
> > There is one thing that I think would be useful in
> > helping: That the Incubator PMC take an active role
> > in accepting new projects. Normally, if the Sponsor
> > says "Yes" a vote isn't even taken on the Incubator
> > side. I think that no matter what, unless overruled
> > by the board, the Incubator should vote.
>
> It was presented to the Incubator PMC that when another PMC has voted, we
> don't have that option. I'd like to see a determination from the Board if
> that is to change.
>
> I will still say that if another PMC has voted, that unless they also
> provide a Member or Officer to provide oversight (not necessarily from that
> PMC), that the request is invalid.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Mads Toftum <ma...@toftum.dk>.
On Wed, Dec 21, 2005 at 11:38:52AM -0500, Jim Jagielski wrote:
> There is one thing that I think would be useful in
> helping: That the Incubator PMC take an active role
> in accepting new projects. Normally, if the Sponsor
> says "Yes" a vote isn't even taken on the Incubator
> side. I think that no matter what, unless overruled
> by the board, the Incubator should vote.
>
Absolutely! I'm surprised that this isn't the case already.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by robert burrell donkin <ro...@gmail.com>.
(for the benefit of those joining the thread, here's the context)
> > On 12/22/05, robert burrell donkin <ro...@gmail.com> wrote:
> > the way people vote are a matter of record and so reputations are at stake
> > both inside and outside apache. voting for a duff release or contributing to
> > a failure of oversight has personal consequences.
> >
> > i wonder whether one cause of some of the worries is that there is very
> > little at stake for the pmc and so very little reason for anyone to ever
> > vote -1. any negatives will be somebody else's problem (whether the
> > incubator's or apache's) to sort out. perhaps this misalignment of power and
> > effect may prove not to be too healthy in the long run.
On 12/22/05, Martin Marinschek <ma...@gmail.com> wrote:
> Do you mean the incubator PMC or the project PMCs?
ATM the sponsoring pmc votes and then the incubator pmc and the
mentors do the work :)
> I do think that there is much at stake also for the project PMCs....
> If the projects they bring in don't work out, this will also be a
> problem for the project community.
how much that is true probably depends on the particular pmc in
question. problems with TLPs are ASF problems.
if it were generally true that every pmc cared so much about every
podling, then i suspect that fewer people would be worried. ATM though
(unlike most ASF votes) each +1 is only a recommendation rather than
an active promise to help. it's committing someone else's time and
reputation...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Martin Marinschek <ma...@gmail.com>.
Do you mean the incubator PMC or the project PMCs?
I do think that there is much at stake also for the project PMCs....
If the projects they bring in don't work out, this will also be a
problem for the project community.
regards,
Martin
On 12/22/05, robert burrell donkin <ro...@gmail.com> wrote:
> On 12/22/05, Jim Jagielski <ji...@jagunet.com> wrote:
> >
> >
> > On Dec 21, 2005, at 7:46 PM, Noel J. Bergman wrote:
> >
> > > Jim Jagielski wrote:
> > >
> > >
> > >> I think the Incubator would best serve the ASF if we/they had
> > >> the ultimate authority to vote on, even if the PMC approves a
> > >> proposed project, acceptance.
> > >
> > > You are entitled to that view, but until the Board formally sets
> > > that role,
> > > I don't believe that the Incubator should presume that it has that
> > > right.
> > >
> >
> > Quoting the Resolution that created the Incubator:
> >
> > RESOLVED, that the Apache Incubator PMC be and hereby is
> > responsible for the acceptance and oversight of new products
> > submitted or proposed to become part of the Foundation; and be
> > it further
> >
> > There is nothing within the Resolution which says, for example,
> > that the sponsor PMC gets first and only vote, etc... That
> > is, instead, a policy which we've (the Incubator) set. It's
> > the Incubator which granted that "power" to the PMCs, and
> > we can certainly, IMO, change our set policies to allow us
> > more control over that which we are charged with in the
> > first place :)
>
>
> the way people vote are a matter of record and so reputations are at stake
> both inside and outside apache. voting for a duff release or contributing to
> a failure of oversight has personal consequences.
>
> i wonder whether one cause of some of the worries is that there is very
> little at stake for the pmc and so very little reason for anyone to ever
> vote -1. any negatives will be somebody else's problem (whether the
> incubator's or apache's) to sort out. perhaps this misalignment of power and
> effect may prove not to be too healthy in the long run.
>
> - robert
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/22/05, Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> On Dec 21, 2005, at 7:46 PM, Noel J. Bergman wrote:
>
> > Jim Jagielski wrote:
> >
> >
> >> I think the Incubator would best serve the ASF if we/they had
> >> the ultimate authority to vote on, even if the PMC approves a
> >> proposed project, acceptance.
> >
> > You are entitled to that view, but until the Board formally sets
> > that role,
> > I don't believe that the Incubator should presume that it has that
> > right.
> >
>
> Quoting the Resolution that created the Incubator:
>
> RESOLVED, that the Apache Incubator PMC be and hereby is
> responsible for the acceptance and oversight of new products
> submitted or proposed to become part of the Foundation; and be
> it further
>
> There is nothing within the Resolution which says, for example,
> that the sponsor PMC gets first and only vote, etc... That
> is, instead, a policy which we've (the Incubator) set. It's
> the Incubator which granted that "power" to the PMCs, and
> we can certainly, IMO, change our set policies to allow us
> more control over that which we are charged with in the
> first place :)
the way people vote are a matter of record and so reputations are at stake
both inside and outside apache. voting for a duff release or contributing to
a failure of oversight has personal consequences.
i wonder whether one cause of some of the worries is that there is very
little at stake for the pmc and so very little reason for anyone to ever
vote -1. any negatives will be somebody else's problem (whether the
incubator's or apache's) to sort out. perhaps this misalignment of power and
effect may prove not to be too healthy in the long run.
- robert
Re: Is the incubator out of control?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 22, 2005, at 2:04 PM, Jim Jagielski wrote:
>
> On Dec 22, 2005, at 1:55 PM, Jim Jagielski wrote:
>> Instead, the
>> question is whether it also has the authority (and
>> responsibility) to decide who enters Incubation or not.
>>
>
> FWIW, I have never envisioned a case where the Incubator
> would be at odds with the desires of the PMCs and
> the members. I would see such as thing (denying
> acceptance) as something that would require as
> much reason and rationale as a code-based veto
> would; much more so, in fact.
I can easily see a case where the Incubator is at odds with the
desire of a PMC. That is a good thing, IMO - a good check & balance.
In the event that the Incubator PMC is at odds with the membership or
the general Apache community at large, we have a *huge* problem.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jim Jagielski wrote:
> I have never envisioned a case where the Incubator would
> be at odds with the desires of the PMCs and the members.
As Geir noted, I can see the potential for the former, but of the latter,
I would hope not. The Members are the Incubator in many real ways, and the
Incubator exists to directly serve the interests of the ASF Membership.
> I would see such as thing (denying acceptance) as something that
> would require as much reason and rationale as a code-based veto
> would; much more so, in fact.
Are you suggesting that graduation from the Incubator should be vetoable,
i.e., treated as a vote on code rather than treated as policy?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 22, 2005, at 1:55 PM, Jim Jagielski wrote:
> Instead, the
> question is whether it also has the authority (and
> responsibility) to decide who enters Incubation or not.
>
FWIW, I have never envisioned a case where the Incubator
would be at odds with the desires of the PMCs and
the members. I would see such as thing (denying
acceptance) as something that would require as
much reason and rationale as a code-based veto
would; much more so, in fact.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 22, 2005, at 1:44 PM, Alan D. Cabrera wrote:
>
> I'm confused. Are you stating that the Incubator PMC does not
> currently have the ultimate authority on who leaves the incubator
> and who does not?
>
Not at all. No one (afaik) denies the fact that the Incubator is
the final arbiter of who graduates or not. Instead, the
question is whether it also has the authority (and
responsibility) to decide who enters Incubation or not.
Deciding who graduates ensures that new projects have the
required IP clearance and community health to (hopefully)
grow and prosper, and to ensure the ASF stays on an
even keel. This is good and worthwhile.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alan D. Cabrera wrote:
> Are you stating that the Incubator PMC does not currently
> have the ultimate authority on who leaves the incubator
> and who does not?
No, that is clearly an authority delegated by the Board exclusively to the
Incubator.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 12/22/2005 10:34 AM, Jim Jagielski wrote:
>
> On Dec 22, 2005, at 12:56 PM, Noel J. Bergman wrote:
>
>> I do understand your point, but as I also understand from the
>> comments of
>> both the current ASF Chairman and his predecessor, the Incubator's
>> authority
>> comes into play when we vote to release from the Incubator, rather
>> than when
>> another PMC charges us to accept a candidate into Incubation.
>> Again, the
>> Board can clarify the intent, and I would welcome that clarification.
>>
>
> The Chairman does not have ultimate authority, and their
> PoV or opinion does not count more or less than others, nor
> does it mean that their interpretation is the rule :)
>
> The idea that PMCs should be able to determine what
> projects are to be folded into the ASF is a good one,
> and one that we've always held to, but it's also the
> one that resulted in the problems with Jakarta
> and the lack of oversight involved with them. So it's
> not the fact that other PMCs should decide what
> gets added in which is the issue, is that we have
> the required checks and balances in place to
> avoid another Jakarta.
>
> Going under the assumption that there "should" be some
> sort of entity which "regulates" the influx of new
> projects within the ASF, I submit that the Incubator
> is the best such entity currently in existence (other
> than the board itself). That's all ;)
I'm confused. Are you stating that the Incubator PMC does not currently
have the ultimate authority on who leaves the incubator and who does not?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 22, 2005, at 2:01 PM, Noel J. Bergman wrote:
> Jim Jagielski wrote:
>
>> The Chairman does not have ultimate authority, and their
>> PoV or opinion does not count more or less than others,
>> nor does it mean that their interpretation is the rule :)
>
> Right, but there is clearly a difference of opinion, so which part
> of "the
> Board can clarify the intent, and I would welcome that
> clarification" needs
> further explanation? ;-)
>
None ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jim Jagielski wrote:
> The Chairman does not have ultimate authority, and their
> PoV or opinion does not count more or less than others,
> nor does it mean that their interpretation is the rule :)
Right, but there is clearly a difference of opinion, so which part of "the
Board can clarify the intent, and I would welcome that clarification" needs
further explanation? ;-)
> The idea that PMCs should be able to determine what
> projects are to be folded into the ASF is a good one,
> and one that we've always held to, but it's also the
> one that resulted in the problems with Jakarta
> and the lack of oversight involved with them.
And so on that basis, an interpretation that permits PMCs to submit projects
for Incubation, and still provides for the Incubator PMC to arbitrate on
exit, makes sense.
> it's not the fact that other PMCs should decide what
> gets added in which is the issue, is that we have
> the required checks and balances in place to
> avoid another Jakarta.
Agreed. And that is only one of the concerns that we need to be aware of.
> Going under the assumption that there "should" be some
> sort of entity which "regulates" the influx of new
> projects within the ASF, I submit that the Incubator
> is the best such entity currently in existence (other
> than the board itself). That's all ;)
Agreed, and we are the authority on what leaves the Incubator. And since we
have traditionally held that any ASF Member can join the Incubator PMC, that
provides the ASF Membership with a lot of say in what happens, should they
choose to become active here.
But this still leaves open WHEN that authority comes into play: on entrance
to the Incubator, or on exit.
On the other hand, since exit may include Incubation failure ... hmmm ... I
suppose that the Incubator PMC could vote to fail a project, even if it
can't vote on whether or not to accept it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 22, 2005, at 12:56 PM, Noel J. Bergman wrote:
> I do understand your point, but as I also understand from the
> comments of
> both the current ASF Chairman and his predecessor, the Incubator's
> authority
> comes into play when we vote to release from the Incubator, rather
> than when
> another PMC charges us to accept a candidate into Incubation.
> Again, the
> Board can clarify the intent, and I would welcome that clarification.
>
The Chairman does not have ultimate authority, and their
PoV or opinion does not count more or less than others, nor
does it mean that their interpretation is the rule :)
The idea that PMCs should be able to determine what
projects are to be folded into the ASF is a good one,
and one that we've always held to, but it's also the
one that resulted in the problems with Jakarta
and the lack of oversight involved with them. So it's
not the fact that other PMCs should decide what
gets added in which is the issue, is that we have
the required checks and balances in place to
avoid another Jakarta.
Going under the assumption that there "should" be some
sort of entity which "regulates" the influx of new
projects within the ASF, I submit that the Incubator
is the best such entity currently in existence (other
than the board itself). That's all ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jim Jagielski wrote:
> Noel J. Bergman wrote:
>> Jim Jagielski wrote:
>>> I think the Incubator would best serve the ASF if we/they had
>>> the ultimate authority to vote on, even if the PMC approves a
>>> proposed project, acceptance.
>>
>> You are entitled to that view, but until the Board formally sets
>> that role, I don't believe that the Incubator should presume that
>> it has that right.
>
> Quoting the Resolution that created the Incubator:
> RESOLVED, that the Apache Incubator PMC be and hereby is
> responsible for the acceptance and oversight of new products
> submitted or proposed to become part of the Foundation;
> There is nothing within the Resolution which says, for example,
> that the sponsor PMC gets first and only vote, etc... That
> is, instead, a policy which we've (the Incubator) set. It's
> the Incubator which granted that "power" to the PMCs
I do understand your point, but as I also understand from the comments of
both the current ASF Chairman and his predecessor, the Incubator's authority
comes into play when we vote to release from the Incubator, rather than when
another PMC charges us to accept a candidate into Incubation. Again, the
Board can clarify the intent, and I would welcome that clarification.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 21, 2005, at 7:46 PM, Noel J. Bergman wrote:
> Jim Jagielski wrote:
>
>
>> I think the Incubator would best serve the ASF if we/they had
>> the ultimate authority to vote on, even if the PMC approves a
>> proposed project, acceptance.
>
> You are entitled to that view, but until the Board formally sets
> that role,
> I don't believe that the Incubator should presume that it has that
> right.
>
Quoting the Resolution that created the Incubator:
RESOLVED, that the Apache Incubator PMC be and hereby is
responsible for the acceptance and oversight of new products
submitted or proposed to become part of the Foundation; and be
it further
There is nothing within the Resolution which says, for example,
that the sponsor PMC gets first and only vote, etc... That
is, instead, a policy which we've (the Incubator) set. It's
the Incubator which granted that "power" to the PMCs, and
we can certainly, IMO, change our set policies to allow us
more control over that which we are charged with in the
first place :)
PS: IMO, in response to the actual subject line, I certainly
don't feel that the Incubator is out of control, or
on a certain path for disaster, or anything like that.
I simply think that, knowing the currently growth plan,
some changes may be a Good Idea to *prevent* any
future problems or concerns.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jim Jagielski wrote:
> I see the Incubator as a gatekeeper almost.
See Roy's comments for an alternative view. As I understand his view, the
gatekeeper role is limited to projects leaving the Incubator, not entering.
> PMCs, in general, don't have an idea of the number of
> podlings within the Incubator, the "load" that the
> Incubator (and Infrastructure) is currently handling,
> etc. They have no need to.
Actually, I disagree. I think that the PMCs should be far more aware of the
overall events within the Foundation, and far less cloistered and parochial.
> I think the Incubator would best serve the ASF if we/they had
> the ultimate authority to vote on, even if the PMC approves a
> proposed project, acceptance.
You are entitled to that view, but until the Board formally sets that role,
I don't believe that the Incubator should presume that it has that right.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 21, 2005, at 12:18 PM, Noel J. Bergman wrote:
> Jim Jagielski wrote:
>
>> There is one thing that I think would be useful in
>> helping: That the Incubator PMC take an active role
>> in accepting new projects. Normally, if the Sponsor
>> says "Yes" a vote isn't even taken on the Incubator
>> side. I think that no matter what, unless overruled
>> by the board, the Incubator should vote.
>
> It was presented to the Incubator PMC that when another PMC has
> voted, we
> don't have that option. I'd like to see a determination from the
> Board if
> that is to change.
>
> I will still say that if another PMC has voted, that unless they also
> provide a Member or Officer to provide oversight (not necessarily
> from that
> PMC), that the request is invalid.
>
I see the Incubator as a gatekeeper almost. PMCs,
in general, don't have an idea of the number of
podlings within the Incubator, the "load" that the
Incubator (and Infrastructure) is currently handling,
etc. They have no need to. I think the Incubator
would best serve the ASF if we/they had the
ultimate authority to vote on, even if the PMC
approves a proposed project, acceptance.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Ted Leung <tw...@sauria.com>.
On Dec 21, 2005, at 9:18 AM, Noel J. Bergman wrote:
> Jim Jagielski wrote:
>
>> There is one thing that I think would be useful in
>> helping: That the Incubator PMC take an active role
>> in accepting new projects. Normally, if the Sponsor
>> says "Yes" a vote isn't even taken on the Incubator
>> side. I think that no matter what, unless overruled
>> by the board, the Incubator should vote.
>
> It was presented to the Incubator PMC that when another PMC has
> voted, we
> don't have that option. I'd like to see a determination from the
> Board if
> that is to change.
I'm in favor of such a change.
Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jim Jagielski wrote:
> There is one thing that I think would be useful in
> helping: That the Incubator PMC take an active role
> in accepting new projects. Normally, if the Sponsor
> says "Yes" a vote isn't even taken on the Incubator
> side. I think that no matter what, unless overruled
> by the board, the Incubator should vote.
It was presented to the Incubator PMC that when another PMC has voted, we
don't have that option. I'd like to see a determination from the Board if
that is to change.
I will still say that if another PMC has voted, that unless they also
provide a Member or Officer to provide oversight (not necessarily from that
PMC), that the request is invalid.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Is the incubator out of control?
Posted by Jim Jagielski <ji...@jaguNET.com>.
There is one thing that I think would be useful in
helping: That the Incubator PMC take an active role
in accepting new projects. Normally, if the Sponsor
says "Yes" a vote isn't even taken on the Incubator
side. I think that no matter what, unless overruled
by the board, the Incubator should vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Is the incubator out of control?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The merits of the particular proposal aside
We should always be judging the merits of each proposal. Failing to do so
might well be part of the problem.
> I think that the incubation process is setting an incredibly
> low bar for access to the Apache brand name
And we require disclaimers and clear notice that projects ARE in the
Incubator. Look at how the folks are complaining that we are trying to make
the projects look different by being in the Incubator. They ARE different.
And they MUST be Incubator branded, and follow Incubation rules.
> Unless we are very careful, Incubator will become a much
> larger mess than the Jakarta project
Unlike, Jakarta, the Incubator scales better --- at least in theory ---
since we require at least one Member or Officer to be providing active
oversight of each project, and the Incubator PMC consists of all of those
mentors, plus others. If that fails, we need to review the situation. If
we cannot find a Member or Officer willing to provide that active oversight,
we won't be able to incubate that project. This means that when some other
PMC votes for the ASF to Incubate a project, they must provide such a person
to perform the oversight. Else we will not accept the project. Voting for
us to accept a project, without providing that oversight, would be
irresponsible and won't be accepted.
We should also make sure that our projects understand the importance of
oversight, and notify the Incubator PMC if those providing oversight go
AWOL. The PPMC should be a vital part of Incubation.
And we require quarterly reports from all of our projects to keep track of
what is happening, which addresses Rob's question.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Is the incubator out of control?
Posted by Ted Leung <tw...@sauria.com>.
On Dec 20, 2005, at 4:49 PM, Martin Cooper wrote:
> Personally, I am less than happy at seeing yet another large project
> proposed from a corporate source (and IBM at that), along with a
> dozen new
> committers who have not earned their merit at the ASF as most
> committers
> have. I feel the ASF is losing its way, and becoming a repository for
> corporate open-sourcing along with taking on responsibility for
> building
> communities around corporate code bases. I suspect I'm in the
> minority at
> the ASF, and I'm undoubtedly in the minority here in the incubator.
> But
> there doesn't seem to be a way for the incubator to say "no
> thanks", other
> than by a podling failing the incubation process, and that seems
> wrong to
> me.
The merits of the particular proposal aside, I wanted to comment on
this paragraph. This year at ApacheCon I was surprised to find that
a number of people also feel that the ASF is growing far too
quickly. I know that are some people who believe that the growth
that we are experiencing is indicative of our success.
Unfortunately, I don't agree with that. I think that the
incubation process is setting an incredibly low bar for access to the
Apache brand name, and this is a bad thing. Corporations see the
value of the brand name, that's why they want to come here and are
willing to put up with all our overhead.
----
Ted Leung Blog: <http://www.sauria.com/blog>
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
I think it's been mentioned a couple of times, so I'll try to clarify what
Zimbra is about. Zimbra is primarily a client-side AJAX toolkit. There is
a small server-side component, currently implemented as JSPs (though we've
hacked up a PHP-based version as well as proof of concept) The server
piece is simply to assemble the page and do some handling of string bundles
and locales for internationalization. If we can find ways to do this on
the client, we should do so. There is also a build-time piece to assemble
images into groups and separate into high-res and low-res versions for
optimal image handling. Otherwise, the functionality is bound to the
client-side DOM with JavaScript, as you'd expect.
Zimbra does have a Java feel to it; it will be familiar to Java programmers
and SWT programmers in particular. You might view that as a strength or a
weakness. It's just one approach. Old school JavaScript? Well, it may
not have namespaces, but it is object-oriented. Your criticisms are well
noted, and this again is what we would like to get out of the incubation
process. If namespaces would be helpful to Zimbra, perhaps it's not too
late to add them? Same for other progresssive programming techniques that
could be incorporated.
Download size and speed are concerns. There are many ways to address this,
including tooling that is on our todo list for generic handling of
whitespace, compression of symbols, coalescing into fewer files, etc (does
not necessarily have to be Eclipse-based, btw) and handling of dependencies
could also help bring down the download size, not just for Zimbra but for
other JS code as well. There is plenty of room for improvement, and we'd
like to work on all these things under the guidance of and with assistance
of the Apache community.
Regarding the coupling between the toolkit and the runtimes, I can only say
that there is no secret handshake and that we are currently implementing
plugins for three different runtimes to prove our point. Zimbra was the
first. Now each runtime is different, and we are trying to find
commonality where we can. With each new runtime we may discover new
requirements on our public APIs, etc., but the goal is to have pluggable
runtimes and to be "friendly" to as many toolkits as possible. To get
custom functionality, some runtimes will clearly have a lot of code to
write. It's not all going to be wizard driven.
I tried to provide a more complete explanation of our dependencies on
xulrunner and javaconnect in my reply to Sanjiva tonight -- let me know if
it needs clarification. Rico is present only so that the tooling may
deploy it with Rico-based projects (unmodified). JSLint and Rhino are both
used for syntax checking in the IDE (both on-the-fly and in batch mode) and
are packaged within Eclipse plugins as binaries, unmodified.
And lastly, tooling and runtimes do not have to be the only subprojects. I
hope I mentioned it in the proposal, but there are other ideas kicking
around for AJAX utilities as well, such as a shared client-side data model,
which might be implemented in such a way that it could be used by more than
one runtime.
-Adam
Martin Cooper
<martinc@apache.o
rg> To
Sent by: general@incubator.apache.org
mfncooper@gmail.c cc
om
Subject
Re: AJAX Toolkit Framework Proposal
12/20/2005 07:49
PM
Please respond to
general
Some comments:
1) This appears to be two proposals rolled into one. One is to incubate a
JavaScript toolkit. (It's not clear to me at this point whether or not that
toolkit includes a server-side component, but that's not really relevant at
this point.) The other is to incubate a development environment that can be
used with that toolkit, or apparently with other toolkits if the necessary
work is done. The former comes from Zimbra; the latter from IBM. It's not
clear to me why this is a single proposal and not two separate ones. I
understand that there is synergy between the two, but I believe that
explicitly separating them will make each part stronger. The proposal as it
is now leaves quite a bit if doubt as to where one ends and the other
begins, begging the question of just how separate they really are, and how
"friendly" to other JavaScript toolkits.
2) Various comments have been made regarding multiple ASF projects
addressing the same area being OK, and indeed a good thing. While I
generally agree with that sentiment, there are grounds for concern when it
comes to JavaScript toolkits running in the browser. One issue is that of
footprint. As it is today, Zimbra appears to be about a 1.25MB download to
the browser, if everything is included. That is *massive* for a JavaScript
toolkit. To include that for, for example, one portlet on a portal page,
while the remaining portlets use other toolkits, and hence yet more
downloads, is expensive and slow. This may sound theoretical, but recall
that another substantial JavaScript toolkit is already on its way to the
ASF, in the form of ADF Faces from Oracle, heading for MyFaces. That
project
is not (I sincerely hope) going to want to develop components that target
multiple huge JavaScript toolkits in the same library.
3) Related to the above, but from a more technical perspective, it is very
disappointing to see so much old-school JavaScript in this toolkit. For
example, the code is not namespaced, leading to greater potential for
collisions, and appears to be written more like Java code, instead of
taking
advantage of the features of the JavaScript language. (This is likely a
factor in why the amount of code is so large.) The use of the Rico toolkit
is also mentioned in the proposal. That toolkit is built on Prototype,
which
is popular but fragile, and will rapidly lead to problems in any
non-uniform
environment, especially in portals.
4) While #3 above is technical in nature, such a code base coming to the
ASF
will tend to lend credence to the way it is structured and built, as a
side-effect of the stature of the ASF. IMO, it would do the JavaScript
community a disservice to promote old-style JavaScript coding when we
should
be trying to lead the way in the new world of AJAX. This, of course,
doesn't
apply to the IDE part of the proposal, which I'm sure any JavaScript
developer would appreciate (as long as it works with their toolkit of
choice, which it purports to do ;).
5) Given that we have numerous open issues regarding the inclusion of
components with non-Apache licenses, I would like to see a more explicit
description of the relationship between the proposed code base and other
artifacts mentioned in the proposal, such as XULRunner, JavaConnect, Rhino,
JSLint and Rico. I know that we current have a problem with Rhino because
of
the NPL. What other issues does this proposal introduce?
Personally, I am less than happy at seeing yet another large project
proposed from a corporate source (and IBM at that), along with a dozen new
committers who have not earned their merit at the ASF as most committers
have. I feel the ASF is losing its way, and becoming a repository for
corporate open-sourcing along with taking on responsibility for building
communities around corporate code bases. I suspect I'm in the minority at
the ASF, and I'm undoubtedly in the minority here in the incubator. But
there doesn't seem to be a way for the incubator to say "no thanks", other
than by a podling failing the incubation process, and that seems wrong to
me.
--
Martin Cooper
On 12/20/05, Sam Ruby <ru...@apache.org> wrote:
>
> Kenneth Tam wrote:
> > I have a more specific question: have you guys considered separating
> > this into a plug-ins/tooling donation to Eclipse, and a runtime
> > donation to Apache? It seems like the IP is already in a form that
> > makes this easy (ie, the AJAX Toolkit Framework Eclipse plugins from
> > IBM, and the AjaxTK Javascript library from Zimbra), and there are
> > several examples that suggest this kind of parallel community building
> > works well.
>
> I'll take this question, as well as Cliff's below.
>
> First, for starters, it is worth noting that there is Apache Licensed
> code all over the internet - SourceForge, CodeHaus, people's private
> sites, whatever. Similarly for Eclipse plugins.
>
> Second, code licensed under the Apache license can be sublicensed and/or
> bundled/shipped with other projects. Example: Eclipse ships Ant.
>
> Separate from the IP, the goal is to build a community, a single place
> to go to where AJAX related components can be found. We see an
> opportunity to build such a community independent of where the
> components originated. A community where Dojo and others would be
> welcome (but not required!) to join, or not, as they wish.
>
> Adam can certainly speak to the technical aspects of this than I can,
> but AJAX certainly causes one to rethink the traditional client/server
> boundary, in fact it tends to blur it. One can pick off small pieces
> and say this definately belongs on the server, and that could ship with
> eclipse, but there are also gray area pieces that we could pick a spot
> based on our current understanding, but over time or with the inclusion
> of new members and their points of view, our understanding may shift.
> It would be advantageous if everything were licensened identically so
> that such decisions could be made on a purely technical basis, and not
> based on other considerations.
>
> Life is hard enough as is.
>
> - - -
>
> Could we develop this at the ASF with the Eclipse license? The answer
> would be no. Could we develop this at Eclipse with the Apache
> license... I'll let Eclipse answer that.
>
> Could we develop this at the ASF, with the Apache license, and let
> Eclipse sublicense and/or bundle and ship any or all of this? That
> question I can answer: yes! And the hope would be that this could serve
> as the basis for some cross fertilization and teamwork between the two
> larger organizations.
>
> - - -
>
> Now to directly Cliff's question: yes, we considered proposing this to
> Eclipse. And we talked with a number of people there. And surprisingly
> enough - we thought those discussions were settled but they seem to have
> sprung back up again after Adam sent in the proposal.
>
> We will pursue those discussions to their completion.
>
> Suffice it to say that Eclipse folks are following this mailing list. I
> invite them to share their thoughts here.
>
> - - -
>
> My recommendation is that we focus on concrete proposals, and code
> bases. If people would like to suggest specific additions or removals
> from the proposal, lets hear it. The proposal as it stands is to build
> a unified, vibrant, and diverse community around code licensed under the
> Apache License, version 2.0. And here seems like a good place to make
> that happen.
>
> - Sam Ruby
>
> P.S. If this isn't complicated enough, there is a third party: Mozilla
> involved. At least there the line seems somewhat clearer.
>
> > On 12/20/05, Cliff Schmidt <cl...@gmail.com> wrote:
> >
> >>Adam,
> >>
> >>Can you tell me if you considered proposing this to the Eclipse
> Foundation?
> >>
> >>Since this project appears to have far stronger dependencies on
> >>Eclipse Foundation projects rather than anything from Apache, can you
> >>tell me why you think bringing this project here is likely to help you
> >>build a stronger community than you would find at Eclipse? Is there
> >>some other overriding reason you prefer to bring this project to
> >>Apache?
> >>
> >>Cliff
> >>
> >>
> >>On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
> >>
> >>>AJAX Toolkit Framework Proposal
> >>>
> >>>0. Rationale
> >>>
> >>>While the term AJAX (Asynchronous Javascript and XML) has only
recently
> >>>been coined, the underlying web standards and technologies (JavaScript
> >>>a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for
> years.
> >>>Although the term is used in a variety of ways, AJAX typically
> describes
> >>>techniques towards developing interactive applications on the web
> client
> >>>including asynchronous messaging, use of XML grammar in client-side
> >>>applications, incremental page updates, and improved user interface
> >>>controls. AJAX applications combine the rich UI experience of
> programmed
> >>>clients with the low-cost lifecycle management of web-based
> applications.
> >>>
> >>>AJAX has raised awareness of the high potential of web applications,
it
> has
> >>>encouraged companies to adopt rich web-based interfaces over
> traditional
> >>>"fat" clients, and it has spawned development activity to create
> toolkits
> >>>and abstractions to make AJAX-style development easier and more
> powerful.
> >>>This is an important trend for open source. The client itself can be
> >>>composed entirely of open-source parts, such as Mozilla's Firefox or
> KDE's
> >>>Konqueror, and does not require any particular operating system,
> helping to
> >>>make a more level playing field for all development. More
importantly,
> >>>AJAX is back-end agnostic as transactions are done over HTTP. Keeping
> the
> >>>client open forces vendors to keep the communication channel open as
> well,
> >>>and this can only continue as long as the client technology keeps pace
> with
> >>>proprietary alternatives. The open, standards based communications
> channel
> >>>is what drives many technologies inside Apache, so success of the open
> >>>client is vital to Apache. The mission of this project is to
encourage
> >>>innovation around enterprise-strength client runtimes and tools and
> build a
> >>>community which can select and nurture a select set which will be most
> >>>beneficial to the web.
> >>>
> >>>0.1 Criteria
> >>>
> >>>Meritocracy:
> >>>
> >>>Apache was chosen for an incubator primarily because of the guidance
> the
> >>>community can provide. The two subprojects put forth are among the
> first
> >>>attempts to formalize this style of development. Additional ideas,
> tools
> >>>or entire runtimes may come forward and indeed would be welcomed to
the
> >>>project, either wholesale as new subprojects or incorporated into the
> >>>existing code.
> >>>
> >>>Community:
> >>>
> >>>The contributed work was inspired by open source development but needs
> a
> >>>strong and diverse community to validate its mission and carry it
> forward.
> >>>A primary objective of the project is to build a vibrant community of
> users
> >>>and active contributors.
> >>>
> >>>Core Developers:
> >>>
> >>>All of the initial committers are members of Zimbra and IBM
development
> >>>teams. All developers have worked on open source projects before and
> have
> >>>experience and understanding of open source principles.
> >>>
> >>>Alignment:
> >>>
> >>>Initial implementation consists of two sub projects.
> >>>
> >>>The AJAX Toolkit Framework will provide a strategic framework for
> >>>Interactive Development Environments (IDEs) for the many different
AJAX
> >>>toolkit offerings in the market. It provides a rich set of tools for
> the
> >>>AJAX / DHTML developer including: a JavaScript editor with edit-time
> syntax
> >>>checking; Mozilla web browser; integrated DOM browser; integrated
> >>>JavaScript debugger; and wizards and development aides tuned to
> specific
> >>>libraries and toolkits. The Framework is extensible to support other
> AJAX
> >>>toolkits and has a wizard-based tool to facilitate the integration of
> new
> >>>toolkits in the framework.
> >>>
> >>>The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> >>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
> set of
> >>>Plugin extensions to Eclipse. It embeds 4 other open source
components:
> >>>Rhino, JSLint, Rico and Zimbra. No code modifications will be made to
> the
> >>>4 open source components specified. They are incorporated to
> accommodate
> >>>Eclipse plugin architecture and distributed as-is by repackaging them
> as
> >>>part of the AJAX Toolkit Framework.
> >>>
> >>>The Zimbra AJAX Development Toolkit, the first toolkit integrated into
> the
> >>>framework, provides a rich client library, similar in style to
> traditional
> >>>object-oriented widget libraries like Eclipse's SWT. This toolkit
> hides
> >>>implementation details and browser quirks and makes web development
> more
> >>>accessible to the enterprise developer. It provides
> >>>
> >>> * User interface development
> >>> * Network communications (both synchronous and asynchronous)
> >>> * SOAP programming
> >>> * XML document creation and manipulation
> >>> * UI event handling and management
> >>>
> >>>For further information, please see the Zimbra AjaxTK whitepaper:
> >>>http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
> >>>
> >>>0.2 Warning signs
> >>>
> >>>Orphaned products:
> >>>
> >>>The initial code submission is based on colloborative work between IBM
> and
> >>>Zimbra to provide a toolkit and a framework to embed the toolkit in
IDE
> >>>environment and provide additional enhancements. Both the companies
> believe
> >>>that taking a joint approach and making it available through open
> source
> >>>will make it widely accepted and create a community and unify Industry
> >>>momentum to consolidate requirements and accelerate community growth
> and
> >>>enhance the toolkit to ease development of AJAX applications.
> >>>
> >>>Inexperience with open source:
> >>>
> >>>Both the companies and several of the commiters are very experienced
in
> >>>Open Source environment. All efforts will be made to ensure that the
> work
> >>>done and momentum will be in strict adherence to open source
> guidelines.
> >>>
> >>>Homogenous developers:
> >>>
> >>>The current list of committers includes developers who are
> geographically
> >>>distributed. They are experienced with working in a distributed
> >>>environment, and with resolving technical differences.
> >>>
> >>>Reliance on salaried developers:
> >>>
> >>>All of the initial developers are paid by their employers to
contribute
> to
> >>>this project and the employers track records for ongoing investment in
> open
> >>>source communities well known.
> >>>
> >>>No ties to other Apache products:
> >>>
> >>>The initial codebase will be licensed under the Apache License 2.0.The
> >>>dependencies on other external projects are defined in the alignment
> >>>section. While there are no direct build dependencies on other Apache
> >>>projects, the development of AJAX clients will often be driven by
> Apache
> >>>middleware and will have a positive impact on the open source movement
> as
> >>>described in the "Rationale" section.
> >>>
> >>>A fascination with the Apache brand:
> >>>
> >>>The committers are intent on developing a strong open source
community.
> We
> >>>believe that the Apache Software Foundation's emphasis on community
> >>>development makes it the most suitable choice.
> >>>
> >>>1. Scope of the subprojects
> >>>
> >>>
> >>>The subprojects will include development tools necessary to encourage
> >>>browser-based, AJAX-style development for individual users as well as
> in
> >>>the enterprise. The tools will be driven by an extensible IDE
> Framework
> >>>and may include utilities to assist in code development, analysis, and
> >>>testing. The tools will be adaptable to different AJAX runtimes, some
> of
> >>>which will also be subprojects in the incubator. The initial
> submission
> >>>includes an IDE and one such runtime.
> >>>
> >>>These initial projects are intended merely as starting points and
> should
> >>>not be taken as bounding the scope of the project as a whole. Some
> other
> >>>potential projects may include:
> >>>
> >>> * WYSIWYG tools for building AJAX-style interfaces
> >>> * Declarative grammars or abstractions for AJAX programming
> >>> * A common data model to facilitate efficient server communication
> with
> >>>Javascript or DOM access
> >>>
> >>>2. Identify the initial source from which the subprojects are to be
> >>>populated
> >>>
> >>>AJAX Toolkit Framework was developed at IBM as a set of plugins based
> on
> >>>the Eclipse Framework and WebTools Project. Zip files containing
> snapshots
> >>>of CVS directories are provided with this proposal at
> >>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> >>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
> >>>
> >>>The Zimbra AjaxTK is available today in open source, and can be
> downloaded
> >>>as part of the Zimbra Collaboration Suite (choose the source code
> version)
> >>>at
> >>>http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> >>>toolkit code is provided at
> http://www.apache.org/~rubys/ajax/Ajax.tar.gz
> >>>
> >>>2.1 External Dependencies of the project
> >>>
> >>>AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> >>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
> set of
> >>>Plugin extensions to Eclipse. It embeds four other open source
> components
> >>>Rhino, JSLint, Rico and Zimbra. No code modifications will be made to
> the
> >>>four open source components specified. They are incorporated to
> accommodate
> >>>Eclipse plugin architecture and distributed as is by repackaging them
> as
> >>>part of AJAX Toolkit Framework. In the future any AJAX toolkit that is
> to
> >>>be supported can be included as another plugin.
> >>>
> >>>3. Identify the ASF resources to be created
> >>>
> >>>3.1 mailing list(s)
> >>>
> >>> * ajaxtk-ppmc
> >>> * ajaxtk-dev
> >>> * ajaxtk-commits
> >>> * ajaxtk-user
> >>>
> >>>3.2 Subversion repository
> >>>
> >>> * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
> >>>
> >>>3.3 Bugzilla
> >>>
> >>> * AJAXTK (AJAXTK)
> >>>
> >>>4. Identify the initial set of committers:
> >>>
> >>> * Craig Becker
> >>> * Leugim Bustelo
> >>> * Andrew Clark
> >>> * Conrad Damon
> >>> * Ross Dargahi
> >>> * Becky Gibson
> >>> * Javier Pedemonte
> >>> * Adam Peller
> >>> * Roland Schemers
> >>> * Donald Sedota
> >>> * Parag Shah
> >>> * Greg Solovyev
> >>>
> >>>5. Identify Apache sponsoring individual
> >>>
> >>>We request that the Apache Incubator PMC sponsor the AJAX Toolkit
> Framework
> >>>as an
> >>>incubating project, with the eventual goal of graduation as a TLP.
The
> >>>initial contributors feel the scope of the project doesn't clearly
> >>>overlap with any existing TLP, and is broad enough to justify eventual
> >>>TLP status.
> >>>
> >>>Champion: Sam Ruby
> >>>
> >>>Mentors: ??
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>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
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Martin Cooper <ma...@apache.org>.
Some comments:
1) This appears to be two proposals rolled into one. One is to incubate a
JavaScript toolkit. (It's not clear to me at this point whether or not that
toolkit includes a server-side component, but that's not really relevant at
this point.) The other is to incubate a development environment that can be
used with that toolkit, or apparently with other toolkits if the necessary
work is done. The former comes from Zimbra; the latter from IBM. It's not
clear to me why this is a single proposal and not two separate ones. I
understand that there is synergy between the two, but I believe that
explicitly separating them will make each part stronger. The proposal as it
is now leaves quite a bit if doubt as to where one ends and the other
begins, begging the question of just how separate they really are, and how
"friendly" to other JavaScript toolkits.
2) Various comments have been made regarding multiple ASF projects
addressing the same area being OK, and indeed a good thing. While I
generally agree with that sentiment, there are grounds for concern when it
comes to JavaScript toolkits running in the browser. One issue is that of
footprint. As it is today, Zimbra appears to be about a 1.25MB download to
the browser, if everything is included. That is *massive* for a JavaScript
toolkit. To include that for, for example, one portlet on a portal page,
while the remaining portlets use other toolkits, and hence yet more
downloads, is expensive and slow. This may sound theoretical, but recall
that another substantial JavaScript toolkit is already on its way to the
ASF, in the form of ADF Faces from Oracle, heading for MyFaces. That project
is not (I sincerely hope) going to want to develop components that target
multiple huge JavaScript toolkits in the same library.
3) Related to the above, but from a more technical perspective, it is very
disappointing to see so much old-school JavaScript in this toolkit. For
example, the code is not namespaced, leading to greater potential for
collisions, and appears to be written more like Java code, instead of taking
advantage of the features of the JavaScript language. (This is likely a
factor in why the amount of code is so large.) The use of the Rico toolkit
is also mentioned in the proposal. That toolkit is built on Prototype, which
is popular but fragile, and will rapidly lead to problems in any non-uniform
environment, especially in portals.
4) While #3 above is technical in nature, such a code base coming to the ASF
will tend to lend credence to the way it is structured and built, as a
side-effect of the stature of the ASF. IMO, it would do the JavaScript
community a disservice to promote old-style JavaScript coding when we should
be trying to lead the way in the new world of AJAX. This, of course, doesn't
apply to the IDE part of the proposal, which I'm sure any JavaScript
developer would appreciate (as long as it works with their toolkit of
choice, which it purports to do ;).
5) Given that we have numerous open issues regarding the inclusion of
components with non-Apache licenses, I would like to see a more explicit
description of the relationship between the proposed code base and other
artifacts mentioned in the proposal, such as XULRunner, JavaConnect, Rhino,
JSLint and Rico. I know that we current have a problem with Rhino because of
the NPL. What other issues does this proposal introduce?
Personally, I am less than happy at seeing yet another large project
proposed from a corporate source (and IBM at that), along with a dozen new
committers who have not earned their merit at the ASF as most committers
have. I feel the ASF is losing its way, and becoming a repository for
corporate open-sourcing along with taking on responsibility for building
communities around corporate code bases. I suspect I'm in the minority at
the ASF, and I'm undoubtedly in the minority here in the incubator. But
there doesn't seem to be a way for the incubator to say "no thanks", other
than by a podling failing the incubation process, and that seems wrong to
me.
--
Martin Cooper
On 12/20/05, Sam Ruby <ru...@apache.org> wrote:
>
> Kenneth Tam wrote:
> > I have a more specific question: have you guys considered separating
> > this into a plug-ins/tooling donation to Eclipse, and a runtime
> > donation to Apache? It seems like the IP is already in a form that
> > makes this easy (ie, the AJAX Toolkit Framework Eclipse plugins from
> > IBM, and the AjaxTK Javascript library from Zimbra), and there are
> > several examples that suggest this kind of parallel community building
> > works well.
>
> I'll take this question, as well as Cliff's below.
>
> First, for starters, it is worth noting that there is Apache Licensed
> code all over the internet - SourceForge, CodeHaus, people's private
> sites, whatever. Similarly for Eclipse plugins.
>
> Second, code licensed under the Apache license can be sublicensed and/or
> bundled/shipped with other projects. Example: Eclipse ships Ant.
>
> Separate from the IP, the goal is to build a community, a single place
> to go to where AJAX related components can be found. We see an
> opportunity to build such a community independent of where the
> components originated. A community where Dojo and others would be
> welcome (but not required!) to join, or not, as they wish.
>
> Adam can certainly speak to the technical aspects of this than I can,
> but AJAX certainly causes one to rethink the traditional client/server
> boundary, in fact it tends to blur it. One can pick off small pieces
> and say this definately belongs on the server, and that could ship with
> eclipse, but there are also gray area pieces that we could pick a spot
> based on our current understanding, but over time or with the inclusion
> of new members and their points of view, our understanding may shift.
> It would be advantageous if everything were licensened identically so
> that such decisions could be made on a purely technical basis, and not
> based on other considerations.
>
> Life is hard enough as is.
>
> - - -
>
> Could we develop this at the ASF with the Eclipse license? The answer
> would be no. Could we develop this at Eclipse with the Apache
> license... I'll let Eclipse answer that.
>
> Could we develop this at the ASF, with the Apache license, and let
> Eclipse sublicense and/or bundle and ship any or all of this? That
> question I can answer: yes! And the hope would be that this could serve
> as the basis for some cross fertilization and teamwork between the two
> larger organizations.
>
> - - -
>
> Now to directly Cliff's question: yes, we considered proposing this to
> Eclipse. And we talked with a number of people there. And surprisingly
> enough - we thought those discussions were settled but they seem to have
> sprung back up again after Adam sent in the proposal.
>
> We will pursue those discussions to their completion.
>
> Suffice it to say that Eclipse folks are following this mailing list. I
> invite them to share their thoughts here.
>
> - - -
>
> My recommendation is that we focus on concrete proposals, and code
> bases. If people would like to suggest specific additions or removals
> from the proposal, lets hear it. The proposal as it stands is to build
> a unified, vibrant, and diverse community around code licensed under the
> Apache License, version 2.0. And here seems like a good place to make
> that happen.
>
> - Sam Ruby
>
> P.S. If this isn't complicated enough, there is a third party: Mozilla
> involved. At least there the line seems somewhat clearer.
>
> > On 12/20/05, Cliff Schmidt <cl...@gmail.com> wrote:
> >
> >>Adam,
> >>
> >>Can you tell me if you considered proposing this to the Eclipse
> Foundation?
> >>
> >>Since this project appears to have far stronger dependencies on
> >>Eclipse Foundation projects rather than anything from Apache, can you
> >>tell me why you think bringing this project here is likely to help you
> >>build a stronger community than you would find at Eclipse? Is there
> >>some other overriding reason you prefer to bring this project to
> >>Apache?
> >>
> >>Cliff
> >>
> >>
> >>On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
> >>
> >>>AJAX Toolkit Framework Proposal
> >>>
> >>>0. Rationale
> >>>
> >>>While the term AJAX (Asynchronous Javascript and XML) has only recently
> >>>been coined, the underlying web standards and technologies (JavaScript
> >>>a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for
> years.
> >>>Although the term is used in a variety of ways, AJAX typically
> describes
> >>>techniques towards developing interactive applications on the web
> client
> >>>including asynchronous messaging, use of XML grammar in client-side
> >>>applications, incremental page updates, and improved user interface
> >>>controls. AJAX applications combine the rich UI experience of
> programmed
> >>>clients with the low-cost lifecycle management of web-based
> applications.
> >>>
> >>>AJAX has raised awareness of the high potential of web applications, it
> has
> >>>encouraged companies to adopt rich web-based interfaces over
> traditional
> >>>"fat" clients, and it has spawned development activity to create
> toolkits
> >>>and abstractions to make AJAX-style development easier and more
> powerful.
> >>>This is an important trend for open source. The client itself can be
> >>>composed entirely of open-source parts, such as Mozilla's Firefox or
> KDE's
> >>>Konqueror, and does not require any particular operating system,
> helping to
> >>>make a more level playing field for all development. More importantly,
> >>>AJAX is back-end agnostic as transactions are done over HTTP. Keeping
> the
> >>>client open forces vendors to keep the communication channel open as
> well,
> >>>and this can only continue as long as the client technology keeps pace
> with
> >>>proprietary alternatives. The open, standards based communications
> channel
> >>>is what drives many technologies inside Apache, so success of the open
> >>>client is vital to Apache. The mission of this project is to encourage
> >>>innovation around enterprise-strength client runtimes and tools and
> build a
> >>>community which can select and nurture a select set which will be most
> >>>beneficial to the web.
> >>>
> >>>0.1 Criteria
> >>>
> >>>Meritocracy:
> >>>
> >>>Apache was chosen for an incubator primarily because of the guidance
> the
> >>>community can provide. The two subprojects put forth are among the
> first
> >>>attempts to formalize this style of development. Additional ideas,
> tools
> >>>or entire runtimes may come forward and indeed would be welcomed to the
> >>>project, either wholesale as new subprojects or incorporated into the
> >>>existing code.
> >>>
> >>>Community:
> >>>
> >>>The contributed work was inspired by open source development but needs
> a
> >>>strong and diverse community to validate its mission and carry it
> forward.
> >>>A primary objective of the project is to build a vibrant community of
> users
> >>>and active contributors.
> >>>
> >>>Core Developers:
> >>>
> >>>All of the initial committers are members of Zimbra and IBM development
> >>>teams. All developers have worked on open source projects before and
> have
> >>>experience and understanding of open source principles.
> >>>
> >>>Alignment:
> >>>
> >>>Initial implementation consists of two sub projects.
> >>>
> >>>The AJAX Toolkit Framework will provide a strategic framework for
> >>>Interactive Development Environments (IDEs) for the many different AJAX
> >>>toolkit offerings in the market. It provides a rich set of tools for
> the
> >>>AJAX / DHTML developer including: a JavaScript editor with edit-time
> syntax
> >>>checking; Mozilla web browser; integrated DOM browser; integrated
> >>>JavaScript debugger; and wizards and development aides tuned to
> specific
> >>>libraries and toolkits. The Framework is extensible to support other
> AJAX
> >>>toolkits and has a wizard-based tool to facilitate the integration of
> new
> >>>toolkits in the framework.
> >>>
> >>>The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> >>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
> set of
> >>>Plugin extensions to Eclipse. It embeds 4 other open source components:
> >>>Rhino, JSLint, Rico and Zimbra. No code modifications will be made to
> the
> >>>4 open source components specified. They are incorporated to
> accommodate
> >>>Eclipse plugin architecture and distributed as-is by repackaging them
> as
> >>>part of the AJAX Toolkit Framework.
> >>>
> >>>The Zimbra AJAX Development Toolkit, the first toolkit integrated into
> the
> >>>framework, provides a rich client library, similar in style to
> traditional
> >>>object-oriented widget libraries like Eclipse's SWT. This toolkit
> hides
> >>>implementation details and browser quirks and makes web development
> more
> >>>accessible to the enterprise developer. It provides
> >>>
> >>> * User interface development
> >>> * Network communications (both synchronous and asynchronous)
> >>> * SOAP programming
> >>> * XML document creation and manipulation
> >>> * UI event handling and management
> >>>
> >>>For further information, please see the Zimbra AjaxTK whitepaper:
> >>>http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
> >>>
> >>>0.2 Warning signs
> >>>
> >>>Orphaned products:
> >>>
> >>>The initial code submission is based on colloborative work between IBM
> and
> >>>Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> >>>environment and provide additional enhancements. Both the companies
> believe
> >>>that taking a joint approach and making it available through open
> source
> >>>will make it widely accepted and create a community and unify Industry
> >>>momentum to consolidate requirements and accelerate community growth
> and
> >>>enhance the toolkit to ease development of AJAX applications.
> >>>
> >>>Inexperience with open source:
> >>>
> >>>Both the companies and several of the commiters are very experienced in
> >>>Open Source environment. All efforts will be made to ensure that the
> work
> >>>done and momentum will be in strict adherence to open source
> guidelines.
> >>>
> >>>Homogenous developers:
> >>>
> >>>The current list of committers includes developers who are
> geographically
> >>>distributed. They are experienced with working in a distributed
> >>>environment, and with resolving technical differences.
> >>>
> >>>Reliance on salaried developers:
> >>>
> >>>All of the initial developers are paid by their employers to contribute
> to
> >>>this project and the employers track records for ongoing investment in
> open
> >>>source communities well known.
> >>>
> >>>No ties to other Apache products:
> >>>
> >>>The initial codebase will be licensed under the Apache License 2.0.The
> >>>dependencies on other external projects are defined in the alignment
> >>>section. While there are no direct build dependencies on other Apache
> >>>projects, the development of AJAX clients will often be driven by
> Apache
> >>>middleware and will have a positive impact on the open source movement
> as
> >>>described in the "Rationale" section.
> >>>
> >>>A fascination with the Apache brand:
> >>>
> >>>The committers are intent on developing a strong open source community.
> We
> >>>believe that the Apache Software Foundation's emphasis on community
> >>>development makes it the most suitable choice.
> >>>
> >>>1. Scope of the subprojects
> >>>
> >>>
> >>>The subprojects will include development tools necessary to encourage
> >>>browser-based, AJAX-style development for individual users as well as
> in
> >>>the enterprise. The tools will be driven by an extensible IDE
> Framework
> >>>and may include utilities to assist in code development, analysis, and
> >>>testing. The tools will be adaptable to different AJAX runtimes, some
> of
> >>>which will also be subprojects in the incubator. The initial
> submission
> >>>includes an IDE and one such runtime.
> >>>
> >>>These initial projects are intended merely as starting points and
> should
> >>>not be taken as bounding the scope of the project as a whole. Some
> other
> >>>potential projects may include:
> >>>
> >>> * WYSIWYG tools for building AJAX-style interfaces
> >>> * Declarative grammars or abstractions for AJAX programming
> >>> * A common data model to facilitate efficient server communication
> with
> >>>Javascript or DOM access
> >>>
> >>>2. Identify the initial source from which the subprojects are to be
> >>>populated
> >>>
> >>>AJAX Toolkit Framework was developed at IBM as a set of plugins based
> on
> >>>the Eclipse Framework and WebTools Project. Zip files containing
> snapshots
> >>>of CVS directories are provided with this proposal at
> >>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> >>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
> >>>
> >>>The Zimbra AjaxTK is available today in open source, and can be
> downloaded
> >>>as part of the Zimbra Collaboration Suite (choose the source code
> version)
> >>>at
> >>>http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> >>>toolkit code is provided at
> http://www.apache.org/~rubys/ajax/Ajax.tar.gz
> >>>
> >>>2.1 External Dependencies of the project
> >>>
> >>>AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> >>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
> set of
> >>>Plugin extensions to Eclipse. It embeds four other open source
> components
> >>>Rhino, JSLint, Rico and Zimbra. No code modifications will be made to
> the
> >>>four open source components specified. They are incorporated to
> accommodate
> >>>Eclipse plugin architecture and distributed as is by repackaging them
> as
> >>>part of AJAX Toolkit Framework. In the future any AJAX toolkit that is
> to
> >>>be supported can be included as another plugin.
> >>>
> >>>3. Identify the ASF resources to be created
> >>>
> >>>3.1 mailing list(s)
> >>>
> >>> * ajaxtk-ppmc
> >>> * ajaxtk-dev
> >>> * ajaxtk-commits
> >>> * ajaxtk-user
> >>>
> >>>3.2 Subversion repository
> >>>
> >>> * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
> >>>
> >>>3.3 Bugzilla
> >>>
> >>> * AJAXTK (AJAXTK)
> >>>
> >>>4. Identify the initial set of committers:
> >>>
> >>> * Craig Becker
> >>> * Leugim Bustelo
> >>> * Andrew Clark
> >>> * Conrad Damon
> >>> * Ross Dargahi
> >>> * Becky Gibson
> >>> * Javier Pedemonte
> >>> * Adam Peller
> >>> * Roland Schemers
> >>> * Donald Sedota
> >>> * Parag Shah
> >>> * Greg Solovyev
> >>>
> >>>5. Identify Apache sponsoring individual
> >>>
> >>>We request that the Apache Incubator PMC sponsor the AJAX Toolkit
> Framework
> >>>as an
> >>>incubating project, with the eventual goal of graduation as a TLP. The
> >>>initial contributors feel the scope of the project doesn't clearly
> >>>overlap with any existing TLP, and is broad enough to justify eventual
> >>>TLP status.
> >>>
> >>>Champion: Sam Ruby
> >>>
> >>>Mentors: ??
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>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
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: AJAX Toolkit Framework Proposal
Posted by Sam Ruby <ru...@apache.org>.
Kenneth Tam wrote:
> I have a more specific question: have you guys considered separating
> this into a plug-ins/tooling donation to Eclipse, and a runtime
> donation to Apache? It seems like the IP is already in a form that
> makes this easy (ie, the AJAX Toolkit Framework Eclipse plugins from
> IBM, and the AjaxTK Javascript library from Zimbra), and there are
> several examples that suggest this kind of parallel community building
> works well.
I'll take this question, as well as Cliff's below.
First, for starters, it is worth noting that there is Apache Licensed
code all over the internet - SourceForge, CodeHaus, people's private
sites, whatever. Similarly for Eclipse plugins.
Second, code licensed under the Apache license can be sublicensed and/or
bundled/shipped with other projects. Example: Eclipse ships Ant.
Separate from the IP, the goal is to build a community, a single place
to go to where AJAX related components can be found. We see an
opportunity to build such a community independent of where the
components originated. A community where Dojo and others would be
welcome (but not required!) to join, or not, as they wish.
Adam can certainly speak to the technical aspects of this than I can,
but AJAX certainly causes one to rethink the traditional client/server
boundary, in fact it tends to blur it. One can pick off small pieces
and say this definately belongs on the server, and that could ship with
eclipse, but there are also gray area pieces that we could pick a spot
based on our current understanding, but over time or with the inclusion
of new members and their points of view, our understanding may shift.
It would be advantageous if everything were licensened identically so
that such decisions could be made on a purely technical basis, and not
based on other considerations.
Life is hard enough as is.
- - -
Could we develop this at the ASF with the Eclipse license? The answer
would be no. Could we develop this at Eclipse with the Apache
license... I'll let Eclipse answer that.
Could we develop this at the ASF, with the Apache license, and let
Eclipse sublicense and/or bundle and ship any or all of this? That
question I can answer: yes! And the hope would be that this could serve
as the basis for some cross fertilization and teamwork between the two
larger organizations.
- - -
Now to directly Cliff's question: yes, we considered proposing this to
Eclipse. And we talked with a number of people there. And surprisingly
enough - we thought those discussions were settled but they seem to have
sprung back up again after Adam sent in the proposal.
We will pursue those discussions to their completion.
Suffice it to say that Eclipse folks are following this mailing list. I
invite them to share their thoughts here.
- - -
My recommendation is that we focus on concrete proposals, and code
bases. If people would like to suggest specific additions or removals
from the proposal, lets hear it. The proposal as it stands is to build
a unified, vibrant, and diverse community around code licensed under the
Apache License, version 2.0. And here seems like a good place to make
that happen.
- Sam Ruby
P.S. If this isn't complicated enough, there is a third party: Mozilla
involved. At least there the line seems somewhat clearer.
> On 12/20/05, Cliff Schmidt <cl...@gmail.com> wrote:
>
>>Adam,
>>
>>Can you tell me if you considered proposing this to the Eclipse Foundation?
>>
>>Since this project appears to have far stronger dependencies on
>>Eclipse Foundation projects rather than anything from Apache, can you
>>tell me why you think bringing this project here is likely to help you
>>build a stronger community than you would find at Eclipse? Is there
>>some other overriding reason you prefer to bring this project to
>>Apache?
>>
>>Cliff
>>
>>
>>On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
>>
>>>AJAX Toolkit Framework Proposal
>>>
>>>0. Rationale
>>>
>>>While the term AJAX (Asynchronous Javascript and XML) has only recently
>>>been coined, the underlying web standards and technologies (JavaScript
>>>a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
>>>Although the term is used in a variety of ways, AJAX typically describes
>>>techniques towards developing interactive applications on the web client
>>>including asynchronous messaging, use of XML grammar in client-side
>>>applications, incremental page updates, and improved user interface
>>>controls. AJAX applications combine the rich UI experience of programmed
>>>clients with the low-cost lifecycle management of web-based applications.
>>>
>>>AJAX has raised awareness of the high potential of web applications, it has
>>>encouraged companies to adopt rich web-based interfaces over traditional
>>>"fat" clients, and it has spawned development activity to create toolkits
>>>and abstractions to make AJAX-style development easier and more powerful.
>>>This is an important trend for open source. The client itself can be
>>>composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
>>>Konqueror, and does not require any particular operating system, helping to
>>>make a more level playing field for all development. More importantly,
>>>AJAX is back-end agnostic as transactions are done over HTTP. Keeping the
>>>client open forces vendors to keep the communication channel open as well,
>>>and this can only continue as long as the client technology keeps pace with
>>>proprietary alternatives. The open, standards based communications channel
>>>is what drives many technologies inside Apache, so success of the open
>>>client is vital to Apache. The mission of this project is to encourage
>>>innovation around enterprise-strength client runtimes and tools and build a
>>>community which can select and nurture a select set which will be most
>>>beneficial to the web.
>>>
>>>0.1 Criteria
>>>
>>>Meritocracy:
>>>
>>>Apache was chosen for an incubator primarily because of the guidance the
>>>community can provide. The two subprojects put forth are among the first
>>>attempts to formalize this style of development. Additional ideas, tools
>>>or entire runtimes may come forward and indeed would be welcomed to the
>>>project, either wholesale as new subprojects or incorporated into the
>>>existing code.
>>>
>>>Community:
>>>
>>>The contributed work was inspired by open source development but needs a
>>>strong and diverse community to validate its mission and carry it forward.
>>>A primary objective of the project is to build a vibrant community of users
>>>and active contributors.
>>>
>>>Core Developers:
>>>
>>>All of the initial committers are members of Zimbra and IBM development
>>>teams. All developers have worked on open source projects before and have
>>>experience and understanding of open source principles.
>>>
>>>Alignment:
>>>
>>>Initial implementation consists of two sub projects.
>>>
>>>The AJAX Toolkit Framework will provide a strategic framework for
>>>Interactive Development Environments (IDEs) for the many different AJAX
>>>toolkit offerings in the market. It provides a rich set of tools for the
>>>AJAX / DHTML developer including: a JavaScript editor with edit-time syntax
>>>checking; Mozilla web browser; integrated DOM browser; integrated
>>>JavaScript debugger; and wizards and development aides tuned to specific
>>>libraries and toolkits. The Framework is extensible to support other AJAX
>>>toolkits and has a wizard-based tool to facilitate the integration of new
>>>toolkits in the framework.
>>>
>>>The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
>>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
>>>Plugin extensions to Eclipse. It embeds 4 other open source components:
>>>Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
>>>4 open source components specified. They are incorporated to accommodate
>>>Eclipse plugin architecture and distributed as-is by repackaging them as
>>>part of the AJAX Toolkit Framework.
>>>
>>>The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
>>>framework, provides a rich client library, similar in style to traditional
>>>object-oriented widget libraries like Eclipse's SWT. This toolkit hides
>>>implementation details and browser quirks and makes web development more
>>>accessible to the enterprise developer. It provides
>>>
>>> * User interface development
>>> * Network communications (both synchronous and asynchronous)
>>> * SOAP programming
>>> * XML document creation and manipulation
>>> * UI event handling and management
>>>
>>>For further information, please see the Zimbra AjaxTK whitepaper:
>>>http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
>>>
>>>0.2 Warning signs
>>>
>>>Orphaned products:
>>>
>>>The initial code submission is based on colloborative work between IBM and
>>>Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
>>>environment and provide additional enhancements. Both the companies believe
>>>that taking a joint approach and making it available through open source
>>>will make it widely accepted and create a community and unify Industry
>>>momentum to consolidate requirements and accelerate community growth and
>>>enhance the toolkit to ease development of AJAX applications.
>>>
>>>Inexperience with open source:
>>>
>>>Both the companies and several of the commiters are very experienced in
>>>Open Source environment. All efforts will be made to ensure that the work
>>>done and momentum will be in strict adherence to open source guidelines.
>>>
>>>Homogenous developers:
>>>
>>>The current list of committers includes developers who are geographically
>>>distributed. They are experienced with working in a distributed
>>>environment, and with resolving technical differences.
>>>
>>>Reliance on salaried developers:
>>>
>>>All of the initial developers are paid by their employers to contribute to
>>>this project and the employers track records for ongoing investment in open
>>>source communities well known.
>>>
>>>No ties to other Apache products:
>>>
>>>The initial codebase will be licensed under the Apache License 2.0.The
>>>dependencies on other external projects are defined in the alignment
>>>section. While there are no direct build dependencies on other Apache
>>>projects, the development of AJAX clients will often be driven by Apache
>>>middleware and will have a positive impact on the open source movement as
>>>described in the "Rationale" section.
>>>
>>>A fascination with the Apache brand:
>>>
>>>The committers are intent on developing a strong open source community. We
>>>believe that the Apache Software Foundation's emphasis on community
>>>development makes it the most suitable choice.
>>>
>>>1. Scope of the subprojects
>>>
>>>
>>>The subprojects will include development tools necessary to encourage
>>>browser-based, AJAX-style development for individual users as well as in
>>>the enterprise. The tools will be driven by an extensible IDE Framework
>>>and may include utilities to assist in code development, analysis, and
>>>testing. The tools will be adaptable to different AJAX runtimes, some of
>>>which will also be subprojects in the incubator. The initial submission
>>>includes an IDE and one such runtime.
>>>
>>>These initial projects are intended merely as starting points and should
>>>not be taken as bounding the scope of the project as a whole. Some other
>>>potential projects may include:
>>>
>>> * WYSIWYG tools for building AJAX-style interfaces
>>> * Declarative grammars or abstractions for AJAX programming
>>> * A common data model to facilitate efficient server communication with
>>>Javascript or DOM access
>>>
>>>2. Identify the initial source from which the subprojects are to be
>>>populated
>>>
>>>AJAX Toolkit Framework was developed at IBM as a set of plugins based on
>>>the Eclipse Framework and WebTools Project. Zip files containing snapshots
>>>of CVS directories are provided with this proposal at
>>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
>>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
>>>
>>>The Zimbra AjaxTK is available today in open source, and can be downloaded
>>>as part of the Zimbra Collaboration Suite (choose the source code version)
>>>at
>>>http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
>>>toolkit code is provided at http://www.apache.org/~rubys/ajax/Ajax.tar.gz
>>>
>>>2.1 External Dependencies of the project
>>>
>>>AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
>>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
>>>Plugin extensions to Eclipse. It embeds four other open source components
>>>Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
>>>four open source components specified. They are incorporated to accommodate
>>>Eclipse plugin architecture and distributed as is by repackaging them as
>>>part of AJAX Toolkit Framework. In the future any AJAX toolkit that is to
>>>be supported can be included as another plugin.
>>>
>>>3. Identify the ASF resources to be created
>>>
>>>3.1 mailing list(s)
>>>
>>> * ajaxtk-ppmc
>>> * ajaxtk-dev
>>> * ajaxtk-commits
>>> * ajaxtk-user
>>>
>>>3.2 Subversion repository
>>>
>>> * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
>>>
>>>3.3 Bugzilla
>>>
>>> * AJAXTK (AJAXTK)
>>>
>>>4. Identify the initial set of committers:
>>>
>>> * Craig Becker
>>> * Leugim Bustelo
>>> * Andrew Clark
>>> * Conrad Damon
>>> * Ross Dargahi
>>> * Becky Gibson
>>> * Javier Pedemonte
>>> * Adam Peller
>>> * Roland Schemers
>>> * Donald Sedota
>>> * Parag Shah
>>> * Greg Solovyev
>>>
>>>5. Identify Apache sponsoring individual
>>>
>>>We request that the Apache Incubator PMC sponsor the AJAX Toolkit Framework
>>>as an
>>>incubating project, with the eventual goal of graduation as a TLP. The
>>>initial contributors feel the scope of the project doesn't clearly
>>>overlap with any existing TLP, and is broad enough to justify eventual
>>>TLP status.
>>>
>>>Champion: Sam Ruby
>>>
>>>Mentors: ??
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: AJAX Toolkit Framework Proposal
Posted by Kenneth Tam <ke...@gmail.com>.
I have a more specific question: have you guys considered separating
this into a plug-ins/tooling donation to Eclipse, and a runtime
donation to Apache? It seems like the IP is already in a form that
makes this easy (ie, the AJAX Toolkit Framework Eclipse plugins from
IBM, and the AjaxTK Javascript library from Zimbra), and there are
several examples that suggest this kind of parallel community building
works well.
On 12/20/05, Cliff Schmidt <cl...@gmail.com> wrote:
> Adam,
>
> Can you tell me if you considered proposing this to the Eclipse Foundation?
>
> Since this project appears to have far stronger dependencies on
> Eclipse Foundation projects rather than anything from Apache, can you
> tell me why you think bringing this project here is likely to help you
> build a stronger community than you would find at Eclipse? Is there
> some other overriding reason you prefer to bring this project to
> Apache?
>
> Cliff
>
>
> On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
> > AJAX Toolkit Framework Proposal
> >
> > 0. Rationale
> >
> > While the term AJAX (Asynchronous Javascript and XML) has only recently
> > been coined, the underlying web standards and technologies (JavaScript
> > a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
> > Although the term is used in a variety of ways, AJAX typically describes
> > techniques towards developing interactive applications on the web client
> > including asynchronous messaging, use of XML grammar in client-side
> > applications, incremental page updates, and improved user interface
> > controls. AJAX applications combine the rich UI experience of programmed
> > clients with the low-cost lifecycle management of web-based applications.
> >
> > AJAX has raised awareness of the high potential of web applications, it has
> > encouraged companies to adopt rich web-based interfaces over traditional
> > "fat" clients, and it has spawned development activity to create toolkits
> > and abstractions to make AJAX-style development easier and more powerful.
> > This is an important trend for open source. The client itself can be
> > composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
> > Konqueror, and does not require any particular operating system, helping to
> > make a more level playing field for all development. More importantly,
> > AJAX is back-end agnostic as transactions are done over HTTP. Keeping the
> > client open forces vendors to keep the communication channel open as well,
> > and this can only continue as long as the client technology keeps pace with
> > proprietary alternatives. The open, standards based communications channel
> > is what drives many technologies inside Apache, so success of the open
> > client is vital to Apache. The mission of this project is to encourage
> > innovation around enterprise-strength client runtimes and tools and build a
> > community which can select and nurture a select set which will be most
> > beneficial to the web.
> >
> > 0.1 Criteria
> >
> > Meritocracy:
> >
> > Apache was chosen for an incubator primarily because of the guidance the
> > community can provide. The two subprojects put forth are among the first
> > attempts to formalize this style of development. Additional ideas, tools
> > or entire runtimes may come forward and indeed would be welcomed to the
> > project, either wholesale as new subprojects or incorporated into the
> > existing code.
> >
> > Community:
> >
> > The contributed work was inspired by open source development but needs a
> > strong and diverse community to validate its mission and carry it forward.
> > A primary objective of the project is to build a vibrant community of users
> > and active contributors.
> >
> > Core Developers:
> >
> > All of the initial committers are members of Zimbra and IBM development
> > teams. All developers have worked on open source projects before and have
> > experience and understanding of open source principles.
> >
> > Alignment:
> >
> > Initial implementation consists of two sub projects.
> >
> > The AJAX Toolkit Framework will provide a strategic framework for
> > Interactive Development Environments (IDEs) for the many different AJAX
> > toolkit offerings in the market. It provides a rich set of tools for the
> > AJAX / DHTML developer including: a JavaScript editor with edit-time syntax
> > checking; Mozilla web browser; integrated DOM browser; integrated
> > JavaScript debugger; and wizards and development aides tuned to specific
> > libraries and toolkits. The Framework is extensible to support other AJAX
> > toolkits and has a wizard-based tool to facilitate the integration of new
> > toolkits in the framework.
> >
> > The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> > JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
> > Plugin extensions to Eclipse. It embeds 4 other open source components:
> > Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> > 4 open source components specified. They are incorporated to accommodate
> > Eclipse plugin architecture and distributed as-is by repackaging them as
> > part of the AJAX Toolkit Framework.
> >
> > The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
> > framework, provides a rich client library, similar in style to traditional
> > object-oriented widget libraries like Eclipse's SWT. This toolkit hides
> > implementation details and browser quirks and makes web development more
> > accessible to the enterprise developer. It provides
> >
> > * User interface development
> > * Network communications (both synchronous and asynchronous)
> > * SOAP programming
> > * XML document creation and manipulation
> > * UI event handling and management
> >
> > For further information, please see the Zimbra AjaxTK whitepaper:
> > http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
> >
> > 0.2 Warning signs
> >
> > Orphaned products:
> >
> > The initial code submission is based on colloborative work between IBM and
> > Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> > environment and provide additional enhancements. Both the companies believe
> > that taking a joint approach and making it available through open source
> > will make it widely accepted and create a community and unify Industry
> > momentum to consolidate requirements and accelerate community growth and
> > enhance the toolkit to ease development of AJAX applications.
> >
> > Inexperience with open source:
> >
> > Both the companies and several of the commiters are very experienced in
> > Open Source environment. All efforts will be made to ensure that the work
> > done and momentum will be in strict adherence to open source guidelines.
> >
> > Homogenous developers:
> >
> > The current list of committers includes developers who are geographically
> > distributed. They are experienced with working in a distributed
> > environment, and with resolving technical differences.
> >
> > Reliance on salaried developers:
> >
> > All of the initial developers are paid by their employers to contribute to
> > this project and the employers track records for ongoing investment in open
> > source communities well known.
> >
> > No ties to other Apache products:
> >
> > The initial codebase will be licensed under the Apache License 2.0.The
> > dependencies on other external projects are defined in the alignment
> > section. While there are no direct build dependencies on other Apache
> > projects, the development of AJAX clients will often be driven by Apache
> > middleware and will have a positive impact on the open source movement as
> > described in the "Rationale" section.
> >
> > A fascination with the Apache brand:
> >
> > The committers are intent on developing a strong open source community. We
> > believe that the Apache Software Foundation's emphasis on community
> > development makes it the most suitable choice.
> >
> > 1. Scope of the subprojects
> >
> >
> > The subprojects will include development tools necessary to encourage
> > browser-based, AJAX-style development for individual users as well as in
> > the enterprise. The tools will be driven by an extensible IDE Framework
> > and may include utilities to assist in code development, analysis, and
> > testing. The tools will be adaptable to different AJAX runtimes, some of
> > which will also be subprojects in the incubator. The initial submission
> > includes an IDE and one such runtime.
> >
> > These initial projects are intended merely as starting points and should
> > not be taken as bounding the scope of the project as a whole. Some other
> > potential projects may include:
> >
> > * WYSIWYG tools for building AJAX-style interfaces
> > * Declarative grammars or abstractions for AJAX programming
> > * A common data model to facilitate efficient server communication with
> > Javascript or DOM access
> >
> > 2. Identify the initial source from which the subprojects are to be
> > populated
> >
> > AJAX Toolkit Framework was developed at IBM as a set of plugins based on
> > the Eclipse Framework and WebTools Project. Zip files containing snapshots
> > of CVS directories are provided with this proposal at
> > http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> > http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
> >
> > The Zimbra AjaxTK is available today in open source, and can be downloaded
> > as part of the Zimbra Collaboration Suite (choose the source code version)
> > at
> > http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> > toolkit code is provided at http://www.apache.org/~rubys/ajax/Ajax.tar.gz
> >
> > 2.1 External Dependencies of the project
> >
> > AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> > JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
> > Plugin extensions to Eclipse. It embeds four other open source components
> > Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> > four open source components specified. They are incorporated to accommodate
> > Eclipse plugin architecture and distributed as is by repackaging them as
> > part of AJAX Toolkit Framework. In the future any AJAX toolkit that is to
> > be supported can be included as another plugin.
> >
> > 3. Identify the ASF resources to be created
> >
> > 3.1 mailing list(s)
> >
> > * ajaxtk-ppmc
> > * ajaxtk-dev
> > * ajaxtk-commits
> > * ajaxtk-user
> >
> > 3.2 Subversion repository
> >
> > * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
> >
> > 3.3 Bugzilla
> >
> > * AJAXTK (AJAXTK)
> >
> > 4. Identify the initial set of committers:
> >
> > * Craig Becker
> > * Leugim Bustelo
> > * Andrew Clark
> > * Conrad Damon
> > * Ross Dargahi
> > * Becky Gibson
> > * Javier Pedemonte
> > * Adam Peller
> > * Roland Schemers
> > * Donald Sedota
> > * Parag Shah
> > * Greg Solovyev
> >
> > 5. Identify Apache sponsoring individual
> >
> > We request that the Apache Incubator PMC sponsor the AJAX Toolkit Framework
> > as an
> > incubating project, with the eventual goal of graduation as a TLP. The
> > initial contributors feel the scope of the project doesn't clearly
> > overlap with any existing TLP, and is broad enough to justify eventual
> > TLP status.
> >
> > Champion: Sam Ruby
> >
> > Mentors: ??
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
Cliff,
Sam has gone through the rationale on community, licensing, etc. On a technical level, I'd like to point out that while the tools subproject does use
Eclipse and the WebTools project, it attempts to do so through limited, well-known APIs. We've been working with the Eclipse team on defects and
enhancements to find the right APIs not just for our needs, but hopefully generic APIs for others to build extensions as well. Once these APIs and
extension points are finalized, hopefully Eclipse will be a stronger platform as a result, and we will be freer to focus on the functionality of AJAX
runtimes, integration with middleware, etc. So, while tools are an enabler and Eclipse is the platform for the tools subproject, I think the overall
mission is building a coherent set of AJAX code that fits in with existing middleware and standards, and a community to steer it. For that, we think
Apache is the right home.
-Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Cliff Schmidt <cl...@gmail.com>.
Adam,
Can you tell me if you considered proposing this to the Eclipse Foundation?
Since this project appears to have far stronger dependencies on
Eclipse Foundation projects rather than anything from Apache, can you
tell me why you think bringing this project here is likely to help you
build a stronger community than you would find at Eclipse? Is there
some other overriding reason you prefer to bring this project to
Apache?
Cliff
On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
> AJAX Toolkit Framework Proposal
>
> 0. Rationale
>
> While the term AJAX (Asynchronous Javascript and XML) has only recently
> been coined, the underlying web standards and technologies (JavaScript
> a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
> Although the term is used in a variety of ways, AJAX typically describes
> techniques towards developing interactive applications on the web client
> including asynchronous messaging, use of XML grammar in client-side
> applications, incremental page updates, and improved user interface
> controls. AJAX applications combine the rich UI experience of programmed
> clients with the low-cost lifecycle management of web-based applications.
>
> AJAX has raised awareness of the high potential of web applications, it has
> encouraged companies to adopt rich web-based interfaces over traditional
> "fat" clients, and it has spawned development activity to create toolkits
> and abstractions to make AJAX-style development easier and more powerful.
> This is an important trend for open source. The client itself can be
> composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
> Konqueror, and does not require any particular operating system, helping to
> make a more level playing field for all development. More importantly,
> AJAX is back-end agnostic as transactions are done over HTTP. Keeping the
> client open forces vendors to keep the communication channel open as well,
> and this can only continue as long as the client technology keeps pace with
> proprietary alternatives. The open, standards based communications channel
> is what drives many technologies inside Apache, so success of the open
> client is vital to Apache. The mission of this project is to encourage
> innovation around enterprise-strength client runtimes and tools and build a
> community which can select and nurture a select set which will be most
> beneficial to the web.
>
> 0.1 Criteria
>
> Meritocracy:
>
> Apache was chosen for an incubator primarily because of the guidance the
> community can provide. The two subprojects put forth are among the first
> attempts to formalize this style of development. Additional ideas, tools
> or entire runtimes may come forward and indeed would be welcomed to the
> project, either wholesale as new subprojects or incorporated into the
> existing code.
>
> Community:
>
> The contributed work was inspired by open source development but needs a
> strong and diverse community to validate its mission and carry it forward.
> A primary objective of the project is to build a vibrant community of users
> and active contributors.
>
> Core Developers:
>
> All of the initial committers are members of Zimbra and IBM development
> teams. All developers have worked on open source projects before and have
> experience and understanding of open source principles.
>
> Alignment:
>
> Initial implementation consists of two sub projects.
>
> The AJAX Toolkit Framework will provide a strategic framework for
> Interactive Development Environments (IDEs) for the many different AJAX
> toolkit offerings in the market. It provides a rich set of tools for the
> AJAX / DHTML developer including: a JavaScript editor with edit-time syntax
> checking; Mozilla web browser; integrated DOM browser; integrated
> JavaScript debugger; and wizards and development aides tuned to specific
> libraries and toolkits. The Framework is extensible to support other AJAX
> toolkits and has a wizard-based tool to facilitate the integration of new
> toolkits in the framework.
>
> The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
> Plugin extensions to Eclipse. It embeds 4 other open source components:
> Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> 4 open source components specified. They are incorporated to accommodate
> Eclipse plugin architecture and distributed as-is by repackaging them as
> part of the AJAX Toolkit Framework.
>
> The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
> framework, provides a rich client library, similar in style to traditional
> object-oriented widget libraries like Eclipse's SWT. This toolkit hides
> implementation details and browser quirks and makes web development more
> accessible to the enterprise developer. It provides
>
> * User interface development
> * Network communications (both synchronous and asynchronous)
> * SOAP programming
> * XML document creation and manipulation
> * UI event handling and management
>
> For further information, please see the Zimbra AjaxTK whitepaper:
> http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
>
> 0.2 Warning signs
>
> Orphaned products:
>
> The initial code submission is based on colloborative work between IBM and
> Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> environment and provide additional enhancements. Both the companies believe
> that taking a joint approach and making it available through open source
> will make it widely accepted and create a community and unify Industry
> momentum to consolidate requirements and accelerate community growth and
> enhance the toolkit to ease development of AJAX applications.
>
> Inexperience with open source:
>
> Both the companies and several of the commiters are very experienced in
> Open Source environment. All efforts will be made to ensure that the work
> done and momentum will be in strict adherence to open source guidelines.
>
> Homogenous developers:
>
> The current list of committers includes developers who are geographically
> distributed. They are experienced with working in a distributed
> environment, and with resolving technical differences.
>
> Reliance on salaried developers:
>
> All of the initial developers are paid by their employers to contribute to
> this project and the employers track records for ongoing investment in open
> source communities well known.
>
> No ties to other Apache products:
>
> The initial codebase will be licensed under the Apache License 2.0.The
> dependencies on other external projects are defined in the alignment
> section. While there are no direct build dependencies on other Apache
> projects, the development of AJAX clients will often be driven by Apache
> middleware and will have a positive impact on the open source movement as
> described in the "Rationale" section.
>
> A fascination with the Apache brand:
>
> The committers are intent on developing a strong open source community. We
> believe that the Apache Software Foundation's emphasis on community
> development makes it the most suitable choice.
>
> 1. Scope of the subprojects
>
>
> The subprojects will include development tools necessary to encourage
> browser-based, AJAX-style development for individual users as well as in
> the enterprise. The tools will be driven by an extensible IDE Framework
> and may include utilities to assist in code development, analysis, and
> testing. The tools will be adaptable to different AJAX runtimes, some of
> which will also be subprojects in the incubator. The initial submission
> includes an IDE and one such runtime.
>
> These initial projects are intended merely as starting points and should
> not be taken as bounding the scope of the project as a whole. Some other
> potential projects may include:
>
> * WYSIWYG tools for building AJAX-style interfaces
> * Declarative grammars or abstractions for AJAX programming
> * A common data model to facilitate efficient server communication with
> Javascript or DOM access
>
> 2. Identify the initial source from which the subprojects are to be
> populated
>
> AJAX Toolkit Framework was developed at IBM as a set of plugins based on
> the Eclipse Framework and WebTools Project. Zip files containing snapshots
> of CVS directories are provided with this proposal at
> http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
>
> The Zimbra AjaxTK is available today in open source, and can be downloaded
> as part of the Zimbra Collaboration Suite (choose the source code version)
> at
> http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> toolkit code is provided at http://www.apache.org/~rubys/ajax/Ajax.tar.gz
>
> 2.1 External Dependencies of the project
>
> AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set of
> Plugin extensions to Eclipse. It embeds four other open source components
> Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> four open source components specified. They are incorporated to accommodate
> Eclipse plugin architecture and distributed as is by repackaging them as
> part of AJAX Toolkit Framework. In the future any AJAX toolkit that is to
> be supported can be included as another plugin.
>
> 3. Identify the ASF resources to be created
>
> 3.1 mailing list(s)
>
> * ajaxtk-ppmc
> * ajaxtk-dev
> * ajaxtk-commits
> * ajaxtk-user
>
> 3.2 Subversion repository
>
> * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
>
> 3.3 Bugzilla
>
> * AJAXTK (AJAXTK)
>
> 4. Identify the initial set of committers:
>
> * Craig Becker
> * Leugim Bustelo
> * Andrew Clark
> * Conrad Damon
> * Ross Dargahi
> * Becky Gibson
> * Javier Pedemonte
> * Adam Peller
> * Roland Schemers
> * Donald Sedota
> * Parag Shah
> * Greg Solovyev
>
> 5. Identify Apache sponsoring individual
>
> We request that the Apache Incubator PMC sponsor the AJAX Toolkit Framework
> as an
> incubating project, with the eventual goal of graduation as a TLP. The
> initial contributors feel the scope of the project doesn't clearly
> overlap with any existing TLP, and is broad enough to justify eventual
> TLP status.
>
> Champion: Sam Ruby
>
> Mentors: ??
>
>
> ---------------------------------------------------------------------
> 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
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
Hi Martin.
Although I confess to know little about MyFaces, I'd imagine your AJAX
components could work well within our tooling environment and that custom
extensions to support them are possible. Out of the box (or with minimal
effort, at least) you should get some integrated JS support in JSPs, have
access to a debugger, snippets, and some other generic web tooling. What
other sorts of tooling on the client do you think might help the MyFaces
project?
Also, perhaps some cross-polination with other toolkits, such as Zimbra and
Rico, could prove helpful, whether code is used directly or if just some of
the patterns prove useful?
Regards,
Adam
Martin Marinschek
<martin.marinsche
k@gmail.com> To
general@incubator.apache.org
12/20/2005 09:54 cc
AM
Subject
Re: AJAX Toolkit Framework Proposal
Please respond to
general
I'm very interested in this.
Even though I am not an Apache member (so no potential mentor ;) I'd
be very interested in what this project means for the Apache
MyFaces-javascript and AJAX integration.
regards,
Martin
On 12/20/05, Paul Fremantle <pz...@gmail.com> wrote:
> Adam
>
> I offer to help mentor this.
>
> Paul
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
> >
> > AJAX Toolkit Framework Proposal
> >
> > 0. Rationale
> >
> > While the term AJAX (Asynchronous Javascript and XML) has only recently
> > been coined, the underlying web standards and technologies (JavaScript
> > a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for
years.
> > Although the term is used in a variety of ways, AJAX typically
describes
> > techniques towards developing interactive applications on the web
client
> > including asynchronous messaging, use of XML grammar in client-side
> > applications, incremental page updates, and improved user interface
> > controls. AJAX applications combine the rich UI experience of
programmed
> > clients with the low-cost lifecycle management of web-based
applications.
> >
> > AJAX has raised awareness of the high potential of web applications, it
> > has
> > encouraged companies to adopt rich web-based interfaces over
traditional
> > "fat" clients, and it has spawned development activity to create
toolkits
> > and abstractions to make AJAX-style development easier and more
powerful.
> > This is an important trend for open source. The client itself can be
> > composed entirely of open-source parts, such as Mozilla's Firefox or
KDE's
> > Konqueror, and does not require any particular operating system,
helping
> > to
> > make a more level playing field for all development. More importantly,
> > AJAX is back-end agnostic as transactions are done over HTTP. Keeping
the
> > client open forces vendors to keep the communication channel open as
well,
> > and this can only continue as long as the client technology keeps pace
> > with
> > proprietary alternatives. The open, standards based communications
> > channel
> > is what drives many technologies inside Apache, so success of the open
> > client is vital to Apache. The mission of this project is to encourage
> > innovation around enterprise-strength client runtimes and tools and
build
> > a
> > community which can select and nurture a select set which will be most
> > beneficial to the web.
> >
> > 0.1 Criteria
> >
> > Meritocracy:
> >
> > Apache was chosen for an incubator primarily because of the guidance
the
> > community can provide. The two subprojects put forth are among the
first
> > attempts to formalize this style of development. Additional ideas,
tools
> > or entire runtimes may come forward and indeed would be welcomed to the
> > project, either wholesale as new subprojects or incorporated into the
> > existing code.
> >
> > Community:
> >
> > The contributed work was inspired by open source development but needs
a
> > strong and diverse community to validate its mission and carry it
forward.
> > A primary objective of the project is to build a vibrant community of
> > users
> > and active contributors.
> >
> > Core Developers:
> >
> > All of the initial committers are members of Zimbra and IBM development
> > teams. All developers have worked on open source projects before and
have
> > experience and understanding of open source principles.
> >
> > Alignment:
> >
> > Initial implementation consists of two sub projects.
> >
> > The AJAX Toolkit Framework will provide a strategic framework for
> > Interactive Development Environments (IDEs) for the many different AJAX
> > toolkit offerings in the market. It provides a rich set of tools for
the
> > AJAX / DHTML developer including: a JavaScript editor with edit-time
> > syntax
> > checking; Mozilla web browser; integrated DOM browser; integrated
> > JavaScript debugger; and wizards and development aides tuned to
specific
> > libraries and toolkits. The Framework is extensible to support other
AJAX
> > toolkits and has a wizard-based tool to facilitate the integration of
new
> > toolkits in the framework.
> >
> > The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> > JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
set
> > of
> > Plugin extensions to Eclipse. It embeds 4 other open source components:
> > Rhino, JSLint, Rico and Zimbra. No code modifications will be made to
the
> > 4 open source components specified. They are incorporated to
accommodate
> > Eclipse plugin architecture and distributed as-is by repackaging them
as
> > part of the AJAX Toolkit Framework.
> >
> > The Zimbra AJAX Development Toolkit, the first toolkit integrated into
the
> > framework, provides a rich client library, similar in style to
traditional
> > object-oriented widget libraries like Eclipse's SWT. This toolkit
hides
> > implementation details and browser quirks and makes web development
more
> > accessible to the enterprise developer. It provides
> >
> > * User interface development
> > * Network communications (both synchronous and asynchronous)
> > * SOAP programming
> > * XML document creation and manipulation
> > * UI event handling and management
> >
> > For further information, please see the Zimbra AjaxTK whitepaper:
> > http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
> >
> > 0.2 Warning signs
> >
> > Orphaned products:
> >
> > The initial code submission is based on colloborative work between IBM
and
> > Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> > environment and provide additional enhancements. Both the companies
> > believe
> > that taking a joint approach and making it available through open
source
> > will make it widely accepted and create a community and unify Industry
> > momentum to consolidate requirements and accelerate community growth
and
> > enhance the toolkit to ease development of AJAX applications.
> >
> > Inexperience with open source:
> >
> > Both the companies and several of the commiters are very experienced in
> > Open Source environment. All efforts will be made to ensure that the
work
> > done and momentum will be in strict adherence to open source
guidelines.
> >
> > Homogenous developers:
> >
> > The current list of committers includes developers who are
geographically
> > distributed. They are experienced with working in a distributed
> > environment, and with resolving technical differences.
> >
> > Reliance on salaried developers:
> >
> > All of the initial developers are paid by their employers to contribute
to
> > this project and the employers track records for ongoing investment in
> > open
> > source communities well known.
> >
> > No ties to other Apache products:
> >
> > The initial codebase will be licensed under the Apache License 2.0.The
> > dependencies on other external projects are defined in the alignment
> > section. While there are no direct build dependencies on other Apache
> > projects, the development of AJAX clients will often be driven by
Apache
> > middleware and will have a positive impact on the open source movement
as
> > described in the "Rationale" section.
> >
> > A fascination with the Apache brand:
> >
> > The committers are intent on developing a strong open source community.
We
> > believe that the Apache Software Foundation's emphasis on community
> > development makes it the most suitable choice.
> >
> > 1. Scope of the subprojects
> >
> >
> > The subprojects will include development tools necessary to encourage
> > browser-based, AJAX-style development for individual users as well as
in
> > the enterprise. The tools will be driven by an extensible IDE
Framework
> > and may include utilities to assist in code development, analysis, and
> > testing. The tools will be adaptable to different AJAX runtimes, some
of
> > which will also be subprojects in the incubator. The initial
submission
> > includes an IDE and one such runtime.
> >
> > These initial projects are intended merely as starting points and
should
> > not be taken as bounding the scope of the project as a whole. Some
other
> > potential projects may include:
> >
> > * WYSIWYG tools for building AJAX-style interfaces
> > * Declarative grammars or abstractions for AJAX programming
> > * A common data model to facilitate efficient server communication with
> > Javascript or DOM access
> >
> > 2. Identify the initial source from which the subprojects are to be
> > populated
> >
> > AJAX Toolkit Framework was developed at IBM as a set of plugins based
on
> > the Eclipse Framework and WebTools Project. Zip files containing
> > snapshots
> > of CVS directories are provided with this proposal at
> > http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> > http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
> >
> > The Zimbra AjaxTK is available today in open source, and can be
downloaded
> > as part of the Zimbra Collaboration Suite (choose the source code
version)
> > at
> > http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> > toolkit code is provided at
http://www.apache.org/~rubys/ajax/Ajax.tar.gz
> >
> > 2.1 External Dependencies of the project
> >
> > AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> > JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
set
> > of
> > Plugin extensions to Eclipse. It embeds four other open source
components
> > Rhino, JSLint, Rico and Zimbra. No code modifications will be made to
the
> > four open source components specified. They are incorporated to
> > accommodate
> > Eclipse plugin architecture and distributed as is by repackaging them
as
> > part of AJAX Toolkit Framework. In the future any AJAX toolkit that is
to
> > be supported can be included as another plugin.
> >
> > 3. Identify the ASF resources to be created
> >
> > 3.1 mailing list(s)
> >
> > * ajaxtk-ppmc
> > * ajaxtk-dev
> > * ajaxtk-commits
> > * ajaxtk-user
> >
> > 3.2 Subversion repository
> >
> > * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
> >
> > 3.3 Bugzilla
> >
> > * AJAXTK (AJAXTK)
> >
> > 4. Identify the initial set of committers:
> >
> > * Craig Becker
> > * Leugim Bustelo
> > * Andrew Clark
> > * Conrad Damon
> > * Ross Dargahi
> > * Becky Gibson
> > * Javier Pedemonte
> > * Adam Peller
> > * Roland Schemers
> > * Donald Sedota
> > * Parag Shah
> > * Greg Solovyev
> >
> > 5. Identify Apache sponsoring individual
> >
> > We request that the Apache Incubator PMC sponsor the AJAX Toolkit
> > Framework
> > as an
> > incubating project, with the eventual goal of graduation as a TLP. The
> > initial contributors feel the scope of the project doesn't clearly
> > overlap with any existing TLP, and is broad enough to justify eventual
> > TLP status.
> >
> > Champion: Sam Ruby
> >
> > Mentors: ??
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
---------------------------------------------------------------------
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
Re: AJAX Toolkit Framework Proposal
Posted by Martin Marinschek <ma...@gmail.com>.
I'm very interested in this.
Even though I am not an Apache member (so no potential mentor ;) I'd
be very interested in what this project means for the Apache
MyFaces-javascript and AJAX integration.
regards,
Martin
On 12/20/05, Paul Fremantle <pz...@gmail.com> wrote:
> Adam
>
> I offer to help mentor this.
>
> Paul
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
> >
> > AJAX Toolkit Framework Proposal
> >
> > 0. Rationale
> >
> > While the term AJAX (Asynchronous Javascript and XML) has only recently
> > been coined, the underlying web standards and technologies (JavaScript
> > a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
> > Although the term is used in a variety of ways, AJAX typically describes
> > techniques towards developing interactive applications on the web client
> > including asynchronous messaging, use of XML grammar in client-side
> > applications, incremental page updates, and improved user interface
> > controls. AJAX applications combine the rich UI experience of programmed
> > clients with the low-cost lifecycle management of web-based applications.
> >
> > AJAX has raised awareness of the high potential of web applications, it
> > has
> > encouraged companies to adopt rich web-based interfaces over traditional
> > "fat" clients, and it has spawned development activity to create toolkits
> > and abstractions to make AJAX-style development easier and more powerful.
> > This is an important trend for open source. The client itself can be
> > composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
> > Konqueror, and does not require any particular operating system, helping
> > to
> > make a more level playing field for all development. More importantly,
> > AJAX is back-end agnostic as transactions are done over HTTP. Keeping the
> > client open forces vendors to keep the communication channel open as well,
> > and this can only continue as long as the client technology keeps pace
> > with
> > proprietary alternatives. The open, standards based communications
> > channel
> > is what drives many technologies inside Apache, so success of the open
> > client is vital to Apache. The mission of this project is to encourage
> > innovation around enterprise-strength client runtimes and tools and build
> > a
> > community which can select and nurture a select set which will be most
> > beneficial to the web.
> >
> > 0.1 Criteria
> >
> > Meritocracy:
> >
> > Apache was chosen for an incubator primarily because of the guidance the
> > community can provide. The two subprojects put forth are among the first
> > attempts to formalize this style of development. Additional ideas, tools
> > or entire runtimes may come forward and indeed would be welcomed to the
> > project, either wholesale as new subprojects or incorporated into the
> > existing code.
> >
> > Community:
> >
> > The contributed work was inspired by open source development but needs a
> > strong and diverse community to validate its mission and carry it forward.
> > A primary objective of the project is to build a vibrant community of
> > users
> > and active contributors.
> >
> > Core Developers:
> >
> > All of the initial committers are members of Zimbra and IBM development
> > teams. All developers have worked on open source projects before and have
> > experience and understanding of open source principles.
> >
> > Alignment:
> >
> > Initial implementation consists of two sub projects.
> >
> > The AJAX Toolkit Framework will provide a strategic framework for
> > Interactive Development Environments (IDEs) for the many different AJAX
> > toolkit offerings in the market. It provides a rich set of tools for the
> > AJAX / DHTML developer including: a JavaScript editor with edit-time
> > syntax
> > checking; Mozilla web browser; integrated DOM browser; integrated
> > JavaScript debugger; and wizards and development aides tuned to specific
> > libraries and toolkits. The Framework is extensible to support other AJAX
> > toolkits and has a wizard-based tool to facilitate the integration of new
> > toolkits in the framework.
> >
> > The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> > JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set
> > of
> > Plugin extensions to Eclipse. It embeds 4 other open source components:
> > Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> > 4 open source components specified. They are incorporated to accommodate
> > Eclipse plugin architecture and distributed as-is by repackaging them as
> > part of the AJAX Toolkit Framework.
> >
> > The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
> > framework, provides a rich client library, similar in style to traditional
> > object-oriented widget libraries like Eclipse's SWT. This toolkit hides
> > implementation details and browser quirks and makes web development more
> > accessible to the enterprise developer. It provides
> >
> > * User interface development
> > * Network communications (both synchronous and asynchronous)
> > * SOAP programming
> > * XML document creation and manipulation
> > * UI event handling and management
> >
> > For further information, please see the Zimbra AjaxTK whitepaper:
> > http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
> >
> > 0.2 Warning signs
> >
> > Orphaned products:
> >
> > The initial code submission is based on colloborative work between IBM and
> > Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> > environment and provide additional enhancements. Both the companies
> > believe
> > that taking a joint approach and making it available through open source
> > will make it widely accepted and create a community and unify Industry
> > momentum to consolidate requirements and accelerate community growth and
> > enhance the toolkit to ease development of AJAX applications.
> >
> > Inexperience with open source:
> >
> > Both the companies and several of the commiters are very experienced in
> > Open Source environment. All efforts will be made to ensure that the work
> > done and momentum will be in strict adherence to open source guidelines.
> >
> > Homogenous developers:
> >
> > The current list of committers includes developers who are geographically
> > distributed. They are experienced with working in a distributed
> > environment, and with resolving technical differences.
> >
> > Reliance on salaried developers:
> >
> > All of the initial developers are paid by their employers to contribute to
> > this project and the employers track records for ongoing investment in
> > open
> > source communities well known.
> >
> > No ties to other Apache products:
> >
> > The initial codebase will be licensed under the Apache License 2.0.The
> > dependencies on other external projects are defined in the alignment
> > section. While there are no direct build dependencies on other Apache
> > projects, the development of AJAX clients will often be driven by Apache
> > middleware and will have a positive impact on the open source movement as
> > described in the "Rationale" section.
> >
> > A fascination with the Apache brand:
> >
> > The committers are intent on developing a strong open source community. We
> > believe that the Apache Software Foundation's emphasis on community
> > development makes it the most suitable choice.
> >
> > 1. Scope of the subprojects
> >
> >
> > The subprojects will include development tools necessary to encourage
> > browser-based, AJAX-style development for individual users as well as in
> > the enterprise. The tools will be driven by an extensible IDE Framework
> > and may include utilities to assist in code development, analysis, and
> > testing. The tools will be adaptable to different AJAX runtimes, some of
> > which will also be subprojects in the incubator. The initial submission
> > includes an IDE and one such runtime.
> >
> > These initial projects are intended merely as starting points and should
> > not be taken as bounding the scope of the project as a whole. Some other
> > potential projects may include:
> >
> > * WYSIWYG tools for building AJAX-style interfaces
> > * Declarative grammars or abstractions for AJAX programming
> > * A common data model to facilitate efficient server communication with
> > Javascript or DOM access
> >
> > 2. Identify the initial source from which the subprojects are to be
> > populated
> >
> > AJAX Toolkit Framework was developed at IBM as a set of plugins based on
> > the Eclipse Framework and WebTools Project. Zip files containing
> > snapshots
> > of CVS directories are provided with this proposal at
> > http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> > http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
> >
> > The Zimbra AjaxTK is available today in open source, and can be downloaded
> > as part of the Zimbra Collaboration Suite (choose the source code version)
> > at
> > http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> > toolkit code is provided at http://www.apache.org/~rubys/ajax/Ajax.tar.gz
> >
> > 2.1 External Dependencies of the project
> >
> > AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> > JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set
> > of
> > Plugin extensions to Eclipse. It embeds four other open source components
> > Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> > four open source components specified. They are incorporated to
> > accommodate
> > Eclipse plugin architecture and distributed as is by repackaging them as
> > part of AJAX Toolkit Framework. In the future any AJAX toolkit that is to
> > be supported can be included as another plugin.
> >
> > 3. Identify the ASF resources to be created
> >
> > 3.1 mailing list(s)
> >
> > * ajaxtk-ppmc
> > * ajaxtk-dev
> > * ajaxtk-commits
> > * ajaxtk-user
> >
> > 3.2 Subversion repository
> >
> > * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
> >
> > 3.3 Bugzilla
> >
> > * AJAXTK (AJAXTK)
> >
> > 4. Identify the initial set of committers:
> >
> > * Craig Becker
> > * Leugim Bustelo
> > * Andrew Clark
> > * Conrad Damon
> > * Ross Dargahi
> > * Becky Gibson
> > * Javier Pedemonte
> > * Adam Peller
> > * Roland Schemers
> > * Donald Sedota
> > * Parag Shah
> > * Greg Solovyev
> >
> > 5. Identify Apache sponsoring individual
> >
> > We request that the Apache Incubator PMC sponsor the AJAX Toolkit
> > Framework
> > as an
> > incubating project, with the eventual goal of graduation as a TLP. The
> > initial contributors feel the scope of the project doesn't clearly
> > overlap with any existing TLP, and is broad enough to justify eventual
> > TLP status.
> >
> > Champion: Sam Ruby
> >
> > Mentors: ??
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Paul Fremantle <pz...@gmail.com>.
Adam
I offer to help mentor this.
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
On 12/20/05, Adam Peller <ap...@us.ibm.com> wrote:
>
> AJAX Toolkit Framework Proposal
>
> 0. Rationale
>
> While the term AJAX (Asynchronous Javascript and XML) has only recently
> been coined, the underlying web standards and technologies (JavaScript
> a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for years.
> Although the term is used in a variety of ways, AJAX typically describes
> techniques towards developing interactive applications on the web client
> including asynchronous messaging, use of XML grammar in client-side
> applications, incremental page updates, and improved user interface
> controls. AJAX applications combine the rich UI experience of programmed
> clients with the low-cost lifecycle management of web-based applications.
>
> AJAX has raised awareness of the high potential of web applications, it
> has
> encouraged companies to adopt rich web-based interfaces over traditional
> "fat" clients, and it has spawned development activity to create toolkits
> and abstractions to make AJAX-style development easier and more powerful.
> This is an important trend for open source. The client itself can be
> composed entirely of open-source parts, such as Mozilla's Firefox or KDE's
> Konqueror, and does not require any particular operating system, helping
> to
> make a more level playing field for all development. More importantly,
> AJAX is back-end agnostic as transactions are done over HTTP. Keeping the
> client open forces vendors to keep the communication channel open as well,
> and this can only continue as long as the client technology keeps pace
> with
> proprietary alternatives. The open, standards based communications
> channel
> is what drives many technologies inside Apache, so success of the open
> client is vital to Apache. The mission of this project is to encourage
> innovation around enterprise-strength client runtimes and tools and build
> a
> community which can select and nurture a select set which will be most
> beneficial to the web.
>
> 0.1 Criteria
>
> Meritocracy:
>
> Apache was chosen for an incubator primarily because of the guidance the
> community can provide. The two subprojects put forth are among the first
> attempts to formalize this style of development. Additional ideas, tools
> or entire runtimes may come forward and indeed would be welcomed to the
> project, either wholesale as new subprojects or incorporated into the
> existing code.
>
> Community:
>
> The contributed work was inspired by open source development but needs a
> strong and diverse community to validate its mission and carry it forward.
> A primary objective of the project is to build a vibrant community of
> users
> and active contributors.
>
> Core Developers:
>
> All of the initial committers are members of Zimbra and IBM development
> teams. All developers have worked on open source projects before and have
> experience and understanding of open source principles.
>
> Alignment:
>
> Initial implementation consists of two sub projects.
>
> The AJAX Toolkit Framework will provide a strategic framework for
> Interactive Development Environments (IDEs) for the many different AJAX
> toolkit offerings in the market. It provides a rich set of tools for the
> AJAX / DHTML developer including: a JavaScript editor with edit-time
> syntax
> checking; Mozilla web browser; integrated DOM browser; integrated
> JavaScript debugger; and wizards and development aides tuned to specific
> libraries and toolkits. The Framework is extensible to support other AJAX
> toolkits and has a wizard-based tool to facilitate the integration of new
> toolkits in the framework.
>
> The AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set
> of
> Plugin extensions to Eclipse. It embeds 4 other open source components:
> Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> 4 open source components specified. They are incorporated to accommodate
> Eclipse plugin architecture and distributed as-is by repackaging them as
> part of the AJAX Toolkit Framework.
>
> The Zimbra AJAX Development Toolkit, the first toolkit integrated into the
> framework, provides a rich client library, similar in style to traditional
> object-oriented widget libraries like Eclipse's SWT. This toolkit hides
> implementation details and browser quirks and makes web development more
> accessible to the enterprise developer. It provides
>
> * User interface development
> * Network communications (both synchronous and asynchronous)
> * SOAP programming
> * XML document creation and manipulation
> * UI event handling and management
>
> For further information, please see the Zimbra AjaxTK whitepaper:
> http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
>
> 0.2 Warning signs
>
> Orphaned products:
>
> The initial code submission is based on colloborative work between IBM and
> Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> environment and provide additional enhancements. Both the companies
> believe
> that taking a joint approach and making it available through open source
> will make it widely accepted and create a community and unify Industry
> momentum to consolidate requirements and accelerate community growth and
> enhance the toolkit to ease development of AJAX applications.
>
> Inexperience with open source:
>
> Both the companies and several of the commiters are very experienced in
> Open Source environment. All efforts will be made to ensure that the work
> done and momentum will be in strict adherence to open source guidelines.
>
> Homogenous developers:
>
> The current list of committers includes developers who are geographically
> distributed. They are experienced with working in a distributed
> environment, and with resolving technical differences.
>
> Reliance on salaried developers:
>
> All of the initial developers are paid by their employers to contribute to
> this project and the employers track records for ongoing investment in
> open
> source communities well known.
>
> No ties to other Apache products:
>
> The initial codebase will be licensed under the Apache License 2.0.The
> dependencies on other external projects are defined in the alignment
> section. While there are no direct build dependencies on other Apache
> projects, the development of AJAX clients will often be driven by Apache
> middleware and will have a positive impact on the open source movement as
> described in the "Rationale" section.
>
> A fascination with the Apache brand:
>
> The committers are intent on developing a strong open source community. We
> believe that the Apache Software Foundation's emphasis on community
> development makes it the most suitable choice.
>
> 1. Scope of the subprojects
>
>
> The subprojects will include development tools necessary to encourage
> browser-based, AJAX-style development for individual users as well as in
> the enterprise. The tools will be driven by an extensible IDE Framework
> and may include utilities to assist in code development, analysis, and
> testing. The tools will be adaptable to different AJAX runtimes, some of
> which will also be subprojects in the incubator. The initial submission
> includes an IDE and one such runtime.
>
> These initial projects are intended merely as starting points and should
> not be taken as bounding the scope of the project as a whole. Some other
> potential projects may include:
>
> * WYSIWYG tools for building AJAX-style interfaces
> * Declarative grammars or abstractions for AJAX programming
> * A common data model to facilitate efficient server communication with
> Javascript or DOM access
>
> 2. Identify the initial source from which the subprojects are to be
> populated
>
> AJAX Toolkit Framework was developed at IBM as a set of plugins based on
> the Eclipse Framework and WebTools Project. Zip files containing
> snapshots
> of CVS directories are provided with this proposal at
> http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
>
> The Zimbra AjaxTK is available today in open source, and can be downloaded
> as part of the Zimbra Collaboration Suite (choose the source code version)
> at
> http://www.zimbra.com/community/downloads.php. A snapshot of the AJAX
> toolkit code is provided at http://www.apache.org/~rubys/ajax/Ajax.tar.gz
>
> 2.1 External Dependencies of the project
>
> AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a set
> of
> Plugin extensions to Eclipse. It embeds four other open source components
> Rhino, JSLint, Rico and Zimbra. No code modifications will be made to the
> four open source components specified. They are incorporated to
> accommodate
> Eclipse plugin architecture and distributed as is by repackaging them as
> part of AJAX Toolkit Framework. In the future any AJAX toolkit that is to
> be supported can be included as another plugin.
>
> 3. Identify the ASF resources to be created
>
> 3.1 mailing list(s)
>
> * ajaxtk-ppmc
> * ajaxtk-dev
> * ajaxtk-commits
> * ajaxtk-user
>
> 3.2 Subversion repository
>
> * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
>
> 3.3 Bugzilla
>
> * AJAXTK (AJAXTK)
>
> 4. Identify the initial set of committers:
>
> * Craig Becker
> * Leugim Bustelo
> * Andrew Clark
> * Conrad Damon
> * Ross Dargahi
> * Becky Gibson
> * Javier Pedemonte
> * Adam Peller
> * Roland Schemers
> * Donald Sedota
> * Parag Shah
> * Greg Solovyev
>
> 5. Identify Apache sponsoring individual
>
> We request that the Apache Incubator PMC sponsor the AJAX Toolkit
> Framework
> as an
> incubating project, with the eventual goal of graduation as a TLP. The
> initial contributors feel the scope of the project doesn't clearly
> overlap with any existing TLP, and is broad enough to justify eventual
> TLP status.
>
> Champion: Sam Ruby
>
> Mentors: ??
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: AJAX Toolkit Framework Proposal
Posted by Mike Milinkovich <mi...@eclipse.org>.
> Big assumption right there. I'll assert there's a reasonable
> chance I understand what's under the hood of the Eclipse
> platform quite well. IIRC I helped the Equinox people decide
> on what to put in there at some point...
Mea culpa. I was reacting to the comment about the "heavyweight IDE". We
often battle some misperceptions of the Eclipse technology stack, so it has
become a bit of a reflex. My apologies.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Leo Simons <ma...@leosimons.com>.
Mike, dude...
On Tue, Dec 20, 2005 at 10:32:25PM -0500, Mike Milinkovich wrote:
> > Hmm. I think your email is more puzzling to me than the
> > original proposal :-) (A heavyweight java-based IDE for doing
> > what's essentially designed as "lightweight" stuff...
>
> It seems that your understanding of the Eclipse platform needs some
> updating.
Big assumption right there. I'll assert there's a reasonable chance I understand
what's under the hood of the Eclipse platform quite well. IIRC I helped the
Equinox people decide on what to put in there at some point...
Alas, that's not what 99% of the post was about. Taking the expertise of one of
the posters to this mailing list in question on the second mail you send is curious,
but disregarding most of the other stuff being said is, again, much more puzzling.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sylvain Wallez <sy...@apache.org>.
Leo Simons wrote:
> On Tue, Dec 20, 2005 at 04:14:22PM +0100, Sylvain Wallez wrote:
>
>> I'm quite puzzled by this proposal. As I understand it, its mainly about
>> a set of Eclipse plugins for Ajax applications and the Zimbra library
>> that, among other features, provides a set of SWT-like widgets.
>>
>
> How is that puzzling?
>
Because the proposal mixes two different concerns, the runtime and the
IDE (see the "subproject" and "no tie in" discussion) and because
generic tooling is something unusual at the ASF.
>> So the questions are:
>> - is the ASF the place for Eclipse extensions? I don't deny the ability to _existing_ project to host their tooling, but this isn't the case here.
>>
>
> IMHO that's a very valid question to which the current answer from the incubator is "yes, if there's sufficient interest from existing ASF members" with "sufficient" somewhat under discussion. I'll suggest that changing the answer to that question should be tackled independently of this proposal.
>
> IANAL. But from talking with Cliff at AC it seems there's not neccessarily a licensing barrier either.
>
That's not a licensing question, but more a general OSS community
question. The ASF isn't alone in the OSS world, and there has been some
recent precedents where incubating projects have made other OSS
organizations uncomfortable. I don't say the OSS world should be
technically partitioned (e.g. server-side at Apache and IDE at Eclipse),
but that we should at least try to play nice with other organizations
and coordinate our activities.
Back in August, Cliff proposed a few modifications [1] to the incubation
proposal process, and IMO the current proposal shows how much these
modifications are needed.
>> - why incubate an Ajax library that none of the current ASF projects
>> uses nor plans to use, unless I missed something?
>>
>
> for all the usual reasons. "ties with existing ASF projects" is a question
> we sometimes ask but the rationale for even asking the question has never
> been written down in an email before (I think). I think what you're "missing"
> is 2 years of history in how we're doing incubation (which often involves
> "stuff that no existing ASF project uses or plans to use" when incubation
> started, like, ehm, Harmony, or Geronimo, or SpamAssassin, or ...)
>
> (...)
>
See my answer to Sam: the current proposal is very different from
SpamAssassin or Harmony.
> I personally feel that wanting to draw projects into the ASF *just* because
> other ASF projects want to use that stuff is Pretty Bad(tm). It should be
> easy and accepted and encouraged for ASF projects to use stuff that lives
> and breathes outside of the ASF if you ask me.
>
Sure, and that's what many projects actually do (and you know how many
external dependencies Cocoon has!). Now I don't see why it is bad to
propose to an external project to join the ASF, to ensure more
visibility and long-term sustainability when that external project
already has a lots of merits and is used by several ASF projects.
This is a win-win situation: we help the growth and healthiness of the
external project, and by doing that we solidify the foundations on which
our own projects are built.
> (...)
>
> Hmm. I think your email is more puzzling to me than the original proposal :-)
> (A heavyweight java-based IDE for doing what's essentially designed as
> "lightweight" stuff...it seems easier to just fix the embed-java-in-the-
> browser problem, like Stefano is doing with Piggy Bank...oh well...)
>
Hehe, this comment actually shows how confusing the proposal is: it's
not about embedding fat clients in the browser, but about on one side a
general-purpose IDE and on the other side a specific client-side library.
Sylvain
[1] http://tinyurl.com/bfaoy
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 20, 2005, at 10:32 PM, Mike Milinkovich wrote:
>
> It's rather like saying what the heck is the Apache web server
> doing with a
> JVM project?
I say that about once a week these days ;)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: AJAX Toolkit Framework Proposal
Posted by Mike Milinkovich <mi...@eclipse.org>.
> Hmm. I think your email is more puzzling to me than the
> original proposal :-) (A heavyweight java-based IDE for doing
> what's essentially designed as "lightweight" stuff...
Leo,
It seems that your understanding of the Eclipse platform needs some
updating. The Java IDE is definitely what we're best known for. But
underneath that IDE there beats the heart of a lightweight, OSGi-compliant
component system.
It's rather like saying what the heck is the Apache web server doing with a
JVM project? Similar to Apache, at Eclipse there is the original namesake
project, which has matured to a community with a significant number (50++)
of different projects.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Leo Simons <ma...@leosimons.com>.
On Tue, Dec 20, 2005 at 04:14:22PM +0100, Sylvain Wallez wrote:
> I'm quite puzzled by this proposal. As I understand it, its mainly about
> a set of Eclipse plugins for Ajax applications and the Zimbra library
> that, among other features, provides a set of SWT-like widgets.
How is that puzzling?
> Also, this proposal pops up right after I mention on members@ that
> several projects at Apache are using or plan to use Dojo [1] and that we
> talked about inviting them. I sincerely hope this is just a coincidence.
Why? Even though it seems to be (and is likely to be since the proposal
looks like it took some preparing), why would lack of coincidence between
these events neccessarily be bad? If Sam were to have mentioned to the
guys working on this proposal something along the lines of "dudes. Several
ASF peeps seem to be getting more interested in AJAX stuff. You should
hurry up a bit with that proposal of yours" that would've pretty much made
sense to me. Note: Sam specifically said he did not say something like that
at all.
> So the questions are:
> - is the ASF the place for Eclipse extensions? I don't deny the ability
> to _existing_ project to host their tooling, but this isn't the case here.
IMHO that's a very valid question to which the current answer from the
incubator is "yes, if there's sufficient interest from existing ASF
members" with "sufficient" somewhat under discussion. I'll suggest that
changing the answer to that question should be tackled independently of
this proposal.
IANAL. But from talking with Cliff at AC it seems there's not neccessarily
a licensing barrier either.
> - why incubate an Ajax library that none of the current ASF projects
> uses nor plans to use, unless I missed something?
for all the usual reasons. "ties with existing ASF projects" is a question
we sometimes ask but the rationale for even asking the question has never
been written down in an email before (I think). I think what you're "missing"
is 2 years of history in how we're doing incubation (which often involves
"stuff that no existing ASF project uses or plans to use" when incubation
started, like, ehm, Harmony, or Geronimo, or SpamAssassin, or ...)
(...)
I personally feel that wanting to draw projects into the ASF *just* because
other ASF projects want to use that stuff is Pretty Bad(tm). It should be
easy and accepted and encouraged for ASF projects to use stuff that lives
and breathes outside of the ASF if you ask me.
(...)
Hmm. I think your email is more puzzling to me than the original proposal :-)
(A heavyweight java-based IDE for doing what's essentially designed as
"lightweight" stuff...it seems easier to just fix the embed-java-in-the-
browser problem, like Stefano is doing with Piggy Bank...oh well...)
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sam Ruby <ru...@apache.org>.
Craig McClanahan wrote:
>
> The Zimbra part of the proposal could, I suppose, be held to aim at that
> goal. If you believe proposing an Eclipse-only tooling story (apparently to
> the exlusion of at least some folks in the Eclipse Foundation :-) forwards
> this goal, I would suggest taking this part of the proposal back for some
> serious editing.
Please read Adam's email that predated yours by a full 2.5 hours.
In any case, if you would like to participate in this project on a
technical level, you would be more than welcome.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Craig McClanahan <cr...@apache.org>.
On 12/21/05, Sam Ruby <ru...@apache.org> wrote:
>
> Craig McClanahan wrote:
> >
> >>From a software engineering viewpoint, focusing on a single tool
>
> Have you any other tools in mind? Bring them on!
Actually, I don't -- tooling-specific adaptations of generic technologies
seem best fitted to the corresponding tool development communitiies, with
participation from all relevant parties in the generic technology
development discussions.
Apparently, neither do you, or this proposal would have made this explicit,
and you'd have had representatives of other tooling folks directly involved,
rather than being totally focused on Eclipse plugins and SWT
implementations.
Once again, let me state that the goal is to seed a non-exclusive AJAX
> community at the ASF.
The Zimbra part of the proposal could, I suppose, be held to aim at that
goal. If you believe proposing an Eclipse-only tooling story (apparently to
the exlusion of at least some folks in the Eclipse Foundation :-) forwards
this goal, I would suggest taking this part of the proposal back for some
serious editing.
Craig
Re: AJAX Toolkit Framework Proposal
Posted by Sam Ruby <ru...@apache.org>.
Craig McClanahan wrote:
>
>>>From a software engineering viewpoint, focusing on a single tool
Have you any other tools in mind? Bring them on!
Once again, let me state that the goal is to seed a non-exclusive AJAX
community at the ASF.
In case it isn't perfectly clear: including Zimbra isn't intended to
exclude Dojo. Including Eclipse, doesn't mean to exclude NetBeans. As
Dims has pointed out, including IDE plugins is not new ground at the ASF.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
Craig,
Sam addressed the social engineering viewpoint; I'd like to talk about the
software side:
> Craig McClanahan wrote:
>>From a software engineering viewpoint, focusing on a single tool as a
>delivery vehicle will tend to bias architectural and implementation
>decisions towards what is easy to express in that particular tool.
I think Sam already mentioned that the Eclipse-based tooling is just our
contribution. And while we'd try to make that as robust and extensible as
possible, we would be by no means limited to one tool. If that isn't clear
in the proposal, we should fix it. (Eclipse is a delivery vehicle for the
tooling only, btw -- the browser is the delivery vehicle for the
applications developed) You've got to start somewhere. Some of the
proposed tooling might be independent of Eclipse, and possibly even
independent of the various AJAX runtimes. As for what we've done in
Eclipse so far, we're trying our best to keep it platform neutral.
Mozilla, embedded in our tooling, is really the container you're developing
in, and even there we hope to offer browser choice; we just chose Mozilla
as a starting point because it's ubiquitous, offers excellent integration
points, is open source, etc. Isn't it really the browser choice which can
introduce bias? (the very problem AJAX toolkits try to address?) Certain
conveniences or widgetry in the tool itself might be geared towards what
Eclipse supports, but I'd hope that Eclipse would not impact the
applications you would develop. I'll have to think about this some more.
If you have any examples, I'd very much like to hear them.
-Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Craig McClanahan <cr...@apache.org>.
On 12/20/05, Sam Ruby <ru...@apache.org> wrote:
>
> Sylvain Wallez wrote:
> > Adam Peller wrote:
> [snip]
> > So the questions are:
> > - is the ASF the place for Eclipse extensions? I don't deny the ability
> > to _existing_ project to host their tooling, but this isn't the case
> here.
>
> As I mentioned, I was involved with these discussions. The ASF doesn't
> tend to make these types of decisions based on the technical aspects of
> a project. What impressed me about the people who were proposing this
> is that they were sincerely interested in the Apache License and
> collaboration model.
Belief in the Apache collaborative development model should certainly be a
prerequisite for acceptance into the Apache community (to me, that's the
thing that binds ASF as a community more strongly than anything else). But
that, by itself, is not a compelling argument for combining these two
particular subprojects into a single proposal. That strikes me as bad
software engineering, as well as bad social engineering.
>From a software engineering viewpoint, focusing on a single tool as a
delivery vehicle will tend to bias architectural and implementation
decisions towards what is easy to express in that particular tool. It would
leave aside the little detail that not everyone interested in AJAX will be
using that tool, or will even be using Java. I'd like to see the various
AJAX libraries, and the communities around them collaborate more ... but
that problem space is plenty big enough without figuring out bindings to
tool widgets, for a particular platform, at the same time.
>From a social engineering viewpoint, this particular combination of
subprojects would create a perception that Apache's support for AJAX is all
about what you can do in Eclipse. That's too limiting a scope for what we
should be trying to achieve. A better answer might be to separate the
tooling aspects from the framework aspects, and consider building a
community around "tools for building AJAX based applications" in general,
that consumes this technology but unoubtedly others as well, rather than
trying to combine oil and water in the same project.
Craig
Re: AJAX Toolkit Framework Proposal
Posted by robert burrell donkin <ro...@gmail.com>.
On 12/21/05, Ted Leung <tw...@sauria.com> wrote:
>
> On Dec 20, 2005, at 12:19 PM, Sylvain Wallez wrote:
>
> > Sam Ruby wrote:
> >> Sylvain Wallez wrote:
> >>
> >> As a general rule, the ASF doesn't go out "inviting", people
> >> within the ASF either start a new project, or projects come to us.
> >
> > You're playing with words. Sure, there's no formal invitation
> > process. Now ASF members can approach projects they find
> > interesting and "suggest them to submit a proposal to the ASF", for
> > the greatest benefit of both the coming and existing ASF projects.
> >
> > Thinking more about it, the fact that the ASF isn't supposed to
> > invite projects seems to go against the ASF meritocratic rules. You
> > should not ask for being a committer: you are voted in when other
> > committers consider you deserve it. And you can reject the offer.
> > Same for membership. Why couldn't it also apply to projects that
> > already follow the Apache way and are of interest to the
> > Foundation's projects?
> >
> > On the other hand, proposals like this one, originating from
> > commercial entities, really look to me as "pushing the ASF door
> > open", even if the incubator is supposed to ensure community
> > diversity and healthiness before graduating as a real project.
>
> If we don't invite projects then we become driven by the projects
> that come to us, which have been overwhelmingly sponsored by
> corporate interests. Saying we don't have an agenda is really
> saying that we're happy to accept someone else's agenda, which I am
> certainly not happy with.
one reason for not issuing formal invitations from the ASF is that
we'd need to create enough process to ensure this happens with
oversight and so on.
IMHO informal negotiations lead by interested members would be a
better approach. this is allowed ATM but perhaps isn't working too
well right now or maybe just takes longer...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Ted Leung <tw...@sauria.com>.
On Dec 20, 2005, at 12:19 PM, Sylvain Wallez wrote:
> Sam Ruby wrote:
>> Sylvain Wallez wrote:
>>
>> As a general rule, the ASF doesn't go out "inviting", people
>> within the ASF either start a new project, or projects come to us.
>
> You're playing with words. Sure, there's no formal invitation
> process. Now ASF members can approach projects they find
> interesting and "suggest them to submit a proposal to the ASF", for
> the greatest benefit of both the coming and existing ASF projects.
>
> Thinking more about it, the fact that the ASF isn't supposed to
> invite projects seems to go against the ASF meritocratic rules. You
> should not ask for being a committer: you are voted in when other
> committers consider you deserve it. And you can reject the offer.
> Same for membership. Why couldn't it also apply to projects that
> already follow the Apache way and are of interest to the
> Foundation's projects?
>
> On the other hand, proposals like this one, originating from
> commercial entities, really look to me as "pushing the ASF door
> open", even if the incubator is supposed to ensure community
> diversity and healthiness before graduating as a real project.
If we don't invite projects then we become driven by the projects
that come to us, which have been overwhelmingly sponsored by
corporate interests. Saying we don't have an agenda is really
saying that we're happy to accept someone else's agenda, which I am
certainly not happy with.
Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sylvain Wallez wrote:
>>> - why incubate an Ajax library that none of the current ASF projects
>>> uses nor plans to use, unless I missed something?
>>
>> It is a valid question, but it is also valid to point out that the
>> ASF has projects as diverse as TCL and SpamAssassin.
>
> The situation is very different here: several projects are integrating
> Ajax features and incidentally found that they were considering the
> same framework for that purpoe. Whereas none of the ASF projects was
> already envisioning close integration with a spam filter when
> SpamAssassin came to Apache.
>
> That could even end up with the funny (ahem) situation where Apache
> has an Ajax framework that isn't used by its Ajax-enabled server-side
> frameworks. Doesn't it sound weird?
>
I don't think this is weird at all. This may be off topic (or missing
the point), but why do the ASF projects have to be one coherent product
suite? Do they have to all tie together? Sure tie-ins are great, but
not everything needs to be related or play nice together. We have plenty
of examples of competing projects (see struts, beehive, turbine,
tapestry, etc).
I think Sam summed it up great when he said:
>> What is more important is considerations that the code be licensed
>> with the Apache Software License (not dual licensed, like Dojo), that
>> the committer bases be diverse, and operate in an open and
>> collaborative model.
I think this is right on with the ASF philosophy [1]:
"""
While there is not an official list, these six principles have been
cited as the core beliefs of philosophy behind the foundation, which is
normally referred to as "The Apache Way":
* collaborative software development
* commercial-friendly standard license
* consistently high quality software
* respectful, honest, technical-based interaction
* faithful implementation of standards
* security as a mandatory feature
""""
I think there is a space for any and all projects that meet the above
criteria.
Cheers,
- Dan
1. http://www.apache.org/foundation/how-it-works.html#management
--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sylvain Wallez <sy...@apache.org>.
Sam Ruby wrote:
> Sylvain Wallez wrote:
>> Adam Peller wrote:
>>
>>> AJAX Toolkit Framework Proposal
>>
>> I'm quite puzzled by this proposal. As I understand it, its mainly
>> about a set of Eclipse plugins for Ajax applications and the Zimbra
>> library that, among other features, provides a set of SWT-like widgets.
>
> Yes.
>
>> Also, this proposal pops up right after I mention on members@ that
>> several projects at Apache are using or plan to use Dojo [1] and that
>> we talked about inviting them. I sincerely hope this is just a
>> coincidence.
>
> Completely a coincidence. I've been aware of the plan to submit this
> proposal for several weeks, and hadn't seen your post until you
> mentioned it. I also had a conflict that precluded me from coming to
> the ApacheCon.
>
> As a general rule, the ASF doesn't go out "inviting", people within
> the ASF either start a new project, or projects come to us.
You're playing with words. Sure, there's no formal invitation process.
Now ASF members can approach projects they find interesting and "suggest
them to submit a proposal to the ASF", for the greatest benefit of both
the coming and existing ASF projects.
Thinking more about it, the fact that the ASF isn't supposed to invite
projects seems to go against the ASF meritocratic rules. You should not
ask for being a committer: you are voted in when other committers
consider you deserve it. And you can reject the offer. Same for
membership. Why couldn't it also apply to projects that already follow
the Apache way and are of interest to the Foundation's projects?
On the other hand, proposals like this one, originating from commercial
entities, really look to me as "pushing the ASF door open", even if the
incubator is supposed to ensure community diversity and healthiness
before graduating as a real project.
> In any case, the ASF is not exclusionary: if there was interest Dojo
> could be added to this proposal, or could pursue a separate proposal.
Right. Now I don't consider starting a proposal war to be the best thing
to do. Especially considering that one of the Dojo devs told me "Those
[the ASF benefits] are all good things, however the political and
organizational overhead of the ASF appears huge". Bingo.
>> So the questions are:
>> - is the ASF the place for Eclipse extensions? I don't deny the
>> ability to _existing_ project to host their tooling, but this isn't
>> the case here.
>
> As I mentioned, I was involved with these discussions. The ASF
> doesn't tend to make these types of decisions based on the technical
> aspects of a project. What impressed me about the people who were
> proposing this is that they were sincerely interested in the Apache
> License and collaboration model.
>
> While the Eclipse development model is certain a valid one, it is
> different in a number of significant ways from the ASF. Suffice it to
> say that I am partial to the way the ASF does business.
Ok. Now some of the planned features seems to directly overlap with
what's already in webtools (e.g. the JavaScript editor), and this
project would be the first one at the ASF in the general IDE tooling
category, which is what Eclipse is all about.
Sure, the development models are different and Apache cares about
community and not technical details, but this seems weird anyway and I'm
wondering if that won't turn into an OSS organizations war which would
certainly be detrimental to all of us.
In other words: why isn't this IBM-originated generic Eclipse tooling
donated to the Webtools project, that also originated from IBM?
>> - why incubate an Ajax library that none of the current ASF projects
>> uses nor plans to use, unless I missed something?
>
> It is a valid question, but it is also valid to point out that the ASF
> has projects as diverse as TCL and SpamAssassin.
The situation is very different here: several projects are integrating
Ajax features and incidentally found that they were considering the same
framework for that purpoe. Whereas none of the ASF projects was already
envisioning close integration with a spam filter when SpamAssassin came
to Apache.
That could even end up with the funny (ahem) situation where Apache has
an Ajax framework that isn't used by its Ajax-enabled server-side
frameworks. Doesn't it sound weird?
> What is more important is considerations that the code be licensed
> with the Apache Software License (not dual licensed, like Dojo), that
> the committer bases be diverse, and operate in an open and
> collaborative model.
C'mon! The incubation process is meant to solve licence and IP problems.
Zimbra is MPL & ZPL(?), and the IBM contribution is "Licensed Materials
- Property of IBM"!!
The Dojo peeps dual-licensed their stuff to allow the widest
distribution possible [1], and have a development model very close to
the Apache way, with active user and developer lists, and committers
nominated on a meritocratic basis. I can't see the same in this
proposal. The Zimbra stuff, as technically impressive as it can be, is
the creation of a single company whose commercial offering is based on
it. Nothing that prevents it to incubate of course, but community
diversity isn't an easy thing to achieve in such conditions.
Sylvain
[1]
http://blog.dojotoolkit.org/2005/12/04/dojo-now-dual-licensed-afl-and-bsd
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Adam Peller <ap...@us.ibm.com>.
Sylvain -
Sylvain Wallez wrote:
>So the questions are:
>- is the ASF the place for Eclipse extensions? I don't deny the ability
>to _existing_ project to host their tooling, but this isn't the case here.
The framework is composed of tools that happen to use Eclipse for a
runtime, much like Java-based projects use a JVM. As Sam stated, hopefully
it's the function that's of interest more than the platform, though I can
understand that this is not a typical proposal. The framework is only one
component of the project; runtime libraries and other AJAX-based utilities
(not tied to Eclipse) can find a home here also.
>- why incubate an Ajax library that none of the current ASF projects
>uses nor plans to use, unless I missed something?
What we hope to achieve is to form a community around AJAX. The tools we
put forth, we believe, will be helpful contributions towards that
community, but others are welcome. AJAX is likely to indirectly drive
Apache-based servers, and direct integration between AJAX and existing
Apache projects is certainly possible -- MyFaces is one such example.
Already we are building on top of integrated support for Tomcat to support
J2EE-based projects, and providing extensible tooling is key to the
architecture, so we should look for more integration points.
As for Dojo, we're very impressed with the project also. The tooling
framework we offer is extensible and even comes with tooling to create the
tooling -- something I didn't get into in the proposal, but it's basically
a wizard-driven UI to make it easier to get at least basic support for
toolkits. Custom features would require real coding.
-Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sam Ruby <ru...@apache.org>.
Sylvain Wallez wrote:
> Adam Peller wrote:
>
>> AJAX Toolkit Framework Proposal
>
> I'm quite puzzled by this proposal. As I understand it, its mainly about
> a set of Eclipse plugins for Ajax applications and the Zimbra library
> that, among other features, provides a set of SWT-like widgets.
Yes.
> Also, this proposal pops up right after I mention on members@ that
> several projects at Apache are using or plan to use Dojo [1] and that we
> talked about inviting them. I sincerely hope this is just a coincidence.
Completely a coincidence. I've been aware of the plan to submit this
proposal for several weeks, and hadn't seen your post until you
mentioned it. I also had a conflict that precluded me from coming to
the ApacheCon.
As a general rule, the ASF doesn't go out "inviting", people within the
ASF either start a new project, or projects come to us.
In any case, the ASF is not exclusionary: if there was interest Dojo
could be added to this proposal, or could pursue a separate proposal.
> So the questions are:
> - is the ASF the place for Eclipse extensions? I don't deny the ability
> to _existing_ project to host their tooling, but this isn't the case here.
As I mentioned, I was involved with these discussions. The ASF doesn't
tend to make these types of decisions based on the technical aspects of
a project. What impressed me about the people who were proposing this
is that they were sincerely interested in the Apache License and
collaboration model.
While the Eclipse development model is certain a valid one, it is
different in a number of significant ways from the ASF. Suffice it to
say that I am partial to the way the ASF does business.
> - why incubate an Ajax library that none of the current ASF projects
> uses nor plans to use, unless I missed something?
It is a valid question, but it is also valid to point out that the ASF
has projects as diverse as TCL and SpamAssassin.
What is more important is considerations that the code be licensed with
the Apache Software License (not dual licensed, like Dojo), that the
committer bases be diverse, and operate in an open and collaborative model.
> Sylvain
>
> [1] http://www.dojotoolkit.org/
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: AJAX Toolkit Framework Proposal
Posted by Sylvain Wallez <sy...@apache.org>.
Adam Peller wrote:
> AJAX Toolkit Framework Proposal
>
I'm quite puzzled by this proposal. As I understand it, its mainly about
a set of Eclipse plugins for Ajax applications and the Zimbra library
that, among other features, provides a set of SWT-like widgets.
Also, this proposal pops up right after I mention on members@ that
several projects at Apache are using or plan to use Dojo [1] and that we
talked about inviting them. I sincerely hope this is just a coincidence.
So the questions are:
- is the ASF the place for Eclipse extensions? I don't deny the ability
to _existing_ project to host their tooling, but this isn't the case here.
- why incubate an Ajax library that none of the current ASF projects
uses nor plans to use, unless I missed something?
Sylvain
[1] http://www.dojotoolkit.org/
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org