[DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <rv...@apache.org>]

Hi!

I would like to open up a discussion thread on
the proposals for the core of Pivotal's GemFire
to join ASF as an incubating project under the
name Geode.

The proposal wiki is available here:
   https://wiki.apache.org/incubator/GeodeProposal
and the text of the proposal is attached to the
bottom of this email as well.

Given the timing of ApacheCON, we would love to
chat with anybody interested in giving us feedback.
That said, of course, the bulk of the discussion is
expected to happen on this thread.

Thanks for your time and consideration!
Roman (Geode proposal champion and a nominated mentor).

== Abstract ==
Geode is a data management platform that provides real-time,
consistent access to data-intensive applications throughout widely
distributed cloud architectures.

Geode pools memory (along with CPU, network and optionally local disk)
across multiple processes to manage application objects and behavior.
It uses dynamic replication and data partitioning techniques for high
availability, improved performance, scalability, and fault tolerance.
Geode is both a distributed data container and an in-memory data
management system providing reliable asynchronous event notifications
and guaranteed message delivery.

== Proposal ==
The goal of this proposal is to bring the core of Pivotal Software,
Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
Foundation (ASF) in order to build a vibrant, diverse and
self-governed open source community around the technology. Pivotal
will continue to market and sell Pivotal GemFire based on Geode. Geode
and Pivotal GemFire will be managed separately. This proposal covers
the Geode source code (mainly written in Java), Geode documentation
and other materials currently available on GitHub.

While Geode is our primary choice for a name of the project, in order
to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
  * Haptic
  * FIG

== Background ==
GemFire is an extremely mature and robust product that can trace its
legacy all the way back to one of the first Object Databases for
Smalltalk: GemStone. The GemFire code base has been maintained by the
same group of engineers as a closed source project. Because of that,
even though the engineers behind GemFire are the de-facto knowledge
leaders for distributed in-memory management, they have had little
exposure to the open source governance process.    The original
company developing GemStone and GemFire was acquired by VMWare in 2010
and later spun off as part of Pivotal Software in 2013. Today GemFire
is used by over 600 enterprise customers. An example deployment
includes China National Railways that uses Pivotal GemFire to run
railway ticketing for the entire country of China with a 10 node
cluster that manages 2 gigabytes "hot data" in memory, and 10 backup
nodes for high availability and elastic scale.

== Rationale ==
Modern-day data management architectures require a robust in-memory
data grid solution to handle a variety of use cases, ranging from
enterprise-wide caching to real-time transactional applications at
scale. In addition, as memory size and network bandwidth growth
continues to outpace those of disk, the importance of managing large
pools of RAM at scale increases. It is essential to innovate at the
same pace and Pivotal strongly believes that in the Big Data space,
this can be optimally achieved through a vibrant, diverse,
self-governed community collectively innovating around a single
codebase while at the same time cross-pollinating with various other
data management communities. ASF is the ideal place to meet these
ambitious goals.

== Initial Goals ==
Our initial goals are to bring Geode into the ASF, transition internal
engineering processes into the open, and foster a collaborative
development model according to the "Apache Way." Pivotal plans to
develop new functionality in an open, community-driven way. To get
there, the existing internal build, test and release processes will be
refactored to support open development.

== Current Status ==
Currently, the project code base is licensed for evaluation purposes
and is available for download from Pivotal.io
(https://network.pivotal.io/products/project-geode). The documentation
and wiki pages are available as public GitHub repositories under
Project Geode organization on GitHub
(https://github.com/project-geode). Although Pivotal GemFire was
developed as a proprietary, closed-source product, the internal
engineering practices adopted by the development team lend themselves
well to an open, collaborative and meritocratic environment.

The Pivotal GemFire team has always focused on building a robust end
user community of paying and non-paying customers. The existing
documentation along with StackOverflow and other similar forums are
expected to facilitate conversions between our existing users so as to
transform them into an active community of Geode members, stakeholders
and developers.

=== Meritocracy ===
Our proposed list of initial committers include the current GemFire
R&D team, Pivotal Field Engineers, and several existing customers and
partners. This group will form a base for the broader community we
will invite to collaborate on the codebase. We intend to radically
expand the initial developer and user community by running the project
in accordance with the "Apache Way". Users and new contributors will
be treated with respect and welcomed. By participating in the
community and providing quality patches/support that move the project
forward, they will earn merit. They also will be encouraged to provide
non-code contributions (documentation, events, community management,
etc.) and will gain merit for doing so. Those with a proven support
and quality track record will be encouraged to become committers.

=== Community ===
If Geode is accepted for incubation, the primary initial goal will be
transitioning the core community towards embracing the Apache Way of
project governance. We would solicit major existing contributors to
become committers on the project from the start.

=== Core Developers ===

While a few core developers are skilled in working in openly governed
Apache communities. Most of the core developers are currently NOT
affiliated with the ASF and would require new ICLAs before committing
to the project.

=== Alignment ===
The following existing ASF projects can be considered when reviewing
Geode proposal:

Apache HadoopⓇ is a distributed storage and processing framework for
very large datasets focusing primarily on batch processing for
analytic purposes. Geode is a data management platform that provides
real-time, consistent, and transactional access to data-intensive
applications. Our roadmap includes plans to provide close integration
with HDFS.

Apache HBase offers tabular data stored in Hadoop based on the Google
Bigtable model.  HBase uses a key-based partitioning scheme and column
family data model that can work well for scan intensive workloads but
is not as broadly applicable as the rich object model, OQL querying,
and hash partitioning provided by Geode.  Geode will use the HFile
format for storing data in HDFS.

Apache Spark is a fast engine for processing large datasets, typically
from a Hadoop cluster, and performing batch, streaming, interactive,
or machine learning workloads.  Geode supports high throughput
streaming ingest application patterns and data parallel algorithms.
Geode also ensures that data is highly available through redundancy
while Spark recovers from faults using RDD lineage recomputation.  Our
roadmap includes plans for providing integration with the Spark
platform.

Apache Ignite (incubating) offers distributed in-memory processing
capabilities which in some ways overlap with Geode.  However, Geode
has been in this field for more than 10 years and the product API's,
design, and implementation details are quite different.  In addition,
Geode offers highly optimized shared-nothing disk persistence for
in-memory data which does not appear to be available with Ignite.

Apache Cassandra is a highly scalable, distributed key-value store
that focuses on eventual consistency.  It uses log-structured merge
trees to handle write-heavy workloads.  The Geode distributed
in-memory cluster provides highly performant and advanced capabilities
including network partition detection and recovery, version-based
state synchronization and conflict resolution, and single IO disk
operations.

Apache ActiveMQ and its sub project Apache Apollo offers a powerful
message queue framework that is being considered for an open source
implementation of Geode's WAN replication capabilities.

Apache Storm is a streaming engine that processes events through a
directed graph of computation. It requires Apache Zookeeper for
coordination and Apache Kafka to reliably store the streaming data
source. Geode provides builtin capabilities for these functions. In
addition, Geode offers data locality for related entities and
in-process access to reference data typically used during processing.

Apache Kafka offers distributed and durable publish-subscribe
messaging. Geode expands beyond publish-subscribe messaging to support
data oriented notifications delivered from highly available, fault
tolerant event queues that can be easily correlated to related data
for further processing. Apache Samza is a distributed processing
framework heavily dependent on Apache Kafka and Apache Hadoop YARN for
messaging and distributed fault-tolerant processing.  Geode is data
source agnostic and leverages its own technology and implementation
for such use cases.

== Known Risks ==
Development has been sponsored mostly by a single company (or its
predecessors) thus far and coordinated mainly by the core Pivotal
GemFire team.

For the project to fully transition to the Apache Way governance
model, development must shift towards the meritocracy-centric model of
growing a community of contributors balanced with the needs for
extreme stability and core implementation coherency.

The tools and development practices in place for the Pivotal GemFire
product are compatible with the ASF infrastructure and thus we do not
anticipate any on-boarding pains. Migration from the current GitHub
repository is also expected to be straightforward.

The project currently includes a modified version of the JGroups
software toolkit. JGroups was initially released under the LGPL
license. Although we have complied with the terms of the LGPL by
making the modified source available, LGPL is classified as an
incompatible license by the ASF.  The JGroups project has since been
re-licenced under ALv2 (see http://www.jgroups.org/license.html) and
we plan to engage with the licensor to overcome this license
incompatibility. If the license incompatibility cannot be overcome
through our discussions with the licensor, we will need to rework this
portion of the project based upon a newer version of the JGroups
toolkit or via other alternative development efforts.

=== Orphaned products ===
Pivotal is fully committed to Pivotal GemFire and the product will
continue to be based on the Geode project. Moreover, Pivotal has a
vested interest in making Geode succeed by driving its close
integration with sister ASF projects. We expect this to further
reduces the risk of orphaning the product.

=== Inexperience with Open Source ===
Pivotal has embraced open source software since its formation by
employing contributors/committers and by shepherding open source
projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Pivotal also
supports other open source projects such as Redis, Chorus, Groovy and
Grails. We have experience with the formation of vibrant communities
around open technologies with the Cloud Foundry Foundation.  Although
some of the initial committers have not been developers on an entirely
open source, community-driven project, we expect to bring to bear the
open development practices that have proven successful on longstanding
Pivotal open source projects to the Geode project.  Additionally,
several ASF veterans agreed to mentor the project and are listed in
this proposal. The project will rely on their guidance and collective
wisdom to quickly transition the entire team of initial committers
towards practicing the Apache Way.

=== Homogeneous Developers ===
While most of the initial committers are employed by Pivotal, we have
already seen a healthy level of interest from our existing customers
and partners. We intend to convert that interest directly into
participation and will be investing in activities to recruit
additional committers from other companies.

=== Reliance on Salaried Developers ===
Most of the contributors are paid to work in the Big Data space. While
they might wander from their current employers, they are unlikely to
venture far from their core expertises and thus will continue to be
engaged with the project regardless of their current employers.

=== Relationships with Other Apache Products ===
As mentioned in the Alignment section, Geode may consider various
degrees of integration and code exchange with Apache Ignite
(incubating), Apache Hadoop, Apache Storm, Apache Spark and Apache
Kafka/Samza. Given the success that the Pivotal GemFire product
enjoyed as an embedded service, we expect integration points to be
inside and outside the project. We look forward to collaborating with
these communities as well as other communities under the Apache
umbrella.

=== An Excessive Fascination with the Apache Brand ===
While we intend to leverage the Apache ‘branding’ when talking to
other projects as testament of our project’s ‘neutrality’, we have no
plans for making use of Apache brand in press releases nor posting
billboards advertising acceptance of Geode into Apache Incubator.

== Documentation ==
See documentation for the current state of the project documentation
available as part of the GitHub repository at
https://github.com/project-geode/docs and live at http://geode-docs.cfapps.io/

== Initial Source ==
Pivotal is releasing the source code for Geode under an Evaluation
License at https://network.pivotal.io/products/project-geode .  We
encourage ASF community members interested in  this proposal to
download the source code, review and try out the software.

== Source and Intellectual Property Submission Plan ==
As soon as Geode is approved to join Apache Incubator, the source code
will be transitioned via the Software Grant Agreement onto ASF
infrastructure and in turn made available under the Apache License,
version 2.0.  We know of no legal encumberments that would inhibit the
transfer of source code to the ASF.

== External Dependencies ==

Embedded dependencies (relocated):
   * json
   * jgroups
   * joptsimple

Runtime dependencies:
   * antlr
   * classmate
   * commons-fileupload
   * commons-io
   * commons-lang
   * commons-modeler
   * fastutil
   * findbugs annotations
   * guava
   * jackson
   * jansi
   * javax.activation
   * javax.mail-api
   * javax.resource-api
   * javax.servlet-api
   * javax.transaction-api
   * jetty
   * jline
   * jna
   * json4s
   * log4j
   * mx4j
   * paranamer
   * scala
   * slf4j
   * snappy-java
   * spring
   * swagger

Module or optional dependencies:
   * None

Build only dependencies:
   * None

Test only dependencies:
   * cglib
   * hamcrest
   * jmock
   * junit
   * multithreadedtc
   * objenesis

Cryptography
N/A

== Required Resources ==

=== Mailing lists ===
  * private@geode.incubator.apache.org (moderated subscriptions)
  * commits@geode.incubator.apache.org
  * dev@geode.incubator.apache.org
  * issues@geode.incubator.apache.org
  * user@geode.incubator.apache.org

=== Git Repository ===
https://git-wip-us.apache.org/repos/asf/incubator-geode.git

=== Issue Tracking ===
JIRA Project Geode (GEODE)

=== Other Resources ===

Means of setting up regular builds for Geode on builds.apache.org

== Initial Committers ==
  * Amey Barve
  * Adib Saikali
  * Alan Strait
  * Amogh Shetkar
  * Anil Gingade
  * Anilkumar Gingade
  * Anthony Baker
  * Ashvin Agrawal
  * Asif Shahid
  * Avinash Dongre
  * Barry Oglesby
  * Ben Reser
  * Bruce Schuchardt
  * Bruce Szalwinski
  * Catherine Johnson
  * Chip Childers
  * Christian Tzolov
  * Dan Smith
  * Darrel Schneider
  * Dave Muirhead
  * David Yozie
  * Dick Cavender
  * Edin Zulich
  * Eric Shu
  * Gideon Low
  * Greg Chase
  * Hemant Bhanawat
  * Henry Saputra
  * Hitesh Khamesra
  * Jacob Barrett
  * Jags Ramnarayan
  * Jan Iversen
  * Jason Huynh
  * Jens Deppe
  * Jianxia Chen
  * John Blum
  * Justin Erenkrantz
  * Ketan Deshpande
  * Kirk Lund
  * Kishor Bachhav
  * Konstantin Boudnik
  * Konstantin Ignatyev
  * Lise Storc
  * Luke Shannon
  * Lyndon Adams
  * Lynn Gallinat
  * Lynn Hughes-Godfrey
  * Mark Bretl
  * Michael Schubert
  * Namrata Thanvi
  * Neeraj Kumar
  * Nilkanth Patel
  * Qihong Chen
  * Rahul Diyewar
  * Randy May
  * Roman Shaposhnik
  * Severine Tymon
  * Shatarupa Nandi
  * Shirish Deshmukh
  * Sonal Agarwal
  * Soubhik Chakraborty
  * Sourabh Bansod
  * Stephane Maldini
  * Stuart Williams
  * Sudhir Menon
  * Sunil Jigyasu
  * Supriya Pillai
  * Suranjan Kumar
  * Suyog Bhokare
  * Swapnil Bawaskar
  * Swati Sawant
  * Tushar Khairnar
  * Udo Kohlmeyer
  * Vince Ford
  * Vinesh Prasanna Manoharan
  * Vivek Bhaskar
  * Wes Williams
  * William A. Rowe Jr.
  * William Markito
  * Will Schipp
  * Xiaojian Zhou
  * Yogesh Mahajan

== Affiliations ==
  * WANDisco: Konstantin Boudnik
  * Bloomberg LP: Justin Erenkrantz
  * Cloud Foundry Foundation: Chip Childers
  * NASA JPL: Chris Mattmann
  * Unaffiliated: Jan Iversen
  * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
  * Pivotal: everyone else on this proposal

== Sponsors ==

=== Champion ===
Roman Shaposhnik

=== Nominated Mentors ===

The initial mentors are listed below:
  * Chip Childers - Apache Member, Cloud Foundry Foundation
  * Justin Erenkrantz - Apache Member, Bloomberg LP
  * Konstantin Boudnik - Apache Member, WANDisco
  * Jan Iversen - Apache Member, Self employed
  * William A. Rowe Jr. - Apache Member, Pivotal
  * Henry Saputra - Apache Member, Pivotal
  * Roman Shaposhnik - Apache Member, Pivotal
  * Chris Mattmann - Apache Member, NASA JPL

=== Sponsoring Entity ===
We would like to propose Apache incubator to sponsor this project.

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

Re: [DISCUSS] Geode Incubation proposal

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Apr 13, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> If I understand the response below correctly you misspoke when you said there were "export" issues. That in fact there is no related export restriction, it's actually about the licensing issue. If that's the case then the proposal is correct in not highlighting these issues - thanks for clarifying that.
>
> I replied to the third part in response to Bill's question. However, to be sure my point gets across. Now that you have confirmed there are in fact no export restrictions then I have no problem with the proposal. However, I'd still like to be able to evaluate the code and to do so I would need to know what I'm agreeing to under the evaluation license.

FWIW, the clickthrough license et al worked for me on my Mac with Chrome.

Inspecting the code will be a lot easier once the proposal is accepted
and we can import the code under ALv2 into our repositories.

*grin*  -- justin

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

RE: [DISCUSS] Geode Incubation proposal

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

It's nothing to do with my browser. If I click the download link I get asked to join the "Pivotal Network" before I can download it.

If I understand the response below correctly you misspoke when you said there were "export" issues. That in fact there is no related export restriction, it's actually about the licensing issue. If that's the case then the proposal is correct in not highlighting these issues - thanks for clarifying that.

I replied to the third part in response to Bill's question. However, to be sure my point gets across. Now that you have confirmed there are in fact no export restrictions then I have no problem with the proposal. However, I'd still like to be able to evaluate the code and to do so I would need to know what I'm agreeing to under the evaluation license.

-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
Sent: Monday, April 13, 2015 12:38 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Geode Incubation proposal

On Sun, Apr 12, 2015 at 10:15 PM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:
> Pivotal are asking me to agree to an "evaluation license" which I cannot view before I sign up.
> So I have to review the privacy policy first.

This must be a bug in your browser. What OS/Browser are you using?

The text of the license is also available in a separate file under the name "Evaluation License":
    https://network.pivotal.io/products/project-geode

> Most importantly, the "export and license obligations" you mention are 
> something that have to go away before we can accept the project (or more accurately before it can graduate).
> Since I can't evaluate the code or the license I have no way of evaluating whether this is possible.
>
> There is no mention of such an item under "known risks" or the 
> "crypotography" section of the proposal so what's this "export" stuff about (assuming the license thing is the evaluation license)?

Sorry for not being more explicit: this is just how Pivotal distribution network works.
And we have to use it in this particular case in order to guarantee that the evaluation license has been explicitly acknowledged (as opposed to just being there in a tarball). All these constraints has nothing to do with the source code itself.

> Given the points above I do not see how I can evaluate this proposal in its current form.

I see that Bill has asked the question that I wanted to ask here, so I'll let you reply in that part of the thread.

Thanks,
Roman.

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

Re: [DISCUSS] Geode Incubation proposal

[Ted Dunning <te...@gmail.com>]

On Mon, Apr 13, 2015 at 7:38 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> > There is no mention of such an item under "known risks" or the
> "crypotography" section of the proposal
> > so what's this "export" stuff about (assuming the license thing is the
> evaluation license)?
>
> Sorry for not being more explicit: this is just how Pivotal
> distribution network works.
> And we have to use it in this particular case in order to guarantee
> that the evaluation
> license has been explicitly acknowledged (as opposed to just being there
> in a
> tarball). All these constraints has nothing to do with the source code
> itself.


It is fair to put a bit of text into the risks statement that says that the
code is currently encumbered with export limitations due to corporate
policy but that these limits will be released as part of the software grant.

Re: [DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Apr 12, 2015 at 10:15 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> Pivotal are asking me to agree to an "evaluation license" which I cannot view before I sign up.
> So I have to review the privacy policy first.

This must be a bug in your browser. What OS/Browser are you using?

The text of the license is also available in a separate file under the
name "Evaluation License":
    https://network.pivotal.io/products/project-geode

> Most importantly, the "export and license obligations" you mention are something that
> have to go away before we can accept the project (or more accurately before it can graduate).
> Since I can't evaluate the code or the license I have no way of evaluating whether this is possible.
>
> There is no mention of such an item under "known risks" or the "crypotography" section of the proposal
> so what's this "export" stuff about (assuming the license thing is the evaluation license)?

Sorry for not being more explicit: this is just how Pivotal
distribution network works.
And we have to use it in this particular case in order to guarantee
that the evaluation
license has been explicitly acknowledged (as opposed to just being there in a
tarball). All these constraints has nothing to do with the source code itself.

> Given the points above I do not see how I can evaluate this proposal in its current form.

I see that Bill has asked the question that I wanted to ask here, so
I'll let you reply in that
part of the thread.

Thanks,
Roman.

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

Re: [DISCUSS] Geode Incubation proposal

[jan i <ja...@apache.org>]

On Monday, April 13, 2015, Justin Erenkrantz <ju...@erenkrantz.com> wrote:

> >> On 13 Apr 2015, at 06:39, Ted Dunning <ted.dunning@gmail.com
> <javascript:;>> wrote:
> >>
> >> I think it is common to take a quick look at code coming in.  In
>
> To be clear, there were conversations with Jim (as VP Legal) prior to
> this submission.  The ASF wouldn't accept the software grant until the
> Incubator approved the proposal.  Pivotal wouldn't release it as ALv2
> until the ASF accepted the grant.
>
> It's a chicken-and-egg problem - seeing the code through the
> click-through evaluation license is the least bad scenario that drives
> this proposal forward.
>
> As a mentor unaffiliated with Pivotal, I'm not worried about the
> provenance checks - Pivotal is ready to execute the software grant and
> release it as ALv2.

i second the opinion of justin, as Mentor I was one of those that suggested
this way.

The concerns raised below are very similar to my concerns, but they have to
with graduation,
and not entering Incubator. Most importantly both Mentors and the team are
aware of
the potential problems.

rgds
jan i

>
> On Mon, Apr 13, 2015 at 7:40 AM, Steve Loughran <stevel@hortonworks.com
> <javascript:;>> wrote:
> > looking at the list of committers -it looks like a whole organisation is
> going to move to doing OSS dev. That's a pretty big move.
>
> Yes, it is.  I'm confident in my conversations with the Pivotal team
> that they fully understand what will be asked of them.  However, as a
> mentor, the proof will be in the pudding and will be demonstrated
> through the Incubation process...or not.
>
> > 1. The withdrawal of support for Groovy shows that pivotal have been
> ruthless in the past about where to invest their OSS dev. It's a bit
> dangerous to list Groovy as a reference for pivotal's OSS experience. It
> shows they've done it, but it shows that the commitment is not indefinite
> funding (to be fair, no single org can guarantee that). Spring is the one
> to really emphasis.
>
> Companies are always free to re-evaluate where they spend their time
> and resources.  I actually view the experience with Groovy as a
> positive thing in the macro sense.  The point of submitting Geode to
> the ASF is to ensure the longevity of the project and community - the
> lesson from Groovy is to ensure it is in appropriate foundation that
> will care for it.
>
> > 2. It will make it more of a barrier to getting other developers in;
> it'll take active effort to bring them in, especially a transition to a
> process of decision making over the lists, rather than in meetings. Again,
> a perennial problem that we all encounter -not an argument against the
> proposal, just something that will take active effort.
>
> This is why we have an Incubator.  =)
>
> > I don't see it leaving incubation with more non-pivotal dev/contrib than
> the pivotal team, just because of the numbers. The mentors/vote will have
> to consider how many external developers constitutes "enough" to be an
> active, open dev community. Again, a permanent problem (*), it just means
> here that it will be very skewed towards pivotal. I think that open-source
> discussion and decision making should be a key metric here, rather than
> just looking at numbers.
>
> Fully agreed for exit criteria, but let's get it in first!  -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>

-- 
Sent from My iPad, sorry for any misspellings.

Re: [DISCUSS] Geode Incubation proposal

[William A Rowe Jr <wr...@rowe-clan.net>]

I am a proposed mentor associated with Pivotal, well away from my own
technology and engineering teams.  I'm not good enough with darts to hit
that side of the org chart from this side of the room, but really would like
to see the contribution succeed, so I'm approaching this as always with
my ASF hat, as a facilitator and educator.  I've had enough conversations
to trust that this is doable.

There seem to be no further issues raised, and there have been nearly
2 weeks for more concerns, questions and other commentary.  Roman,
this appears to be vote-worthy.  Incubation can't begin unless incubation
is begun...

Yours,

Bill


On Wed, Apr 15, 2015 at 11:48 PM, Konstantin Boudnik <co...@apache.org> wrote:

> +1 on what Justin said. And I am not affiliated w/ Pivotal in _any_ way.
>
> Cos
>
> On Mon, Apr 13, 2015 at 08:10AM, Justin Erenkrantz wrote:
> > >> On 13 Apr 2015, at 06:39, Ted Dunning <te...@gmail.com> wrote:
> > >>
> > >> I think it is common to take a quick look at code coming in.  In
> >
> > To be clear, there were conversations with Jim (as VP Legal) prior to
> > this submission.  The ASF wouldn't accept the software grant until the
> > Incubator approved the proposal.  Pivotal wouldn't release it as ALv2
> > until the ASF accepted the grant.
> >
> > It's a chicken-and-egg problem - seeing the code through the
> > click-through evaluation license is the least bad scenario that drives
> > this proposal forward.
> >
> > As a mentor unaffiliated with Pivotal, I'm not worried about the
> > provenance checks - Pivotal is ready to execute the software grant and
> > release it as ALv2.
>

Re: [DISCUSS] Geode Incubation proposal

[Konstantin Boudnik <co...@apache.org>]

+1 on what Justin said. And I am not affiliated w/ Pivotal in _any_ way.

Cos

On Mon, Apr 13, 2015 at 08:10AM, Justin Erenkrantz wrote:
> >> On 13 Apr 2015, at 06:39, Ted Dunning <te...@gmail.com> wrote:
> >>
> >> I think it is common to take a quick look at code coming in.  In
> 
> To be clear, there were conversations with Jim (as VP Legal) prior to
> this submission.  The ASF wouldn't accept the software grant until the
> Incubator approved the proposal.  Pivotal wouldn't release it as ALv2
> until the ASF accepted the grant.
> 
> It's a chicken-and-egg problem - seeing the code through the
> click-through evaluation license is the least bad scenario that drives
> this proposal forward.
> 
> As a mentor unaffiliated with Pivotal, I'm not worried about the
> provenance checks - Pivotal is ready to execute the software grant and
> release it as ALv2.
> 
> On Mon, Apr 13, 2015 at 7:40 AM, Steve Loughran <st...@hortonworks.com> wrote:
> > looking at the list of committers -it looks like a whole organisation is going to move to doing OSS dev. That's a pretty big move.
> 
> Yes, it is.  I'm confident in my conversations with the Pivotal team
> that they fully understand what will be asked of them.  However, as a
> mentor, the proof will be in the pudding and will be demonstrated
> through the Incubation process...or not.
> 
> > 1. The withdrawal of support for Groovy shows that pivotal have been ruthless in the past about where to invest their OSS dev. It's a bit dangerous to list Groovy as a reference for pivotal's OSS experience. It shows they've done it, but it shows that the commitment is not indefinite funding (to be fair, no single org can guarantee that). Spring is the one to really emphasis.
> 
> Companies are always free to re-evaluate where they spend their time
> and resources.  I actually view the experience with Groovy as a
> positive thing in the macro sense.  The point of submitting Geode to
> the ASF is to ensure the longevity of the project and community - the
> lesson from Groovy is to ensure it is in appropriate foundation that
> will care for it.
> 
> > 2. It will make it more of a barrier to getting other developers in; it'll take active effort to bring them in, especially a transition to a process of decision making over the lists, rather than in meetings. Again, a perennial problem that we all encounter -not an argument against the proposal, just something that will take active effort.
> 
> This is why we have an Incubator.  =)
> 
> > I don't see it leaving incubation with more non-pivotal dev/contrib than the pivotal team, just because of the numbers. The mentors/vote will have to consider how many external developers constitutes "enough" to be an active, open dev community. Again, a permanent problem (*), it just means here that it will be very skewed towards pivotal. I think that open-source discussion and decision making should be a key metric here, rather than just looking at numbers.
> 
> Fully agreed for exit criteria, but let's get it in first!  -- justin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

Re: [DISCUSS] Geode Incubation proposal

[Justin Erenkrantz <ju...@erenkrantz.com>]

>> On 13 Apr 2015, at 06:39, Ted Dunning <te...@gmail.com> wrote:
>>
>> I think it is common to take a quick look at code coming in.  In

To be clear, there were conversations with Jim (as VP Legal) prior to
this submission.  The ASF wouldn't accept the software grant until the
Incubator approved the proposal.  Pivotal wouldn't release it as ALv2
until the ASF accepted the grant.

It's a chicken-and-egg problem - seeing the code through the
click-through evaluation license is the least bad scenario that drives
this proposal forward.

As a mentor unaffiliated with Pivotal, I'm not worried about the
provenance checks - Pivotal is ready to execute the software grant and
release it as ALv2.

On Mon, Apr 13, 2015 at 7:40 AM, Steve Loughran <st...@hortonworks.com> wrote:
> looking at the list of committers -it looks like a whole organisation is going to move to doing OSS dev. That's a pretty big move.

Yes, it is.  I'm confident in my conversations with the Pivotal team
that they fully understand what will be asked of them.  However, as a
mentor, the proof will be in the pudding and will be demonstrated
through the Incubation process...or not.

> 1. The withdrawal of support for Groovy shows that pivotal have been ruthless in the past about where to invest their OSS dev. It's a bit dangerous to list Groovy as a reference for pivotal's OSS experience. It shows they've done it, but it shows that the commitment is not indefinite funding (to be fair, no single org can guarantee that). Spring is the one to really emphasis.

Companies are always free to re-evaluate where they spend their time
and resources.  I actually view the experience with Groovy as a
positive thing in the macro sense.  The point of submitting Geode to
the ASF is to ensure the longevity of the project and community - the
lesson from Groovy is to ensure it is in appropriate foundation that
will care for it.

> 2. It will make it more of a barrier to getting other developers in; it'll take active effort to bring them in, especially a transition to a process of decision making over the lists, rather than in meetings. Again, a perennial problem that we all encounter -not an argument against the proposal, just something that will take active effort.

This is why we have an Incubator.  =)

> I don't see it leaving incubation with more non-pivotal dev/contrib than the pivotal team, just because of the numbers. The mentors/vote will have to consider how many external developers constitutes "enough" to be an active, open dev community. Again, a permanent problem (*), it just means here that it will be very skewed towards pivotal. I think that open-source discussion and decision making should be a key metric here, rather than just looking at numbers.

Fully agreed for exit criteria, but let's get it in first!  -- justin

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

Re: [DISCUSS] Geode Incubation proposal

[Steve Loughran <st...@hortonworks.com>]

> On 13 Apr 2015, at 06:39, Ted Dunning <te...@gmail.com> wrote:
> 
> I think it is common to take a quick look at code coming in.  In
> particular, a glance to see whether there is any hygiene around licensing
> is an important question.  Many projects in the world at large have no good
> record of who write the code but still imagine that they can change the
> licensing.  Such projects are not suitable for Apache incubation since
> without a clean rewrite, they are not possible to Apache license.
> 
> Commercially developed code rarely has that sort of problem, but there may
> be other problems that a quick perusal would turn up or eliminate.

I believe one reason the openjdk GUI rendering is worse than the oracle one is, apparently, that there's a  chunk of OSF/Motif code in there whose provenance isn't clear, until it was released as LGPL, was closed source. That is: code sharing by cut-and-paste is always trouble

looking at the list of committers -it looks like a whole organisation is going to move to doing OSS dev. That's a pretty big move.

1. The withdrawal of support for Groovy shows that pivotal have been ruthless in the past about where to invest their OSS dev. It's a bit dangerous to list Groovy as a reference for pivotal's OSS experience. It shows they've done it, but it shows that the commitment is not indefinite funding (to be fair, no single org can guarantee that). Spring is the one to really emphasis.

2. It will make it more of a barrier to getting other developers in; it'll take active effort to bring them in, especially a transition to a process of decision making over the lists, rather than in meetings. Again, a perennial problem that we all encounter -not an argument against the proposal, just something that will take active effort.

I don't see it leaving incubation with more non-pivotal dev/contrib than the pivotal team, just because of the numbers. The mentors/vote will have to consider how many external developers constitutes "enough" to be an active, open dev community. Again, a permanent problem (*), it just means here that it will be very skewed towards pivotal. I think that open-source discussion and decision making should be a key metric here, rather than just looking at numbers.

otherwise: impressive proposal!

-Steve


(*) as a reminder, we in the slider-incubating project are hiring -along with every other incubated project.

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

Re: [DISCUSS] Geode Incubation proposal

[Ted Dunning <te...@gmail.com>]

I think it is common to take a quick look at code coming in.  In
particular, a glance to see whether there is any hygiene around licensing
is an important question.  Many projects in the world at large have no good
record of who write the code but still imagine that they can change the
licensing.  Such projects are not suitable for Apache incubation since
without a clean rewrite, they are not possible to Apache license.

Commercially developed code rarely has that sort of problem, but there may
be other problems that a quick perusal would turn up or eliminate.

At the very least, it seems reasonable to put a link to the content of the
evaluation license in the proposal.



On Mon, Apr 13, 2015 at 7:32 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> Ross,
>
> do we evaluate source code at the incubation-entry level, or do we evaluate
> proposed development goals and development community propositions? I'm
> curious about your thoughts.
>
> Yours,
>
> Bill
> On Apr 13, 2015 12:16 AM, "Ross Gardler (MS OPEN TECH)" <
> Ross.Gardler@microsoft.com> wrote:
>
> > Pivotal are asking me to agree to an "evaluation license" which I cannot
> > view before I sign up. So I have to review the privacy policy first.
> >
> > Pivotal's privacy policy goes a *long* way beyond the point I am
> > comfortable with when getting open source software (or deciding whether I
> > want to agree with an evaluation license I can't read). I guess your
> > defense could be that it's not open source yet, that's fine, but you are
> > asking me, as an IPMC Member, to make a judgement on the validity of the
> > proposal but I can't evaluate the code since I can't access it or the
> > license under which I am allowed to view it.
> >
> > Most importantly, the "export and license obligations" you mention are
> > something that have to go away before we can accept the project (or more
> > accurately before it can graduate). Since I can't evaluate the code or
> the
> > license I have no way of evaluating whether this is possible. There is no
> > mention of such an item under "known risks" or the "crypotography"
> section
> > of the proposal so what's this "export" stuff about (assuming the license
> > thing is the evaluation license)?
> >
> > Given the points above I do not see how I can evaluate this proposal in
> > its current form.
> >
> > Ross
> >
> > -----Original Message-----
> > From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of
> > Roman Shaposhnik
> > Sent: Sunday, April 12, 2015 11:56 PM
> > To: general@incubator.apache.org
> > Subject: Re: [DISCUSS] Geode Incubation proposal
> >
> > Since I'm getting a few off-list questions, I just want to make one point
> > clear:
> >
> > On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> > >> I'd also like to be able to review the source referred to in the
> > >> proposal without having to sign up to  "the Pivotal network" - how can
> > I do that?
> > >
> > > The issue here is export and license compliance. Unfortunately,
> > > singing up is the only way to go right now. Why is it problematic for
> > you?
> >
> > The software currently is NOT under ALv2. It is available under the
> > evaluation license. The whole point of the proposal is to make it
> available
> > under ALv2 as an Incubating project.
> >
> > Our apologies for making folks click through the evaluation license.
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > 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: [DISCUSS] Geode Incubation proposal

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

I believe we evaluate the community, not the code. 

However, in this case I would like to look at the code to get a feel for whether I would be interested in contributing to the project.

Ross

-----Original Message-----
From: William A Rowe Jr [mailto:wrowe@rowe-clan.net] 
Sent: Monday, April 13, 2015 12:33 AM
To: general@incubator.apache.org
Subject: RE: [DISCUSS] Geode Incubation proposal

Ross,

do we evaluate source code at the incubation-entry level, or do we evaluate proposed development goals and development community propositions? I'm curious about your thoughts.

Yours,

Bill
On Apr 13, 2015 12:16 AM, "Ross Gardler (MS OPEN TECH)" < Ross.Gardler@microsoft.com> wrote:

> Pivotal are asking me to agree to an "evaluation license" which I 
> cannot view before I sign up. So I have to review the privacy policy first.
>
> Pivotal's privacy policy goes a *long* way beyond the point I am 
> comfortable with when getting open source software (or deciding 
> whether I want to agree with an evaluation license I can't read). I 
> guess your defense could be that it's not open source yet, that's 
> fine, but you are asking me, as an IPMC Member, to make a judgement on 
> the validity of the proposal but I can't evaluate the code since I 
> can't access it or the license under which I am allowed to view it.
>
> Most importantly, the "export and license obligations" you mention are 
> something that have to go away before we can accept the project (or 
> more accurately before it can graduate). Since I can't evaluate the 
> code or the license I have no way of evaluating whether this is 
> possible. There is no mention of such an item under "known risks" or 
> the "crypotography" section of the proposal so what's this "export" 
> stuff about (assuming the license thing is the evaluation license)?
>
> Given the points above I do not see how I can evaluate this proposal 
> in its current form.
>
> Ross
>
> -----Original Message-----
> From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of 
> Roman Shaposhnik
> Sent: Sunday, April 12, 2015 11:56 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Geode Incubation proposal
>
> Since I'm getting a few off-list questions, I just want to make one 
> point
> clear:
>
> On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik 
> <ro...@shaposhnik.org>
> wrote:
> >> I'd also like to be able to review the source referred to in the 
> >> proposal without having to sign up to  "the Pivotal network" - how 
> >> can
> I do that?
> >
> > The issue here is export and license compliance. Unfortunately, 
> > singing up is the only way to go right now. Why is it problematic 
> > for
> you?
>
> The software currently is NOT under ALv2. It is available under the 
> evaluation license. The whole point of the proposal is to make it 
> available under ALv2 as an Incubating project.
>
> Our apologies for making folks click through the evaluation license.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Geode Incubation proposal

[William A Rowe Jr <wr...@rowe-clan.net>]

Ross,

do we evaluate source code at the incubation-entry level, or do we evaluate
proposed development goals and development community propositions? I'm
curious about your thoughts.

Yours,

Bill
On Apr 13, 2015 12:16 AM, "Ross Gardler (MS OPEN TECH)" <
Ross.Gardler@microsoft.com> wrote:

> Pivotal are asking me to agree to an "evaluation license" which I cannot
> view before I sign up. So I have to review the privacy policy first.
>
> Pivotal's privacy policy goes a *long* way beyond the point I am
> comfortable with when getting open source software (or deciding whether I
> want to agree with an evaluation license I can't read). I guess your
> defense could be that it's not open source yet, that's fine, but you are
> asking me, as an IPMC Member, to make a judgement on the validity of the
> proposal but I can't evaluate the code since I can't access it or the
> license under which I am allowed to view it.
>
> Most importantly, the "export and license obligations" you mention are
> something that have to go away before we can accept the project (or more
> accurately before it can graduate). Since I can't evaluate the code or the
> license I have no way of evaluating whether this is possible. There is no
> mention of such an item under "known risks" or the "crypotography" section
> of the proposal so what's this "export" stuff about (assuming the license
> thing is the evaluation license)?
>
> Given the points above I do not see how I can evaluate this proposal in
> its current form.
>
> Ross
>
> -----Original Message-----
> From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of
> Roman Shaposhnik
> Sent: Sunday, April 12, 2015 11:56 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Geode Incubation proposal
>
> Since I'm getting a few off-list questions, I just want to make one point
> clear:
>
> On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >> I'd also like to be able to review the source referred to in the
> >> proposal without having to sign up to  "the Pivotal network" - how can
> I do that?
> >
> > The issue here is export and license compliance. Unfortunately,
> > singing up is the only way to go right now. Why is it problematic for
> you?
>
> The software currently is NOT under ALv2. It is available under the
> evaluation license. The whole point of the proposal is to make it available
> under ALv2 as an Incubating project.
>
> Our apologies for making folks click through the evaluation license.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: [DISCUSS] Geode Incubation proposal

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

Pivotal are asking me to agree to an "evaluation license" which I cannot view before I sign up. So I have to review the privacy policy first.

Pivotal's privacy policy goes a *long* way beyond the point I am comfortable with when getting open source software (or deciding whether I want to agree with an evaluation license I can't read). I guess your defense could be that it's not open source yet, that's fine, but you are asking me, as an IPMC Member, to make a judgement on the validity of the proposal but I can't evaluate the code since I can't access it or the license under which I am allowed to view it.

Most importantly, the "export and license obligations" you mention are something that have to go away before we can accept the project (or more accurately before it can graduate). Since I can't evaluate the code or the license I have no way of evaluating whether this is possible. There is no mention of such an item under "known risks" or the "crypotography" section of the proposal so what's this "export" stuff about (assuming the license thing is the evaluation license)? 

Given the points above I do not see how I can evaluate this proposal in its current form.

Ross

-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
Sent: Sunday, April 12, 2015 11:56 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Geode Incubation proposal

Since I'm getting a few off-list questions, I just want to make one point
clear:

On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> I'd also like to be able to review the source referred to in the 
>> proposal without having to sign up to  "the Pivotal network" - how can I do that?
>
> The issue here is export and license compliance. Unfortunately, 
> singing up is the only way to go right now. Why is it problematic for you?

The software currently is NOT under ALv2. It is available under the evaluation license. The whole point of the proposal is to make it available under ALv2 as an Incubating project.

Our apologies for making folks click through the evaluation license.

Thanks,
Roman.

---------------------------------------------------------------------
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: [DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <ro...@shaposhnik.org>]

Since I'm getting a few off-list questions, I just want to make one point
clear:

On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> I'd also like to be able to review the source referred to in the proposal
>> without having to sign up to  "the Pivotal network" - how can I do that?
>
> The issue here is export and license compliance. Unfortunately, singing
> up is the only way to go right now. Why is it problematic for you?

The software currently is NOT under ALv2. It is available under the
evaluation license. The whole point of the proposal is to make it available
under ALv2 as an Incubating project.

Our apologies for making folks click through the evaluation license.

Thanks,
Roman.

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

Re: [DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Apr 12, 2015 at 8:49 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> Where "hand over the Geode name" also means hand over the domain name and GitHub organizations
> that have rather confusingly been launched in the last few days.

Yup. Everything that's been published on GitHub is going
to transition to ASF once the proposal gets voted in.

> I'd also like to be able to review the source referred to in the proposal
> without having to sign up to  "the Pivotal network" - how can I do that?

The issue here is export and license compliance. Unfortunately, singing
up is the only way to go right now. Why is it problematic for you?

Thanks,
Roman.

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

RE: [DISCUSS] Geode Incubation proposal

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

Where "hand over the Geode name" also means hand over the domain name and GitHub organizations that have rather confusingly been launched in the last few days.

I'd also like to be able to review the source referred to in the proposal without having to sign up to "the Pivotal network" - how can I do that?

Ross

-----Original Message-----
From: John D. Ament [mailto:johndament@apache.org] 
Sent: Sunday, April 12, 2015 1:50 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Geode Incubation proposal

Roman,

Is this the same as Project Geode which seems to be clogging my twitter feed this afternoon?

http://projectgeode.org/

If so, it looks like you already figured out the naming issue.  Is whoever behind this going to hand over the "geode" name to ASF?

John

On Sun, Apr 12, 2015 at 2:47 PM Roman Shaposhnik <rv...@apache.org> wrote:

> Hi!
>
> I would like to open up a discussion thread on the proposals for the 
> core of Pivotal's GemFire to join ASF as an incubating project under 
> the name Geode.
>
> The proposal wiki is available here:
>    https://wiki.apache.org/incubator/GeodeProposal
> and the text of the proposal is attached to the bottom of this email 
> as well.
>
> Given the timing of ApacheCON, we would love to chat with anybody 
> interested in giving us feedback.
> That said, of course, the bulk of the discussion is expected to happen 
> on this thread.
>
> Thanks for your time and consideration!
> Roman (Geode proposal champion and a nominated mentor).
>
> == Abstract ==
> Geode is a data management platform that provides real-time, 
> consistent access to data-intensive applications throughout widely 
> distributed cloud architectures.
>
> Geode pools memory (along with CPU, network and optionally local disk) 
> across multiple processes to manage application objects and behavior.
> It uses dynamic replication and data partitioning techniques for high 
> availability, improved performance, scalability, and fault tolerance.
> Geode is both a distributed data container and an in-memory data 
> management system providing reliable asynchronous event notifications 
> and guaranteed message delivery.
>
> == Proposal ==
> The goal of this proposal is to bring the core of Pivotal Software, 
> Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software 
> Foundation (ASF) in order to build a vibrant, diverse and 
> self-governed open source community around the technology. Pivotal 
> will continue to market and sell Pivotal GemFire based on Geode. Geode 
> and Pivotal GemFire will be managed separately. This proposal covers 
> the Geode source code (mainly written in Java), Geode documentation 
> and other materials currently available on GitHub.
>
> While Geode is our primary choice for a name of the project, in order 
> to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
>   * Haptic
>   * FIG
>
> == Background ==
> GemFire is an extremely mature and robust product that can trace its 
> legacy all the way back to one of the first Object Databases for
> Smalltalk: GemStone. The GemFire code base has been maintained by the 
> same group of engineers as a closed source project. Because of that, 
> even though the engineers behind GemFire are the de-facto knowledge 
> leaders for distributed in-memory management, they have had little
> exposure to the open source governance process.    The original
> company developing GemStone and GemFire was acquired by VMWare in 2010 
> and later spun off as part of Pivotal Software in 2013. Today GemFire 
> is used by over 600 enterprise customers. An example deployment 
> includes China National Railways that uses Pivotal GemFire to run 
> railway ticketing for the entire country of China with a 10 node 
> cluster that manages 2 gigabytes "hot data" in memory, and 10 backup 
> nodes for high availability and elastic scale.
>
> == Rationale ==
> Modern-day data management architectures require a robust in-memory 
> data grid solution to handle a variety of use cases, ranging from 
> enterprise-wide caching to real-time transactional applications at 
> scale. In addition, as memory size and network bandwidth growth 
> continues to outpace those of disk, the importance of managing large 
> pools of RAM at scale increases. It is essential to innovate at the 
> same pace and Pivotal strongly believes that in the Big Data space, 
> this can be optimally achieved through a vibrant, diverse, 
> self-governed community collectively innovating around a single 
> codebase while at the same time cross-pollinating with various other 
> data management communities. ASF is the ideal place to meet these 
> ambitious goals.
>
> == Initial Goals ==
> Our initial goals are to bring Geode into the ASF, transition internal 
> engineering processes into the open, and foster a collaborative 
> development model according to the "Apache Way." Pivotal plans to 
> develop new functionality in an open, community-driven way. To get 
> there, the existing internal build, test and release processes will be 
> refactored to support open development.
>
> == Current Status ==
> Currently, the project code base is licensed for evaluation purposes 
> and is available for download from Pivotal.io 
> (https://network.pivotal.io/products/project-geode). The documentation 
> and wiki pages are available as public GitHub repositories under 
> Project Geode organization on GitHub 
> (https://github.com/project-geode). Although Pivotal GemFire was 
> developed as a proprietary, closed-source product, the internal 
> engineering practices adopted by the development team lend themselves 
> well to an open, collaborative and meritocratic environment.
>
> The Pivotal GemFire team has always focused on building a robust end 
> user community of paying and non-paying customers. The existing 
> documentation along with StackOverflow and other similar forums are 
> expected to facilitate conversions between our existing users so as to 
> transform them into an active community of Geode members, stakeholders 
> and developers.
>
> === Meritocracy ===
> Our proposed list of initial committers include the current GemFire 
> R&D team, Pivotal Field Engineers, and several existing customers and 
> partners. This group will form a base for the broader community we 
> will invite to collaborate on the codebase. We intend to radically 
> expand the initial developer and user community by running the project 
> in accordance with the "Apache Way". Users and new contributors will 
> be treated with respect and welcomed. By participating in the 
> community and providing quality patches/support that move the project 
> forward, they will earn merit. They also will be encouraged to provide 
> non-code contributions (documentation, events, community management,
> etc.) and will gain merit for doing so. Those with a proven support 
> and quality track record will be encouraged to become committers.
>
> === Community ===
> If Geode is accepted for incubation, the primary initial goal will be 
> transitioning the core community towards embracing the Apache Way of 
> project governance. We would solicit major existing contributors to 
> become committers on the project from the start.
>
> === Core Developers ===
>
> While a few core developers are skilled in working in openly governed 
> Apache communities. Most of the core developers are currently NOT 
> affiliated with the ASF and would require new ICLAs before committing 
> to the project.
>
> === Alignment ===
> The following existing ASF projects can be considered when reviewing 
> Geode proposal:
>
> Apache HadoopⓇ is a distributed storage and processing framework for 
> very large datasets focusing primarily on batch processing for 
> analytic purposes. Geode is a data management platform that provides 
> real-time, consistent, and transactional access to data-intensive 
> applications. Our roadmap includes plans to provide close integration 
> with HDFS.
>
> Apache HBase offers tabular data stored in Hadoop based on the Google 
> Bigtable model.  HBase uses a key-based partitioning scheme and column 
> family data model that can work well for scan intensive workloads but 
> is not as broadly applicable as the rich object model, OQL querying, 
> and hash partitioning provided by Geode.  Geode will use the HFile 
> format for storing data in HDFS.
>
> Apache Spark is a fast engine for processing large datasets, typically 
> from a Hadoop cluster, and performing batch, streaming, interactive, 
> or machine learning workloads.  Geode supports high throughput 
> streaming ingest application patterns and data parallel algorithms.
> Geode also ensures that data is highly available through redundancy 
> while Spark recovers from faults using RDD lineage recomputation.  Our 
> roadmap includes plans for providing integration with the Spark 
> platform.
>
> Apache Ignite (incubating) offers distributed in-memory processing 
> capabilities which in some ways overlap with Geode.  However, Geode 
> has been in this field for more than 10 years and the product API's, 
> design, and implementation details are quite different.  In addition, 
> Geode offers highly optimized shared-nothing disk persistence for 
> in-memory data which does not appear to be available with Ignite.
>
> Apache Cassandra is a highly scalable, distributed key-value store 
> that focuses on eventual consistency.  It uses log-structured merge 
> trees to handle write-heavy workloads.  The Geode distributed 
> in-memory cluster provides highly performant and advanced capabilities 
> including network partition detection and recovery, version-based 
> state synchronization and conflict resolution, and single IO disk 
> operations.
>
> Apache ActiveMQ and its sub project Apache Apollo offers a powerful 
> message queue framework that is being considered for an open source 
> implementation of Geode's WAN replication capabilities.
>
> Apache Storm is a streaming engine that processes events through a 
> directed graph of computation. It requires Apache Zookeeper for 
> coordination and Apache Kafka to reliably store the streaming data 
> source. Geode provides builtin capabilities for these functions. In 
> addition, Geode offers data locality for related entities and 
> in-process access to reference data typically used during processing.
>
> Apache Kafka offers distributed and durable publish-subscribe 
> messaging. Geode expands beyond publish-subscribe messaging to support 
> data oriented notifications delivered from highly available, fault 
> tolerant event queues that can be easily correlated to related data 
> for further processing. Apache Samza is a distributed processing 
> framework heavily dependent on Apache Kafka and Apache Hadoop YARN for 
> messaging and distributed fault-tolerant processing.  Geode is data 
> source agnostic and leverages its own technology and implementation 
> for such use cases.
>
> == Known Risks ==
> Development has been sponsored mostly by a single company (or its
> predecessors) thus far and coordinated mainly by the core Pivotal 
> GemFire team.
>
> For the project to fully transition to the Apache Way governance 
> model, development must shift towards the meritocracy-centric model of 
> growing a community of contributors balanced with the needs for 
> extreme stability and core implementation coherency.
>
> The tools and development practices in place for the Pivotal GemFire 
> product are compatible with the ASF infrastructure and thus we do not 
> anticipate any on-boarding pains. Migration from the current GitHub 
> repository is also expected to be straightforward.
>
> The project currently includes a modified version of the JGroups 
> software toolkit. JGroups was initially released under the LGPL 
> license. Although we have complied with the terms of the LGPL by 
> making the modified source available, LGPL is classified as an 
> incompatible license by the ASF.  The JGroups project has since been 
> re-licenced under ALv2 (see http://www.jgroups.org/license.html) and 
> we plan to engage with the licensor to overcome this license 
> incompatibility. If the license incompatibility cannot be overcome 
> through our discussions with the licensor, we will need to rework this 
> portion of the project based upon a newer version of the JGroups 
> toolkit or via other alternative development efforts.
>
> === Orphaned products ===
> Pivotal is fully committed to Pivotal GemFire and the product will 
> continue to be based on the Geode project. Moreover, Pivotal has a 
> vested interest in making Geode succeed by driving its close 
> integration with sister ASF projects. We expect this to further 
> reduces the risk of orphaning the product.
>
> === Inexperience with Open Source ===
> Pivotal has embraced open source software since its formation by 
> employing contributors/committers and by shepherding open source 
> projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Pivotal also 
> supports other open source projects such as Redis, Chorus, Groovy and 
> Grails. We have experience with the formation of vibrant communities 
> around open technologies with the Cloud Foundry Foundation.  Although 
> some of the initial committers have not been developers on an entirely 
> open source, community-driven project, we expect to bring to bear the 
> open development practices that have proven successful on longstanding 
> Pivotal open source projects to the Geode project.  Additionally, 
> several ASF veterans agreed to mentor the project and are listed in 
> this proposal. The project will rely on their guidance and collective 
> wisdom to quickly transition the entire team of initial committers 
> towards practicing the Apache Way.
>
> === Homogeneous Developers ===
> While most of the initial committers are employed by Pivotal, we have 
> already seen a healthy level of interest from our existing customers 
> and partners. We intend to convert that interest directly into 
> participation and will be investing in activities to recruit 
> additional committers from other companies.
>
> === Reliance on Salaried Developers === Most of the contributors are 
> paid to work in the Big Data space. While they might wander from their 
> current employers, they are unlikely to venture far from their core 
> expertises and thus will continue to be engaged with the project 
> regardless of their current employers.
>
> === Relationships with Other Apache Products === As mentioned in the 
> Alignment section, Geode may consider various degrees of integration 
> and code exchange with Apache Ignite (incubating), Apache Hadoop, 
> Apache Storm, Apache Spark and Apache Kafka/Samza. Given the success 
> that the Pivotal GemFire product enjoyed as an embedded service, we 
> expect integration points to be inside and outside the project. We 
> look forward to collaborating with these communities as well as other 
> communities under the Apache umbrella.
>
> === An Excessive Fascination with the Apache Brand === While we intend 
> to leverage the Apache ‘branding’ when talking to other projects as 
> testament of our project’s ‘neutrality’, we have no plans for making 
> use of Apache brand in press releases nor posting billboards 
> advertising acceptance of Geode into Apache Incubator.
>
> == Documentation ==
> See documentation for the current state of the project documentation 
> available as part of the GitHub repository at 
> https://github.com/project-geode/docs and live at 
> http://geode-docs.cfapps.io/
>
> == Initial Source ==
> Pivotal is releasing the source code for Geode under an Evaluation 
> License at https://network.pivotal.io/products/project-geode .  We 
> encourage ASF community members interested in  this proposal to 
> download the source code, review and try out the software.
>
> == Source and Intellectual Property Submission Plan == As soon as 
> Geode is approved to join Apache Incubator, the source code will be 
> transitioned via the Software Grant Agreement onto ASF infrastructure 
> and in turn made available under the Apache License, version 2.0.  We 
> know of no legal encumberments that would inhibit the transfer of 
> source code to the ASF.
>
> == External Dependencies ==
>
> Embedded dependencies (relocated):
>    * json
>    * jgroups
>    * joptsimple
>
> Runtime dependencies:
>    * antlr
>    * classmate
>    * commons-fileupload
>    * commons-io
>    * commons-lang
>    * commons-modeler
>    * fastutil
>    * findbugs annotations
>    * guava
>    * jackson
>    * jansi
>    * javax.activation
>    * javax.mail-api
>    * javax.resource-api
>    * javax.servlet-api
>    * javax.transaction-api
>    * jetty
>    * jline
>    * jna
>    * json4s
>    * log4j
>    * mx4j
>    * paranamer
>    * scala
>    * slf4j
>    * snappy-java
>    * spring
>    * swagger
>
> Module or optional dependencies:
>    * None
>
> Build only dependencies:
>    * None
>
> Test only dependencies:
>    * cglib
>    * hamcrest
>    * jmock
>    * junit
>    * multithreadedtc
>    * objenesis
>
> Cryptography
> N/A
>
> == Required Resources ==
>
> === Mailing lists ===
>   * private@geode.incubator.apache.org (moderated subscriptions)
>   * commits@geode.incubator.apache.org
>   * dev@geode.incubator.apache.org
>   * issues@geode.incubator.apache.org
>   * user@geode.incubator.apache.org
>
> === Git Repository ===
> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>
> === Issue Tracking ===
> JIRA Project Geode (GEODE)
>
> === Other Resources ===
>
> Means of setting up regular builds for Geode on builds.apache.org
>
> == Initial Committers ==
>   * Amey Barve
>   * Adib Saikali
>   * Alan Strait
>   * Amogh Shetkar
>   * Anil Gingade
>   * Anilkumar Gingade
>   * Anthony Baker
>   * Ashvin Agrawal
>   * Asif Shahid
>   * Avinash Dongre
>   * Barry Oglesby
>   * Ben Reser
>   * Bruce Schuchardt
>   * Bruce Szalwinski
>   * Catherine Johnson
>   * Chip Childers
>   * Christian Tzolov
>   * Dan Smith
>   * Darrel Schneider
>   * Dave Muirhead
>   * David Yozie
>   * Dick Cavender
>   * Edin Zulich
>   * Eric Shu
>   * Gideon Low
>   * Greg Chase
>   * Hemant Bhanawat
>   * Henry Saputra
>   * Hitesh Khamesra
>   * Jacob Barrett
>   * Jags Ramnarayan
>   * Jan Iversen
>   * Jason Huynh
>   * Jens Deppe
>   * Jianxia Chen
>   * John Blum
>   * Justin Erenkrantz
>   * Ketan Deshpande
>   * Kirk Lund
>   * Kishor Bachhav
>   * Konstantin Boudnik
>   * Konstantin Ignatyev
>   * Lise Storc
>   * Luke Shannon
>   * Lyndon Adams
>   * Lynn Gallinat
>   * Lynn Hughes-Godfrey
>   * Mark Bretl
>   * Michael Schubert
>   * Namrata Thanvi
>   * Neeraj Kumar
>   * Nilkanth Patel
>   * Qihong Chen
>   * Rahul Diyewar
>   * Randy May
>   * Roman Shaposhnik
>   * Severine Tymon
>   * Shatarupa Nandi
>   * Shirish Deshmukh
>   * Sonal Agarwal
>   * Soubhik Chakraborty
>   * Sourabh Bansod
>   * Stephane Maldini
>   * Stuart Williams
>   * Sudhir Menon
>   * Sunil Jigyasu
>   * Supriya Pillai
>   * Suranjan Kumar
>   * Suyog Bhokare
>   * Swapnil Bawaskar
>   * Swati Sawant
>   * Tushar Khairnar
>   * Udo Kohlmeyer
>   * Vince Ford
>   * Vinesh Prasanna Manoharan
>   * Vivek Bhaskar
>   * Wes Williams
>   * William A. Rowe Jr.
>   * William Markito
>   * Will Schipp
>   * Xiaojian Zhou
>   * Yogesh Mahajan
>
> == Affiliations ==
>   * WANDisco: Konstantin Boudnik
>   * Bloomberg LP: Justin Erenkrantz
>   * Cloud Foundry Foundation: Chip Childers
>   * NASA JPL: Chris Mattmann
>   * Unaffiliated: Jan Iversen
>   * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
>   * Pivotal: everyone else on this proposal
>
> == Sponsors ==
>
> === Champion ===
> Roman Shaposhnik
>
> === Nominated Mentors ===
>
> The initial mentors are listed below:
>   * Chip Childers - Apache Member, Cloud Foundry Foundation
>   * Justin Erenkrantz - Apache Member, Bloomberg LP
>   * Konstantin Boudnik - Apache Member, WANDisco
>   * Jan Iversen - Apache Member, Self employed
>   * William A. Rowe Jr. - Apache Member, Pivotal
>   * Henry Saputra - Apache Member, Pivotal
>   * Roman Shaposhnik - Apache Member, Pivotal
>   * Chris Mattmann - Apache Member, NASA JPL
>
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Apr 12, 2015 at 1:50 PM, John D. Ament <jo...@apache.org> wrote:
> Roman,
>
> Is this the same as Project Geode which seems to be clogging my twitter
> feed this afternoon?

Sorry about that -- we get excited about open source ;-)

> http://projectgeode.org/
>
> If so, it looks like you already figured out the naming issue.  Is whoever
> behind this going to hand over the "geode" name to ASF?

Yes.

Thanks,
Roman.

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

Re: [DISCUSS] Geode Incubation proposal

["John D. Ament" <jo...@apache.org>]

Roman,

Is this the same as Project Geode which seems to be clogging my twitter
feed this afternoon?

http://projectgeode.org/

If so, it looks like you already figured out the naming issue.  Is whoever
behind this going to hand over the "geode" name to ASF?

John

On Sun, Apr 12, 2015 at 2:47 PM Roman Shaposhnik <rv...@apache.org> wrote:

> Hi!
>
> I would like to open up a discussion thread on
> the proposals for the core of Pivotal's GemFire
> to join ASF as an incubating project under the
> name Geode.
>
> The proposal wiki is available here:
>    https://wiki.apache.org/incubator/GeodeProposal
> and the text of the proposal is attached to the
> bottom of this email as well.
>
> Given the timing of ApacheCON, we would love to
> chat with anybody interested in giving us feedback.
> That said, of course, the bulk of the discussion is
> expected to happen on this thread.
>
> Thanks for your time and consideration!
> Roman (Geode proposal champion and a nominated mentor).
>
> == Abstract ==
> Geode is a data management platform that provides real-time,
> consistent access to data-intensive applications throughout widely
> distributed cloud architectures.
>
> Geode pools memory (along with CPU, network and optionally local disk)
> across multiple processes to manage application objects and behavior.
> It uses dynamic replication and data partitioning techniques for high
> availability, improved performance, scalability, and fault tolerance.
> Geode is both a distributed data container and an in-memory data
> management system providing reliable asynchronous event notifications
> and guaranteed message delivery.
>
> == Proposal ==
> The goal of this proposal is to bring the core of Pivotal Software,
> Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
> Foundation (ASF) in order to build a vibrant, diverse and
> self-governed open source community around the technology. Pivotal
> will continue to market and sell Pivotal GemFire based on Geode. Geode
> and Pivotal GemFire will be managed separately. This proposal covers
> the Geode source code (mainly written in Java), Geode documentation
> and other materials currently available on GitHub.
>
> While Geode is our primary choice for a name of the project, in order
> to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
>   * Haptic
>   * FIG
>
> == Background ==
> GemFire is an extremely mature and robust product that can trace its
> legacy all the way back to one of the first Object Databases for
> Smalltalk: GemStone. The GemFire code base has been maintained by the
> same group of engineers as a closed source project. Because of that,
> even though the engineers behind GemFire are the de-facto knowledge
> leaders for distributed in-memory management, they have had little
> exposure to the open source governance process.    The original
> company developing GemStone and GemFire was acquired by VMWare in 2010
> and later spun off as part of Pivotal Software in 2013. Today GemFire
> is used by over 600 enterprise customers. An example deployment
> includes China National Railways that uses Pivotal GemFire to run
> railway ticketing for the entire country of China with a 10 node
> cluster that manages 2 gigabytes "hot data" in memory, and 10 backup
> nodes for high availability and elastic scale.
>
> == Rationale ==
> Modern-day data management architectures require a robust in-memory
> data grid solution to handle a variety of use cases, ranging from
> enterprise-wide caching to real-time transactional applications at
> scale. In addition, as memory size and network bandwidth growth
> continues to outpace those of disk, the importance of managing large
> pools of RAM at scale increases. It is essential to innovate at the
> same pace and Pivotal strongly believes that in the Big Data space,
> this can be optimally achieved through a vibrant, diverse,
> self-governed community collectively innovating around a single
> codebase while at the same time cross-pollinating with various other
> data management communities. ASF is the ideal place to meet these
> ambitious goals.
>
> == Initial Goals ==
> Our initial goals are to bring Geode into the ASF, transition internal
> engineering processes into the open, and foster a collaborative
> development model according to the "Apache Way." Pivotal plans to
> develop new functionality in an open, community-driven way. To get
> there, the existing internal build, test and release processes will be
> refactored to support open development.
>
> == Current Status ==
> Currently, the project code base is licensed for evaluation purposes
> and is available for download from Pivotal.io
> (https://network.pivotal.io/products/project-geode). The documentation
> and wiki pages are available as public GitHub repositories under
> Project Geode organization on GitHub
> (https://github.com/project-geode). Although Pivotal GemFire was
> developed as a proprietary, closed-source product, the internal
> engineering practices adopted by the development team lend themselves
> well to an open, collaborative and meritocratic environment.
>
> The Pivotal GemFire team has always focused on building a robust end
> user community of paying and non-paying customers. The existing
> documentation along with StackOverflow and other similar forums are
> expected to facilitate conversions between our existing users so as to
> transform them into an active community of Geode members, stakeholders
> and developers.
>
> === Meritocracy ===
> Our proposed list of initial committers include the current GemFire
> R&D team, Pivotal Field Engineers, and several existing customers and
> partners. This group will form a base for the broader community we
> will invite to collaborate on the codebase. We intend to radically
> expand the initial developer and user community by running the project
> in accordance with the "Apache Way". Users and new contributors will
> be treated with respect and welcomed. By participating in the
> community and providing quality patches/support that move the project
> forward, they will earn merit. They also will be encouraged to provide
> non-code contributions (documentation, events, community management,
> etc.) and will gain merit for doing so. Those with a proven support
> and quality track record will be encouraged to become committers.
>
> === Community ===
> If Geode is accepted for incubation, the primary initial goal will be
> transitioning the core community towards embracing the Apache Way of
> project governance. We would solicit major existing contributors to
> become committers on the project from the start.
>
> === Core Developers ===
>
> While a few core developers are skilled in working in openly governed
> Apache communities. Most of the core developers are currently NOT
> affiliated with the ASF and would require new ICLAs before committing
> to the project.
>
> === Alignment ===
> The following existing ASF projects can be considered when reviewing
> Geode proposal:
>
> Apache HadoopⓇ is a distributed storage and processing framework for
> very large datasets focusing primarily on batch processing for
> analytic purposes. Geode is a data management platform that provides
> real-time, consistent, and transactional access to data-intensive
> applications. Our roadmap includes plans to provide close integration
> with HDFS.
>
> Apache HBase offers tabular data stored in Hadoop based on the Google
> Bigtable model.  HBase uses a key-based partitioning scheme and column
> family data model that can work well for scan intensive workloads but
> is not as broadly applicable as the rich object model, OQL querying,
> and hash partitioning provided by Geode.  Geode will use the HFile
> format for storing data in HDFS.
>
> Apache Spark is a fast engine for processing large datasets, typically
> from a Hadoop cluster, and performing batch, streaming, interactive,
> or machine learning workloads.  Geode supports high throughput
> streaming ingest application patterns and data parallel algorithms.
> Geode also ensures that data is highly available through redundancy
> while Spark recovers from faults using RDD lineage recomputation.  Our
> roadmap includes plans for providing integration with the Spark
> platform.
>
> Apache Ignite (incubating) offers distributed in-memory processing
> capabilities which in some ways overlap with Geode.  However, Geode
> has been in this field for more than 10 years and the product API's,
> design, and implementation details are quite different.  In addition,
> Geode offers highly optimized shared-nothing disk persistence for
> in-memory data which does not appear to be available with Ignite.
>
> Apache Cassandra is a highly scalable, distributed key-value store
> that focuses on eventual consistency.  It uses log-structured merge
> trees to handle write-heavy workloads.  The Geode distributed
> in-memory cluster provides highly performant and advanced capabilities
> including network partition detection and recovery, version-based
> state synchronization and conflict resolution, and single IO disk
> operations.
>
> Apache ActiveMQ and its sub project Apache Apollo offers a powerful
> message queue framework that is being considered for an open source
> implementation of Geode's WAN replication capabilities.
>
> Apache Storm is a streaming engine that processes events through a
> directed graph of computation. It requires Apache Zookeeper for
> coordination and Apache Kafka to reliably store the streaming data
> source. Geode provides builtin capabilities for these functions. In
> addition, Geode offers data locality for related entities and
> in-process access to reference data typically used during processing.
>
> Apache Kafka offers distributed and durable publish-subscribe
> messaging. Geode expands beyond publish-subscribe messaging to support
> data oriented notifications delivered from highly available, fault
> tolerant event queues that can be easily correlated to related data
> for further processing. Apache Samza is a distributed processing
> framework heavily dependent on Apache Kafka and Apache Hadoop YARN for
> messaging and distributed fault-tolerant processing.  Geode is data
> source agnostic and leverages its own technology and implementation
> for such use cases.
>
> == Known Risks ==
> Development has been sponsored mostly by a single company (or its
> predecessors) thus far and coordinated mainly by the core Pivotal
> GemFire team.
>
> For the project to fully transition to the Apache Way governance
> model, development must shift towards the meritocracy-centric model of
> growing a community of contributors balanced with the needs for
> extreme stability and core implementation coherency.
>
> The tools and development practices in place for the Pivotal GemFire
> product are compatible with the ASF infrastructure and thus we do not
> anticipate any on-boarding pains. Migration from the current GitHub
> repository is also expected to be straightforward.
>
> The project currently includes a modified version of the JGroups
> software toolkit. JGroups was initially released under the LGPL
> license. Although we have complied with the terms of the LGPL by
> making the modified source available, LGPL is classified as an
> incompatible license by the ASF.  The JGroups project has since been
> re-licenced under ALv2 (see http://www.jgroups.org/license.html) and
> we plan to engage with the licensor to overcome this license
> incompatibility. If the license incompatibility cannot be overcome
> through our discussions with the licensor, we will need to rework this
> portion of the project based upon a newer version of the JGroups
> toolkit or via other alternative development efforts.
>
> === Orphaned products ===
> Pivotal is fully committed to Pivotal GemFire and the product will
> continue to be based on the Geode project. Moreover, Pivotal has a
> vested interest in making Geode succeed by driving its close
> integration with sister ASF projects. We expect this to further
> reduces the risk of orphaning the product.
>
> === Inexperience with Open Source ===
> Pivotal has embraced open source software since its formation by
> employing contributors/committers and by shepherding open source
> projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Pivotal also
> supports other open source projects such as Redis, Chorus, Groovy and
> Grails. We have experience with the formation of vibrant communities
> around open technologies with the Cloud Foundry Foundation.  Although
> some of the initial committers have not been developers on an entirely
> open source, community-driven project, we expect to bring to bear the
> open development practices that have proven successful on longstanding
> Pivotal open source projects to the Geode project.  Additionally,
> several ASF veterans agreed to mentor the project and are listed in
> this proposal. The project will rely on their guidance and collective
> wisdom to quickly transition the entire team of initial committers
> towards practicing the Apache Way.
>
> === Homogeneous Developers ===
> While most of the initial committers are employed by Pivotal, we have
> already seen a healthy level of interest from our existing customers
> and partners. We intend to convert that interest directly into
> participation and will be investing in activities to recruit
> additional committers from other companies.
>
> === Reliance on Salaried Developers ===
> Most of the contributors are paid to work in the Big Data space. While
> they might wander from their current employers, they are unlikely to
> venture far from their core expertises and thus will continue to be
> engaged with the project regardless of their current employers.
>
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, Geode may consider various
> degrees of integration and code exchange with Apache Ignite
> (incubating), Apache Hadoop, Apache Storm, Apache Spark and Apache
> Kafka/Samza. Given the success that the Pivotal GemFire product
> enjoyed as an embedded service, we expect integration points to be
> inside and outside the project. We look forward to collaborating with
> these communities as well as other communities under the Apache
> umbrella.
>
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of Geode into Apache Incubator.
>
> == Documentation ==
> See documentation for the current state of the project documentation
> available as part of the GitHub repository at
> https://github.com/project-geode/docs and live at
> http://geode-docs.cfapps.io/
>
> == Initial Source ==
> Pivotal is releasing the source code for Geode under an Evaluation
> License at https://network.pivotal.io/products/project-geode .  We
> encourage ASF community members interested in  this proposal to
> download the source code, review and try out the software.
>
> == Source and Intellectual Property Submission Plan ==
> As soon as Geode is approved to join Apache Incubator, the source code
> will be transitioned via the Software Grant Agreement onto ASF
> infrastructure and in turn made available under the Apache License,
> version 2.0.  We know of no legal encumberments that would inhibit the
> transfer of source code to the ASF.
>
> == External Dependencies ==
>
> Embedded dependencies (relocated):
>    * json
>    * jgroups
>    * joptsimple
>
> Runtime dependencies:
>    * antlr
>    * classmate
>    * commons-fileupload
>    * commons-io
>    * commons-lang
>    * commons-modeler
>    * fastutil
>    * findbugs annotations
>    * guava
>    * jackson
>    * jansi
>    * javax.activation
>    * javax.mail-api
>    * javax.resource-api
>    * javax.servlet-api
>    * javax.transaction-api
>    * jetty
>    * jline
>    * jna
>    * json4s
>    * log4j
>    * mx4j
>    * paranamer
>    * scala
>    * slf4j
>    * snappy-java
>    * spring
>    * swagger
>
> Module or optional dependencies:
>    * None
>
> Build only dependencies:
>    * None
>
> Test only dependencies:
>    * cglib
>    * hamcrest
>    * jmock
>    * junit
>    * multithreadedtc
>    * objenesis
>
> Cryptography
> N/A
>
> == Required Resources ==
>
> === Mailing lists ===
>   * private@geode.incubator.apache.org (moderated subscriptions)
>   * commits@geode.incubator.apache.org
>   * dev@geode.incubator.apache.org
>   * issues@geode.incubator.apache.org
>   * user@geode.incubator.apache.org
>
> === Git Repository ===
> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>
> === Issue Tracking ===
> JIRA Project Geode (GEODE)
>
> === Other Resources ===
>
> Means of setting up regular builds for Geode on builds.apache.org
>
> == Initial Committers ==
>   * Amey Barve
>   * Adib Saikali
>   * Alan Strait
>   * Amogh Shetkar
>   * Anil Gingade
>   * Anilkumar Gingade
>   * Anthony Baker
>   * Ashvin Agrawal
>   * Asif Shahid
>   * Avinash Dongre
>   * Barry Oglesby
>   * Ben Reser
>   * Bruce Schuchardt
>   * Bruce Szalwinski
>   * Catherine Johnson
>   * Chip Childers
>   * Christian Tzolov
>   * Dan Smith
>   * Darrel Schneider
>   * Dave Muirhead
>   * David Yozie
>   * Dick Cavender
>   * Edin Zulich
>   * Eric Shu
>   * Gideon Low
>   * Greg Chase
>   * Hemant Bhanawat
>   * Henry Saputra
>   * Hitesh Khamesra
>   * Jacob Barrett
>   * Jags Ramnarayan
>   * Jan Iversen
>   * Jason Huynh
>   * Jens Deppe
>   * Jianxia Chen
>   * John Blum
>   * Justin Erenkrantz
>   * Ketan Deshpande
>   * Kirk Lund
>   * Kishor Bachhav
>   * Konstantin Boudnik
>   * Konstantin Ignatyev
>   * Lise Storc
>   * Luke Shannon
>   * Lyndon Adams
>   * Lynn Gallinat
>   * Lynn Hughes-Godfrey
>   * Mark Bretl
>   * Michael Schubert
>   * Namrata Thanvi
>   * Neeraj Kumar
>   * Nilkanth Patel
>   * Qihong Chen
>   * Rahul Diyewar
>   * Randy May
>   * Roman Shaposhnik
>   * Severine Tymon
>   * Shatarupa Nandi
>   * Shirish Deshmukh
>   * Sonal Agarwal
>   * Soubhik Chakraborty
>   * Sourabh Bansod
>   * Stephane Maldini
>   * Stuart Williams
>   * Sudhir Menon
>   * Sunil Jigyasu
>   * Supriya Pillai
>   * Suranjan Kumar
>   * Suyog Bhokare
>   * Swapnil Bawaskar
>   * Swati Sawant
>   * Tushar Khairnar
>   * Udo Kohlmeyer
>   * Vince Ford
>   * Vinesh Prasanna Manoharan
>   * Vivek Bhaskar
>   * Wes Williams
>   * William A. Rowe Jr.
>   * William Markito
>   * Will Schipp
>   * Xiaojian Zhou
>   * Yogesh Mahajan
>
> == Affiliations ==
>   * WANDisco: Konstantin Boudnik
>   * Bloomberg LP: Justin Erenkrantz
>   * Cloud Foundry Foundation: Chip Childers
>   * NASA JPL: Chris Mattmann
>   * Unaffiliated: Jan Iversen
>   * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
>   * Pivotal: everyone else on this proposal
>
> == Sponsors ==
>
> === Champion ===
> Roman Shaposhnik
>
> === Nominated Mentors ===
>
> The initial mentors are listed below:
>   * Chip Childers - Apache Member, Cloud Foundry Foundation
>   * Justin Erenkrantz - Apache Member, Bloomberg LP
>   * Konstantin Boudnik - Apache Member, WANDisco
>   * Jan Iversen - Apache Member, Self employed
>   * William A. Rowe Jr. - Apache Member, Pivotal
>   * Henry Saputra - Apache Member, Pivotal
>   * Roman Shaposhnik - Apache Member, Pivotal
>   * Chris Mattmann - Apache Member, NASA JPL
>
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Geode Incubation proposal

[Niclas Hedhman <ni...@hedhman.org>]

+1 for Geode accepted into Incubator.

It shouldn't be a big issue whether the codebase is available or not at the
moment. It is part of incubation to shape it up to an open source project,
that doesn't have to happen a priori (can't recall that Google Wave was
available as OSS before coming to ASF, but I could remember wrongly)

Anyway, looking forward to see this being accepted.

// Niclas

On Tue, Apr 14, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> On Mon, Apr 13, 2015 at 11:42 AM, jan i <ja...@apache.org> wrote:
> > On 13 April 2015 at 19:19, Greg Chase <gc...@pivotal.io> wrote:
> >
> >> jan i <jani <at> apache.org> writes:
> >>
> >> >
> >> > On Sunday, April 12, 2015, dsh <daniel.haischt <at> gmail.com> wrote:
> >> >
> >> > > Just as a quick remark. Geode might be a trademark owned by AMD:
> >> > > http://en.wikipedia.org/wiki/Geode_%28processor%29
> >> >
> >> > Good catch, we need to hear the opinion of trademark <at>  because it
> >> depend on
> >> > it is in an overlapping field (as I understood it). F.x. Corinthia is
> >> > registered as a print font and hotel chain, but that was not a
> problem.
> >> >
> >> > I think it is a good proposal and the project seems to have good
> chances
> >> of
> >> > growing under the wings of apache.
> >> >
> >> > rgds
> >> > jan i
> >> >
> >>
> >>
> >> The name "Geode" was thought up by the Geode contributors at Pivotal.
> >>
> >> Pivotal legal did a pretty extensive trademark search to ensure there
> would
> >> be no infringement.  It was their opinion that there  is low risk of
> >> trademark
> >> infringement with the AMD product.
> >>
> >> However, its fully understandable that Apache legal needs to vet the
> name
> >> of the project should it be accepted for incubation.
> >>
> >
> > Thanks for the explanation, that was what I expected, but since a slight
> > concern has
> > been raised, I have the following proposal.
> >
> > Get a statement from Pivotal legal, what they have done, and add it to
> the
> > proposal.
> >
> > That will also give ASF trademark (not legal) a stepping stone.
>
> I guess at this point I'm not sure what level of specific details
> would be required.
> Like I said: Pivotal has done a trademark clearance search to determine
> whether
> the Geode name was available for use. The determination was that it is ok
> to
> use it.
>
> Of course, ASF always has to do a PODLINGNAMESEARCH before blessing
> the name and we fully expect this to be the case here. I am not saying that
> we somehow replaced that step. All I am saying is that chances of Geode
> passing PODLINGNAMESEARCH are high. But that's just one company's
> opinion.
>
> Not sure what other level of details needs to be communicated. If somebody
> can jump in and tell me specifics -- that would be appreciated.
>
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

Re: [DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Mon, Apr 13, 2015 at 11:42 AM, jan i <ja...@apache.org> wrote:
> On 13 April 2015 at 19:19, Greg Chase <gc...@pivotal.io> wrote:
>
>> jan i <jani <at> apache.org> writes:
>>
>> >
>> > On Sunday, April 12, 2015, dsh <daniel.haischt <at> gmail.com> wrote:
>> >
>> > > Just as a quick remark. Geode might be a trademark owned by AMD:
>> > > http://en.wikipedia.org/wiki/Geode_%28processor%29
>> >
>> > Good catch, we need to hear the opinion of trademark <at>  because it
>> depend on
>> > it is in an overlapping field (as I understood it). F.x. Corinthia is
>> > registered as a print font and hotel chain, but that was not a problem.
>> >
>> > I think it is a good proposal and the project seems to have good chances
>> of
>> > growing under the wings of apache.
>> >
>> > rgds
>> > jan i
>> >
>>
>>
>> The name "Geode" was thought up by the Geode contributors at Pivotal.
>>
>> Pivotal legal did a pretty extensive trademark search to ensure there would
>> be no infringement.  It was their opinion that there  is low risk of
>> trademark
>> infringement with the AMD product.
>>
>> However, its fully understandable that Apache legal needs to vet the name
>> of the project should it be accepted for incubation.
>>
>
> Thanks for the explanation, that was what I expected, but since a slight
> concern has
> been raised, I have the following proposal.
>
> Get a statement from Pivotal legal, what they have done, and add it to the
> proposal.
>
> That will also give ASF trademark (not legal) a stepping stone.

I guess at this point I'm not sure what level of specific details
would be required.
Like I said: Pivotal has done a trademark clearance search to determine whether
the Geode name was available for use. The determination was that it is ok to
use it.

Of course, ASF always has to do a PODLINGNAMESEARCH before blessing
the name and we fully expect this to be the case here. I am not saying that
we somehow replaced that step. All I am saying is that chances of Geode
passing PODLINGNAMESEARCH are high. But that's just one company's
opinion.

Not sure what other level of details needs to be communicated. If somebody
can jump in and tell me specifics -- that would be appreciated.


Thanks,
Roman.

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

Re: [DISCUSS] Geode Incubation proposal

[jan i <ja...@apache.org>]

On 13 April 2015 at 19:19, Greg Chase <gc...@pivotal.io> wrote:

> jan i <jani <at> apache.org> writes:
>
> >
> > On Sunday, April 12, 2015, dsh <daniel.haischt <at> gmail.com> wrote:
> >
> > > Just as a quick remark. Geode might be a trademark owned by AMD:
> > > http://en.wikipedia.org/wiki/Geode_%28processor%29
> >
> > Good catch, we need to hear the opinion of trademark <at>  because it
> depend on
> > it is in an overlapping field (as I understood it). F.x. Corinthia is
> > registered as a print font and hotel chain, but that was not a problem.
> >
> > I think it is a good proposal and the project seems to have good chances
> of
> > growing under the wings of apache.
> >
> > rgds
> > jan i
> >
>
>
> The name "Geode" was thought up by the Geode contributors at Pivotal.
>
> Pivotal legal did a pretty extensive trademark search to ensure there would
> be no infringement.  It was their opinion that there  is low risk of
> trademark
> infringement with the AMD product.
>
> However, its fully understandable that Apache legal needs to vet the name
> of the project should it be accepted for incubation.
>

Thanks for the explanation, that was what I expected, but since a slight
concern has
been raised, I have the following proposal.

Get a statement from Pivotal legal, what they have done, and add it to the
proposal.

That will also give ASF trademark (not legal) a stepping stone.

rgds
jan I.


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

Re: [DISCUSS] Geode Incubation proposal

[Greg Chase <gc...@pivotal.io>]

jan i <jani <at> apache.org> writes:

> 
> On Sunday, April 12, 2015, dsh <daniel.haischt <at> gmail.com> wrote:
> 
> > Just as a quick remark. Geode might be a trademark owned by AMD:
> > http://en.wikipedia.org/wiki/Geode_%28processor%29
> 
> Good catch, we need to hear the opinion of trademark <at>  because it depend on
> it is in an overlapping field (as I understood it). F.x. Corinthia is
> registered as a print font and hotel chain, but that was not a problem.
> 
> I think it is a good proposal and the project seems to have good chances of
> growing under the wings of apache.
> 
> rgds
> jan i
> 


The name "Geode" was thought up by the Geode contributors at Pivotal.  

Pivotal legal did a pretty extensive trademark search to ensure there would 
be no infringement.  It was their opinion that there  is low risk of trademark 
infringement with the AMD product.

However, its fully understandable that Apache legal needs to vet the name 
of the project should it be accepted for incubation.


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

Re: [DISCUSS] Geode Incubation proposal

[jan i <ja...@apache.org>]

On Sunday, April 12, 2015, dsh <da...@gmail.com> wrote:

> Just as a quick remark. Geode might be a trademark owned by AMD:
> http://en.wikipedia.org/wiki/Geode_%28processor%29


Good catch, we need to hear the opinion of trademark@ because it depend on
it is in an overlapping field (as I understood it). F.x. Corinthia is
registered as a print font and hotel chain, but that was not a problem.

I think it is a good proposal and the project seems to have good chances of
growing under the wings of apache.

rgds
jan i

>
> Cheers
> Daniel
>
> On Sun, Apr 12, 2015 at 8:46 PM, Roman Shaposhnik <rvs@apache.org
> <javascript:;>> wrote:
>
> > Hi!
> >
> > I would like to open up a discussion thread on
> > the proposals for the core of Pivotal's GemFire
> > to join ASF as an incubating project under the
> > name Geode.
> >
> > The proposal wiki is available here:
> >    https://wiki.apache.org/incubator/GeodeProposal
> > and the text of the proposal is attached to the
> > bottom of this email as well.
> >
> > Given the timing of ApacheCON, we would love to
> > chat with anybody interested in giving us feedback.
> > That said, of course, the bulk of the discussion is
> > expected to happen on this thread.
> >
> > Thanks for your time and consideration!
> > Roman (Geode proposal champion and a nominated mentor).
> >
> > == Abstract ==
> > Geode is a data management platform that provides real-time,
> > consistent access to data-intensive applications throughout widely
> > distributed cloud architectures.
> >
> > Geode pools memory (along with CPU, network and optionally local disk)
> > across multiple processes to manage application objects and behavior.
> > It uses dynamic replication and data partitioning techniques for high
> > availability, improved performance, scalability, and fault tolerance.
> > Geode is both a distributed data container and an in-memory data
> > management system providing reliable asynchronous event notifications
> > and guaranteed message delivery.
> >
> > == Proposal ==
> > The goal of this proposal is to bring the core of Pivotal Software,
> > Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
> > Foundation (ASF) in order to build a vibrant, diverse and
> > self-governed open source community around the technology. Pivotal
> > will continue to market and sell Pivotal GemFire based on Geode. Geode
> > and Pivotal GemFire will be managed separately. This proposal covers
> > the Geode source code (mainly written in Java), Geode documentation
> > and other materials currently available on GitHub.
> >
> > While Geode is our primary choice for a name of the project, in order
> > to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
> >   * Haptic
> >   * FIG
> >
> > == Background ==
> > GemFire is an extremely mature and robust product that can trace its
> > legacy all the way back to one of the first Object Databases for
> > Smalltalk: GemStone. The GemFire code base has been maintained by the
> > same group of engineers as a closed source project. Because of that,
> > even though the engineers behind GemFire are the de-facto knowledge
> > leaders for distributed in-memory management, they have had little
> > exposure to the open source governance process.    The original
> > company developing GemStone and GemFire was acquired by VMWare in 2010
> > and later spun off as part of Pivotal Software in 2013. Today GemFire
> > is used by over 600 enterprise customers. An example deployment
> > includes China National Railways that uses Pivotal GemFire to run
> > railway ticketing for the entire country of China with a 10 node
> > cluster that manages 2 gigabytes "hot data" in memory, and 10 backup
> > nodes for high availability and elastic scale.
> >
> > == Rationale ==
> > Modern-day data management architectures require a robust in-memory
> > data grid solution to handle a variety of use cases, ranging from
> > enterprise-wide caching to real-time transactional applications at
> > scale. In addition, as memory size and network bandwidth growth
> > continues to outpace those of disk, the importance of managing large
> > pools of RAM at scale increases. It is essential to innovate at the
> > same pace and Pivotal strongly believes that in the Big Data space,
> > this can be optimally achieved through a vibrant, diverse,
> > self-governed community collectively innovating around a single
> > codebase while at the same time cross-pollinating with various other
> > data management communities. ASF is the ideal place to meet these
> > ambitious goals.
> >
> > == Initial Goals ==
> > Our initial goals are to bring Geode into the ASF, transition internal
> > engineering processes into the open, and foster a collaborative
> > development model according to the "Apache Way." Pivotal plans to
> > develop new functionality in an open, community-driven way. To get
> > there, the existing internal build, test and release processes will be
> > refactored to support open development.
> >
> > == Current Status ==
> > Currently, the project code base is licensed for evaluation purposes
> > and is available for download from Pivotal.io
> > (https://network.pivotal.io/products/project-geode). The documentation
> > and wiki pages are available as public GitHub repositories under
> > Project Geode organization on GitHub
> > (https://github.com/project-geode). Although Pivotal GemFire was
> > developed as a proprietary, closed-source product, the internal
> > engineering practices adopted by the development team lend themselves
> > well to an open, collaborative and meritocratic environment.
> >
> > The Pivotal GemFire team has always focused on building a robust end
> > user community of paying and non-paying customers. The existing
> > documentation along with StackOverflow and other similar forums are
> > expected to facilitate conversions between our existing users so as to
> > transform them into an active community of Geode members, stakeholders
> > and developers.
> >
> > === Meritocracy ===
> > Our proposed list of initial committers include the current GemFire
> > R&D team, Pivotal Field Engineers, and several existing customers and
> > partners. This group will form a base for the broader community we
> > will invite to collaborate on the codebase. We intend to radically
> > expand the initial developer and user community by running the project
> > in accordance with the "Apache Way". Users and new contributors will
> > be treated with respect and welcomed. By participating in the
> > community and providing quality patches/support that move the project
> > forward, they will earn merit. They also will be encouraged to provide
> > non-code contributions (documentation, events, community management,
> > etc.) and will gain merit for doing so. Those with a proven support
> > and quality track record will be encouraged to become committers.
> >
> > === Community ===
> > If Geode is accepted for incubation, the primary initial goal will be
> > transitioning the core community towards embracing the Apache Way of
> > project governance. We would solicit major existing contributors to
> > become committers on the project from the start.
> >
> > === Core Developers ===
> >
> > While a few core developers are skilled in working in openly governed
> > Apache communities. Most of the core developers are currently NOT
> > affiliated with the ASF and would require new ICLAs before committing
> > to the project.
> >
> > === Alignment ===
> > The following existing ASF projects can be considered when reviewing
> > Geode proposal:
> >
> > Apache HadoopⓇ is a distributed storage and processing framework for
> > very large datasets focusing primarily on batch processing for
> > analytic purposes. Geode is a data management platform that provides
> > real-time, consistent, and transactional access to data-intensive
> > applications. Our roadmap includes plans to provide close integration
> > with HDFS.
> >
> > Apache HBase offers tabular data stored in Hadoop based on the Google
> > Bigtable model.  HBase uses a key-based partitioning scheme and column
> > family data model that can work well for scan intensive workloads but
> > is not as broadly applicable as the rich object model, OQL querying,
> > and hash partitioning provided by Geode.  Geode will use the HFile
> > format for storing data in HDFS.
> >
> > Apache Spark is a fast engine for processing large datasets, typically
> > from a Hadoop cluster, and performing batch, streaming, interactive,
> > or machine learning workloads.  Geode supports high throughput
> > streaming ingest application patterns and data parallel algorithms.
> > Geode also ensures that data is highly available through redundancy
> > while Spark recovers from faults using RDD lineage recomputation.  Our
> > roadmap includes plans for providing integration with the Spark
> > platform.
> >
> > Apache Ignite (incubating) offers distributed in-memory processing
> > capabilities which in some ways overlap with Geode.  However, Geode
> > has been in this field for more than 10 years and the product API's,
> > design, and implementation details are quite different.  In addition,
> > Geode offers highly optimized shared-nothing disk persistence for
> > in-memory data which does not appear to be available with Ignite.
> >
> > Apache Cassandra is a highly scalable, distributed key-value store
> > that focuses on eventual consistency.  It uses log-structured merge
> > trees to handle write-heavy workloads.  The Geode distributed
> > in-memory cluster provides highly performant and advanced capabilities
> > including network partition detection and recovery, version-based
> > state synchronization and conflict resolution, and single IO disk
> > operations.
> >
> > Apache ActiveMQ and its sub project Apache Apollo offers a powerful
> > message queue framework that is being considered for an open source
> > implementation of Geode's WAN replication capabilities.
> >
> > Apache Storm is a streaming engine that processes events through a
> > directed graph of computation. It requires Apache Zookeeper for
> > coordination and Apache Kafka to reliably store the streaming data
> > source. Geode provides builtin capabilities for these functions. In
> > addition, Geode offers data locality for related entities and
> > in-process access to reference data typically used during processing.
> >
> > Apache Kafka offers distributed and durable publish-subscribe
> > messaging. Geode expands beyond publish-subscribe messaging to support
> > data oriented notifications delivered from highly available, fault
> > tolerant event queues that can be easily correlated to related data
> > for further processing. Apache Samza is a distributed processing
> > framework heavily dependent on Apache Kafka and Apache Hadoop YARN for
> > messaging and distributed fault-tolerant processing.  Geode is data
> > source agnostic and leverages its own technology and implementation
> > for such use cases.
> >
> > == Known Risks ==
> > Development has been sponsored mostly by a single company (or its
> > predecessors) thus far and coordinated mainly by the core Pivotal
> > GemFire team.
> >
> > For the project to fully transition to the Apache Way governance
> > model, development must shift towards the meritocracy-centric model of
> > growing a community of contributors balanced with the needs for
> > extreme stability and core implementation coherency.
> >
> > The tools and development practices in place for the Pivotal GemFire
> > product are compatible with the ASF infrastructure and thus we do not
> > anticipate any on-boarding pains. Migration from the current GitHub
> > repository is also expected to be straightforward.
> >
> > The project currently includes a modified version of the JGroups
> > software toolkit. JGroups was initially released under the LGPL
> > license. Although we have complied with the terms of the LGPL by
> > making the modified source available, LGPL is classified as an
> > incompatible license by the ASF.  The JGroups project has since been
> > re-licenced under ALv2 (see http://www.jgroups.org/license.html) and
> > we plan to engage with the licensor to overcome this license
> > incompatibility. If the license incompatibility cannot be overcome
> > through our discussions with the licensor, we will need to rework this
> > portion of the project based upon a newer version of the JGroups
> > toolkit or via other alternative development efforts.
> >
> > === Orphaned products ===
> > Pivotal is fully committed to Pivotal GemFire and the product will
> > continue to be based on the Geode project. Moreover, Pivotal has a
> > vested interest in making Geode succeed by driving its close
> > integration with sister ASF projects. We expect this to further
> > reduces the risk of orphaning the product.
> >
> > === Inexperience with Open Source ===
> > Pivotal has embraced open source software since its formation by
> > employing contributors/committers and by shepherding open source
> > projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Pivotal also
> > supports other open source projects such as Redis, Chorus, Groovy and
> > Grails. We have experience with the formation of vibrant communities
> > around open technologies with the Cloud Foundry Foundation.  Although
> > some of the initial committers have not been developers on an entirely
> > open source, community-driven project, we expect to bring to bear the
> > open development practices that have proven successful on longstanding
> > Pivotal open source projects to the Geode project.  Additionally,
> > several ASF veterans agreed to mentor the project and are listed in
> > this proposal. The project will rely on their guidance and collective
> > wisdom to quickly transition the entire team of initial committers
> > towards practicing the Apache Way.
> >
> > === Homogeneous Developers ===
> > While most of the initial committers are employed by Pivotal, we have
> > already seen a healthy level of interest from our existing customers
> > and partners. We intend to convert that interest directly into
> > participation and will be investing in activities to recruit
> > additional committers from other companies.
> >
> > === Reliance on Salaried Developers ===
> > Most of the contributors are paid to work in the Big Data space. While
> > they might wander from their current employers, they are unlikely to
> > venture far from their core expertises and thus will continue to be
> > engaged with the project regardless of their current employers.
> >
> > === Relationships with Other Apache Products ===
> > As mentioned in the Alignment section, Geode may consider various
> > degrees of integration and code exchange with Apache Ignite
> > (incubating), Apache Hadoop, Apache Storm, Apache Spark and Apache
> > Kafka/Samza. Given the success that the Pivotal GemFire product
> > enjoyed as an embedded service, we expect integration points to be
> > inside and outside the project. We look forward to collaborating with
> > these communities as well as other communities under the Apache
> > umbrella.
> >
> > === An Excessive Fascination with the Apache Brand ===
> > While we intend to leverage the Apache ‘branding’ when talking to
> > other projects as testament of our project’s ‘neutrality’, we have no
> > plans for making use of Apache brand in press releases nor posting
> > billboards advertising acceptance of Geode into Apache Incubator.
> >
> > == Documentation ==
> > See documentation for the current state of the project documentation
> > available as part of the GitHub repository at
> > https://github.com/project-geode/docs and live at
> > http://geode-docs.cfapps.io/
> >
> > == Initial Source ==
> > Pivotal is releasing the source code for Geode under an Evaluation
> > License at https://network.pivotal.io/products/project-geode .  We
> > encourage ASF community members interested in  this proposal to
> > download the source code, review and try out the software.
> >
> > == Source and Intellectual Property Submission Plan ==
> > As soon as Geode is approved to join Apache Incubator, the source code
> > will be transitioned via the Software Grant Agreement onto ASF
> > infrastructure and in turn made available under the Apache License,
> > version 2.0.  We know of no legal encumberments that would inhibit the
> > transfer of source code to the ASF.
> >
> > == External Dependencies ==
> >
> > Embedded dependencies (relocated):
> >    * json
> >    * jgroups
> >    * joptsimple
> >
> > Runtime dependencies:
> >    * antlr
> >    * classmate
> >    * commons-fileupload
> >    * commons-io
> >    * commons-lang
> >    * commons-modeler
> >    * fastutil
> >    * findbugs annotations
> >    * guava
> >    * jackson
> >    * jansi
> >    * javax.activation
> >    * javax.mail-api
> >    * javax.resource-api
> >    * javax.servlet-api
> >    * javax.transaction-api
> >    * jetty
> >    * jline
> >    * jna
> >    * json4s
> >    * log4j
> >    * mx4j
> >    * paranamer
> >    * scala
> >    * slf4j
> >    * snappy-java
> >    * spring
> >    * swagger
> >
> > Module or optional dependencies:
> >    * None
> >
> > Build only dependencies:
> >    * None
> >
> > Test only dependencies:
> >    * cglib
> >    * hamcrest
> >    * jmock
> >    * junit
> >    * multithreadedtc
> >    * objenesis
> >
> > Cryptography
> > N/A
> >
> > == Required Resources ==
> >
> > === Mailing lists ===
> >   * private@geode.incubator.apache.org <javascript:;> (moderated
> subscriptions)
> >   * commits@geode.incubator.apache.org <javascript:;>
> >   * dev@geode.incubator.apache.org <javascript:;>
> >   * issues@geode.incubator.apache.org <javascript:;>
> >   * user@geode.incubator.apache.org <javascript:;>
> >
> > === Git Repository ===
> > https://git-wip-us.apache.org/repos/asf/incubator-geode.git
> >
> > === Issue Tracking ===
> > JIRA Project Geode (GEODE)
> >
> > === Other Resources ===
> >
> > Means of setting up regular builds for Geode on builds.apache.org
> >
> > == Initial Committers ==
> >   * Amey Barve
> >   * Adib Saikali
> >   * Alan Strait
> >   * Amogh Shetkar
> >   * Anil Gingade
> >   * Anilkumar Gingade
> >   * Anthony Baker
> >   * Ashvin Agrawal
> >   * Asif Shahid
> >   * Avinash Dongre
> >   * Barry Oglesby
> >   * Ben Reser
> >   * Bruce Schuchardt
> >   * Bruce Szalwinski
> >   * Catherine Johnson
> >   * Chip Childers
> >   * Christian Tzolov
> >   * Dan Smith
> >   * Darrel Schneider
> >   * Dave Muirhead
> >   * David Yozie
> >   * Dick Cavender
> >   * Edin Zulich
> >   * Eric Shu
> >   * Gideon Low
> >   * Greg Chase
> >   * Hemant Bhanawat
> >   * Henry Saputra
> >   * Hitesh Khamesra
> >   * Jacob Barrett
> >   * Jags Ramnarayan
> >   * Jan Iversen
> >   * Jason Huynh
> >   * Jens Deppe
> >   * Jianxia Chen
> >   * John Blum
> >   * Justin Erenkrantz
> >   * Ketan Deshpande
> >   * Kirk Lund
> >   * Kishor Bachhav
> >   * Konstantin Boudnik
> >   * Konstantin Ignatyev
> >   * Lise Storc
> >   * Luke Shannon
> >   * Lyndon Adams
> >   * Lynn Gallinat
> >   * Lynn Hughes-Godfrey
> >   * Mark Bretl
> >   * Michael Schubert
> >   * Namrata Thanvi
> >   * Neeraj Kumar
> >   * Nilkanth Patel
> >   * Qihong Chen
> >   * Rahul Diyewar
> >   * Randy May
> >   * Roman Shaposhnik
> >   * Severine Tymon
> >   * Shatarupa Nandi
> >   * Shirish Deshmukh
> >   * Sonal Agarwal
> >   * Soubhik Chakraborty
> >   * Sourabh Bansod
> >   * Stephane Maldini
> >   * Stuart Williams
> >   * Sudhir Menon
> >   * Sunil Jigyasu
> >   * Supriya Pillai
> >   * Suranjan Kumar
> >   * Suyog Bhokare
> >   * Swapnil Bawaskar
> >   * Swati Sawant
> >   * Tushar Khairnar
> >   * Udo Kohlmeyer
> >   * Vince Ford
> >   * Vinesh Prasanna Manoharan
> >   * Vivek Bhaskar
> >   * Wes Williams
> >   * William A. Rowe Jr.
> >   * William Markito
> >   * Will Schipp
> >   * Xiaojian Zhou
> >   * Yogesh Mahajan
> >
> > == Affiliations ==
> >   * WANDisco: Konstantin Boudnik
> >   * Bloomberg LP: Justin Erenkrantz
> >   * Cloud Foundry Foundation: Chip Childers
> >   * NASA JPL: Chris Mattmann
> >   * Unaffiliated: Jan Iversen
> >   * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
> >   * Pivotal: everyone else on this proposal
> >
> > == Sponsors ==
> >
> > === Champion ===
> > Roman Shaposhnik
> >
> > === Nominated Mentors ===
> >
> > The initial mentors are listed below:
> >   * Chip Childers - Apache Member, Cloud Foundry Foundation
> >   * Justin Erenkrantz - Apache Member, Bloomberg LP
> >   * Konstantin Boudnik - Apache Member, WANDisco
> >   * Jan Iversen - Apache Member, Self employed
> >   * William A. Rowe Jr. - Apache Member, Pivotal
> >   * Henry Saputra - Apache Member, Pivotal
> >   * Roman Shaposhnik - Apache Member, Pivotal
> >   * Chris Mattmann - Apache Member, NASA JPL
> >
> > === Sponsoring Entity ===
> > We would like to propose Apache incubator to sponsor this project.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> > For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
> >
> >
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: [DISCUSS] Geode Incubation proposal

[dsh <da...@gmail.com>]

Just as a quick remark. Geode might be a trademark owned by AMD:
http://en.wikipedia.org/wiki/Geode_%28processor%29

Cheers
Daniel

On Sun, Apr 12, 2015 at 8:46 PM, Roman Shaposhnik <rv...@apache.org> wrote:

> Hi!
>
> I would like to open up a discussion thread on
> the proposals for the core of Pivotal's GemFire
> to join ASF as an incubating project under the
> name Geode.
>
> The proposal wiki is available here:
>    https://wiki.apache.org/incubator/GeodeProposal
> and the text of the proposal is attached to the
> bottom of this email as well.
>
> Given the timing of ApacheCON, we would love to
> chat with anybody interested in giving us feedback.
> That said, of course, the bulk of the discussion is
> expected to happen on this thread.
>
> Thanks for your time and consideration!
> Roman (Geode proposal champion and a nominated mentor).
>
> == Abstract ==
> Geode is a data management platform that provides real-time,
> consistent access to data-intensive applications throughout widely
> distributed cloud architectures.
>
> Geode pools memory (along with CPU, network and optionally local disk)
> across multiple processes to manage application objects and behavior.
> It uses dynamic replication and data partitioning techniques for high
> availability, improved performance, scalability, and fault tolerance.
> Geode is both a distributed data container and an in-memory data
> management system providing reliable asynchronous event notifications
> and guaranteed message delivery.
>
> == Proposal ==
> The goal of this proposal is to bring the core of Pivotal Software,
> Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
> Foundation (ASF) in order to build a vibrant, diverse and
> self-governed open source community around the technology. Pivotal
> will continue to market and sell Pivotal GemFire based on Geode. Geode
> and Pivotal GemFire will be managed separately. This proposal covers
> the Geode source code (mainly written in Java), Geode documentation
> and other materials currently available on GitHub.
>
> While Geode is our primary choice for a name of the project, in order
> to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
>   * Haptic
>   * FIG
>
> == Background ==
> GemFire is an extremely mature and robust product that can trace its
> legacy all the way back to one of the first Object Databases for
> Smalltalk: GemStone. The GemFire code base has been maintained by the
> same group of engineers as a closed source project. Because of that,
> even though the engineers behind GemFire are the de-facto knowledge
> leaders for distributed in-memory management, they have had little
> exposure to the open source governance process.    The original
> company developing GemStone and GemFire was acquired by VMWare in 2010
> and later spun off as part of Pivotal Software in 2013. Today GemFire
> is used by over 600 enterprise customers. An example deployment
> includes China National Railways that uses Pivotal GemFire to run
> railway ticketing for the entire country of China with a 10 node
> cluster that manages 2 gigabytes "hot data" in memory, and 10 backup
> nodes for high availability and elastic scale.
>
> == Rationale ==
> Modern-day data management architectures require a robust in-memory
> data grid solution to handle a variety of use cases, ranging from
> enterprise-wide caching to real-time transactional applications at
> scale. In addition, as memory size and network bandwidth growth
> continues to outpace those of disk, the importance of managing large
> pools of RAM at scale increases. It is essential to innovate at the
> same pace and Pivotal strongly believes that in the Big Data space,
> this can be optimally achieved through a vibrant, diverse,
> self-governed community collectively innovating around a single
> codebase while at the same time cross-pollinating with various other
> data management communities. ASF is the ideal place to meet these
> ambitious goals.
>
> == Initial Goals ==
> Our initial goals are to bring Geode into the ASF, transition internal
> engineering processes into the open, and foster a collaborative
> development model according to the "Apache Way." Pivotal plans to
> develop new functionality in an open, community-driven way. To get
> there, the existing internal build, test and release processes will be
> refactored to support open development.
>
> == Current Status ==
> Currently, the project code base is licensed for evaluation purposes
> and is available for download from Pivotal.io
> (https://network.pivotal.io/products/project-geode). The documentation
> and wiki pages are available as public GitHub repositories under
> Project Geode organization on GitHub
> (https://github.com/project-geode). Although Pivotal GemFire was
> developed as a proprietary, closed-source product, the internal
> engineering practices adopted by the development team lend themselves
> well to an open, collaborative and meritocratic environment.
>
> The Pivotal GemFire team has always focused on building a robust end
> user community of paying and non-paying customers. The existing
> documentation along with StackOverflow and other similar forums are
> expected to facilitate conversions between our existing users so as to
> transform them into an active community of Geode members, stakeholders
> and developers.
>
> === Meritocracy ===
> Our proposed list of initial committers include the current GemFire
> R&D team, Pivotal Field Engineers, and several existing customers and
> partners. This group will form a base for the broader community we
> will invite to collaborate on the codebase. We intend to radically
> expand the initial developer and user community by running the project
> in accordance with the "Apache Way". Users and new contributors will
> be treated with respect and welcomed. By participating in the
> community and providing quality patches/support that move the project
> forward, they will earn merit. They also will be encouraged to provide
> non-code contributions (documentation, events, community management,
> etc.) and will gain merit for doing so. Those with a proven support
> and quality track record will be encouraged to become committers.
>
> === Community ===
> If Geode is accepted for incubation, the primary initial goal will be
> transitioning the core community towards embracing the Apache Way of
> project governance. We would solicit major existing contributors to
> become committers on the project from the start.
>
> === Core Developers ===
>
> While a few core developers are skilled in working in openly governed
> Apache communities. Most of the core developers are currently NOT
> affiliated with the ASF and would require new ICLAs before committing
> to the project.
>
> === Alignment ===
> The following existing ASF projects can be considered when reviewing
> Geode proposal:
>
> Apache HadoopⓇ is a distributed storage and processing framework for
> very large datasets focusing primarily on batch processing for
> analytic purposes. Geode is a data management platform that provides
> real-time, consistent, and transactional access to data-intensive
> applications. Our roadmap includes plans to provide close integration
> with HDFS.
>
> Apache HBase offers tabular data stored in Hadoop based on the Google
> Bigtable model.  HBase uses a key-based partitioning scheme and column
> family data model that can work well for scan intensive workloads but
> is not as broadly applicable as the rich object model, OQL querying,
> and hash partitioning provided by Geode.  Geode will use the HFile
> format for storing data in HDFS.
>
> Apache Spark is a fast engine for processing large datasets, typically
> from a Hadoop cluster, and performing batch, streaming, interactive,
> or machine learning workloads.  Geode supports high throughput
> streaming ingest application patterns and data parallel algorithms.
> Geode also ensures that data is highly available through redundancy
> while Spark recovers from faults using RDD lineage recomputation.  Our
> roadmap includes plans for providing integration with the Spark
> platform.
>
> Apache Ignite (incubating) offers distributed in-memory processing
> capabilities which in some ways overlap with Geode.  However, Geode
> has been in this field for more than 10 years and the product API's,
> design, and implementation details are quite different.  In addition,
> Geode offers highly optimized shared-nothing disk persistence for
> in-memory data which does not appear to be available with Ignite.
>
> Apache Cassandra is a highly scalable, distributed key-value store
> that focuses on eventual consistency.  It uses log-structured merge
> trees to handle write-heavy workloads.  The Geode distributed
> in-memory cluster provides highly performant and advanced capabilities
> including network partition detection and recovery, version-based
> state synchronization and conflict resolution, and single IO disk
> operations.
>
> Apache ActiveMQ and its sub project Apache Apollo offers a powerful
> message queue framework that is being considered for an open source
> implementation of Geode's WAN replication capabilities.
>
> Apache Storm is a streaming engine that processes events through a
> directed graph of computation. It requires Apache Zookeeper for
> coordination and Apache Kafka to reliably store the streaming data
> source. Geode provides builtin capabilities for these functions. In
> addition, Geode offers data locality for related entities and
> in-process access to reference data typically used during processing.
>
> Apache Kafka offers distributed and durable publish-subscribe
> messaging. Geode expands beyond publish-subscribe messaging to support
> data oriented notifications delivered from highly available, fault
> tolerant event queues that can be easily correlated to related data
> for further processing. Apache Samza is a distributed processing
> framework heavily dependent on Apache Kafka and Apache Hadoop YARN for
> messaging and distributed fault-tolerant processing.  Geode is data
> source agnostic and leverages its own technology and implementation
> for such use cases.
>
> == Known Risks ==
> Development has been sponsored mostly by a single company (or its
> predecessors) thus far and coordinated mainly by the core Pivotal
> GemFire team.
>
> For the project to fully transition to the Apache Way governance
> model, development must shift towards the meritocracy-centric model of
> growing a community of contributors balanced with the needs for
> extreme stability and core implementation coherency.
>
> The tools and development practices in place for the Pivotal GemFire
> product are compatible with the ASF infrastructure and thus we do not
> anticipate any on-boarding pains. Migration from the current GitHub
> repository is also expected to be straightforward.
>
> The project currently includes a modified version of the JGroups
> software toolkit. JGroups was initially released under the LGPL
> license. Although we have complied with the terms of the LGPL by
> making the modified source available, LGPL is classified as an
> incompatible license by the ASF.  The JGroups project has since been
> re-licenced under ALv2 (see http://www.jgroups.org/license.html) and
> we plan to engage with the licensor to overcome this license
> incompatibility. If the license incompatibility cannot be overcome
> through our discussions with the licensor, we will need to rework this
> portion of the project based upon a newer version of the JGroups
> toolkit or via other alternative development efforts.
>
> === Orphaned products ===
> Pivotal is fully committed to Pivotal GemFire and the product will
> continue to be based on the Geode project. Moreover, Pivotal has a
> vested interest in making Geode succeed by driving its close
> integration with sister ASF projects. We expect this to further
> reduces the risk of orphaning the product.
>
> === Inexperience with Open Source ===
> Pivotal has embraced open source software since its formation by
> employing contributors/committers and by shepherding open source
> projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Pivotal also
> supports other open source projects such as Redis, Chorus, Groovy and
> Grails. We have experience with the formation of vibrant communities
> around open technologies with the Cloud Foundry Foundation.  Although
> some of the initial committers have not been developers on an entirely
> open source, community-driven project, we expect to bring to bear the
> open development practices that have proven successful on longstanding
> Pivotal open source projects to the Geode project.  Additionally,
> several ASF veterans agreed to mentor the project and are listed in
> this proposal. The project will rely on their guidance and collective
> wisdom to quickly transition the entire team of initial committers
> towards practicing the Apache Way.
>
> === Homogeneous Developers ===
> While most of the initial committers are employed by Pivotal, we have
> already seen a healthy level of interest from our existing customers
> and partners. We intend to convert that interest directly into
> participation and will be investing in activities to recruit
> additional committers from other companies.
>
> === Reliance on Salaried Developers ===
> Most of the contributors are paid to work in the Big Data space. While
> they might wander from their current employers, they are unlikely to
> venture far from their core expertises and thus will continue to be
> engaged with the project regardless of their current employers.
>
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, Geode may consider various
> degrees of integration and code exchange with Apache Ignite
> (incubating), Apache Hadoop, Apache Storm, Apache Spark and Apache
> Kafka/Samza. Given the success that the Pivotal GemFire product
> enjoyed as an embedded service, we expect integration points to be
> inside and outside the project. We look forward to collaborating with
> these communities as well as other communities under the Apache
> umbrella.
>
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of Geode into Apache Incubator.
>
> == Documentation ==
> See documentation for the current state of the project documentation
> available as part of the GitHub repository at
> https://github.com/project-geode/docs and live at
> http://geode-docs.cfapps.io/
>
> == Initial Source ==
> Pivotal is releasing the source code for Geode under an Evaluation
> License at https://network.pivotal.io/products/project-geode .  We
> encourage ASF community members interested in  this proposal to
> download the source code, review and try out the software.
>
> == Source and Intellectual Property Submission Plan ==
> As soon as Geode is approved to join Apache Incubator, the source code
> will be transitioned via the Software Grant Agreement onto ASF
> infrastructure and in turn made available under the Apache License,
> version 2.0.  We know of no legal encumberments that would inhibit the
> transfer of source code to the ASF.
>
> == External Dependencies ==
>
> Embedded dependencies (relocated):
>    * json
>    * jgroups
>    * joptsimple
>
> Runtime dependencies:
>    * antlr
>    * classmate
>    * commons-fileupload
>    * commons-io
>    * commons-lang
>    * commons-modeler
>    * fastutil
>    * findbugs annotations
>    * guava
>    * jackson
>    * jansi
>    * javax.activation
>    * javax.mail-api
>    * javax.resource-api
>    * javax.servlet-api
>    * javax.transaction-api
>    * jetty
>    * jline
>    * jna
>    * json4s
>    * log4j
>    * mx4j
>    * paranamer
>    * scala
>    * slf4j
>    * snappy-java
>    * spring
>    * swagger
>
> Module or optional dependencies:
>    * None
>
> Build only dependencies:
>    * None
>
> Test only dependencies:
>    * cglib
>    * hamcrest
>    * jmock
>    * junit
>    * multithreadedtc
>    * objenesis
>
> Cryptography
> N/A
>
> == Required Resources ==
>
> === Mailing lists ===
>   * private@geode.incubator.apache.org (moderated subscriptions)
>   * commits@geode.incubator.apache.org
>   * dev@geode.incubator.apache.org
>   * issues@geode.incubator.apache.org
>   * user@geode.incubator.apache.org
>
> === Git Repository ===
> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>
> === Issue Tracking ===
> JIRA Project Geode (GEODE)
>
> === Other Resources ===
>
> Means of setting up regular builds for Geode on builds.apache.org
>
> == Initial Committers ==
>   * Amey Barve
>   * Adib Saikali
>   * Alan Strait
>   * Amogh Shetkar
>   * Anil Gingade
>   * Anilkumar Gingade
>   * Anthony Baker
>   * Ashvin Agrawal
>   * Asif Shahid
>   * Avinash Dongre
>   * Barry Oglesby
>   * Ben Reser
>   * Bruce Schuchardt
>   * Bruce Szalwinski
>   * Catherine Johnson
>   * Chip Childers
>   * Christian Tzolov
>   * Dan Smith
>   * Darrel Schneider
>   * Dave Muirhead
>   * David Yozie
>   * Dick Cavender
>   * Edin Zulich
>   * Eric Shu
>   * Gideon Low
>   * Greg Chase
>   * Hemant Bhanawat
>   * Henry Saputra
>   * Hitesh Khamesra
>   * Jacob Barrett
>   * Jags Ramnarayan
>   * Jan Iversen
>   * Jason Huynh
>   * Jens Deppe
>   * Jianxia Chen
>   * John Blum
>   * Justin Erenkrantz
>   * Ketan Deshpande
>   * Kirk Lund
>   * Kishor Bachhav
>   * Konstantin Boudnik
>   * Konstantin Ignatyev
>   * Lise Storc
>   * Luke Shannon
>   * Lyndon Adams
>   * Lynn Gallinat
>   * Lynn Hughes-Godfrey
>   * Mark Bretl
>   * Michael Schubert
>   * Namrata Thanvi
>   * Neeraj Kumar
>   * Nilkanth Patel
>   * Qihong Chen
>   * Rahul Diyewar
>   * Randy May
>   * Roman Shaposhnik
>   * Severine Tymon
>   * Shatarupa Nandi
>   * Shirish Deshmukh
>   * Sonal Agarwal
>   * Soubhik Chakraborty
>   * Sourabh Bansod
>   * Stephane Maldini
>   * Stuart Williams
>   * Sudhir Menon
>   * Sunil Jigyasu
>   * Supriya Pillai
>   * Suranjan Kumar
>   * Suyog Bhokare
>   * Swapnil Bawaskar
>   * Swati Sawant
>   * Tushar Khairnar
>   * Udo Kohlmeyer
>   * Vince Ford
>   * Vinesh Prasanna Manoharan
>   * Vivek Bhaskar
>   * Wes Williams
>   * William A. Rowe Jr.
>   * William Markito
>   * Will Schipp
>   * Xiaojian Zhou
>   * Yogesh Mahajan
>
> == Affiliations ==
>   * WANDisco: Konstantin Boudnik
>   * Bloomberg LP: Justin Erenkrantz
>   * Cloud Foundry Foundation: Chip Childers
>   * NASA JPL: Chris Mattmann
>   * Unaffiliated: Jan Iversen
>   * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
>   * Pivotal: everyone else on this proposal
>
> == Sponsors ==
>
> === Champion ===
> Roman Shaposhnik
>
> === Nominated Mentors ===
>
> The initial mentors are listed below:
>   * Chip Childers - Apache Member, Cloud Foundry Foundation
>   * Justin Erenkrantz - Apache Member, Bloomberg LP
>   * Konstantin Boudnik - Apache Member, WANDisco
>   * Jan Iversen - Apache Member, Self employed
>   * William A. Rowe Jr. - Apache Member, Pivotal
>   * Henry Saputra - Apache Member, Pivotal
>   * Roman Shaposhnik - Apache Member, Pivotal
>   * Chris Mattmann - Apache Member, NASA JPL
>
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Geode Incubation proposal

[Roman Shaposhnik <rv...@apache.org>]

On Sun, Apr 12, 2015 at 1:00 PM, Ted Dunning <te...@gmail.com> wrote:
> Roman,
>
> Could you comment on the potential issue that this proposal is only
> offering up the distributed object storage.  The problem that might arise
> with this is that by offering up a particular specialized core capability,
> other projects may find it difficult to use this core capability which
> would inhibit growth of the community.
>
> What do you think about that?

I was trying to address that very point in the Rationale section. While
it is true that today Geode is the engine for GemFire, it is at the same
time a pretty sophisticated piece of engineering work with subsystems
that can find use outside of GemFire applications. Just to give you a few
examples: there's a kick-ass eventing systems in there and the off-heap
memory management implementation is one the best ones I've seen.
I could absolutely see Geode integrating much tighter at the level
of in-memory data exchange layer (think Tachyon done right) with the
rest of the bigdata ecosystem as well.

That said, making Geode as modular as possible is exactly why we're
proposing it for Incubation: this is exactly the kind of extended use
cases that ASF communities are great at figuring out.

Long story short, it is definitely our desire to see Geode applicable way
outside of core GemFire capabilities and I believe it has got what it takes.

Thanks,
Roman.

P.S. In fact, you've just given me a great subject for a blog post. Stay
tuned!

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

Re: [DISCUSS] Geode Incubation proposal

[Ted Dunning <te...@gmail.com>]

Roman,

Could you comment on the potential issue that this proposal is only
offering up the distributed object storage.  The problem that might arise
with this is that by offering up a particular specialized core capability,
other projects may find it difficult to use this core capability which
would inhibit growth of the community.

What do you think about that?



On Sun, Apr 12, 2015 at 8:46 PM, Roman Shaposhnik <rv...@apache.org> wrote:

> Hi!
>
> I would like to open up a discussion thread on
> the proposals for the core of Pivotal's GemFire
> to join ASF as an incubating project under the
> name Geode.
>
> The proposal wiki is available here:
>    https://wiki.apache.org/incubator/GeodeProposal
> and the text of the proposal is attached to the
> bottom of this email as well.
>
> Given the timing of ApacheCON, we would love to
> chat with anybody interested in giving us feedback.
> That said, of course, the bulk of the discussion is
> expected to happen on this thread.
>
> Thanks for your time and consideration!
> Roman (Geode proposal champion and a nominated mentor).
>
> == Abstract ==
> Geode is a data management platform that provides real-time,
> consistent access to data-intensive applications throughout widely
> distributed cloud architectures.
>
> Geode pools memory (along with CPU, network and optionally local disk)
> across multiple processes to manage application objects and behavior.
> It uses dynamic replication and data partitioning techniques for high
> availability, improved performance, scalability, and fault tolerance.
> Geode is both a distributed data container and an in-memory data
> management system providing reliable asynchronous event notifications
> and guaranteed message delivery.
>
> == Proposal ==
> The goal of this proposal is to bring the core of Pivotal Software,
> Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
> Foundation (ASF) in order to build a vibrant, diverse and
> self-governed open source community around the technology. Pivotal
> will continue to market and sell Pivotal GemFire based on Geode. Geode
> and Pivotal GemFire will be managed separately. This proposal covers
> the Geode source code (mainly written in Java), Geode documentation
> and other materials currently available on GitHub.
>
> While Geode is our primary choice for a name of the project, in order
> to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
>   * Haptic
>   * FIG
>
> == Background ==
> GemFire is an extremely mature and robust product that can trace its
> legacy all the way back to one of the first Object Databases for
> Smalltalk: GemStone. The GemFire code base has been maintained by the
> same group of engineers as a closed source project. Because of that,
> even though the engineers behind GemFire are the de-facto knowledge
> leaders for distributed in-memory management, they have had little
> exposure to the open source governance process.    The original
> company developing GemStone and GemFire was acquired by VMWare in 2010
> and later spun off as part of Pivotal Software in 2013. Today GemFire
> is used by over 600 enterprise customers. An example deployment
> includes China National Railways that uses Pivotal GemFire to run
> railway ticketing for the entire country of China with a 10 node
> cluster that manages 2 gigabytes "hot data" in memory, and 10 backup
> nodes for high availability and elastic scale.
>
> == Rationale ==
> Modern-day data management architectures require a robust in-memory
> data grid solution to handle a variety of use cases, ranging from
> enterprise-wide caching to real-time transactional applications at
> scale. In addition, as memory size and network bandwidth growth
> continues to outpace those of disk, the importance of managing large
> pools of RAM at scale increases. It is essential to innovate at the
> same pace and Pivotal strongly believes that in the Big Data space,
> this can be optimally achieved through a vibrant, diverse,
> self-governed community collectively innovating around a single
> codebase while at the same time cross-pollinating with various other
> data management communities. ASF is the ideal place to meet these
> ambitious goals.
>
> == Initial Goals ==
> Our initial goals are to bring Geode into the ASF, transition internal
> engineering processes into the open, and foster a collaborative
> development model according to the "Apache Way." Pivotal plans to
> develop new functionality in an open, community-driven way. To get
> there, the existing internal build, test and release processes will be
> refactored to support open development.
>
> == Current Status ==
> Currently, the project code base is licensed for evaluation purposes
> and is available for download from Pivotal.io
> (https://network.pivotal.io/products/project-geode). The documentation
> and wiki pages are available as public GitHub repositories under
> Project Geode organization on GitHub
> (https://github.com/project-geode). Although Pivotal GemFire was
> developed as a proprietary, closed-source product, the internal
> engineering practices adopted by the development team lend themselves
> well to an open, collaborative and meritocratic environment.
>
> The Pivotal GemFire team has always focused on building a robust end
> user community of paying and non-paying customers. The existing
> documentation along with StackOverflow and other similar forums are
> expected to facilitate conversions between our existing users so as to
> transform them into an active community of Geode members, stakeholders
> and developers.
>
> === Meritocracy ===
> Our proposed list of initial committers include the current GemFire
> R&D team, Pivotal Field Engineers, and several existing customers and
> partners. This group will form a base for the broader community we
> will invite to collaborate on the codebase. We intend to radically
> expand the initial developer and user community by running the project
> in accordance with the "Apache Way". Users and new contributors will
> be treated with respect and welcomed. By participating in the
> community and providing quality patches/support that move the project
> forward, they will earn merit. They also will be encouraged to provide
> non-code contributions (documentation, events, community management,
> etc.) and will gain merit for doing so. Those with a proven support
> and quality track record will be encouraged to become committers.
>
> === Community ===
> If Geode is accepted for incubation, the primary initial goal will be
> transitioning the core community towards embracing the Apache Way of
> project governance. We would solicit major existing contributors to
> become committers on the project from the start.
>
> === Core Developers ===
>
> While a few core developers are skilled in working in openly governed
> Apache communities. Most of the core developers are currently NOT
> affiliated with the ASF and would require new ICLAs before committing
> to the project.
>
> === Alignment ===
> The following existing ASF projects can be considered when reviewing
> Geode proposal:
>
> Apache HadoopⓇ is a distributed storage and processing framework for
> very large datasets focusing primarily on batch processing for
> analytic purposes. Geode is a data management platform that provides
> real-time, consistent, and transactional access to data-intensive
> applications. Our roadmap includes plans to provide close integration
> with HDFS.
>
> Apache HBase offers tabular data stored in Hadoop based on the Google
> Bigtable model.  HBase uses a key-based partitioning scheme and column
> family data model that can work well for scan intensive workloads but
> is not as broadly applicable as the rich object model, OQL querying,
> and hash partitioning provided by Geode.  Geode will use the HFile
> format for storing data in HDFS.
>
> Apache Spark is a fast engine for processing large datasets, typically
> from a Hadoop cluster, and performing batch, streaming, interactive,
> or machine learning workloads.  Geode supports high throughput
> streaming ingest application patterns and data parallel algorithms.
> Geode also ensures that data is highly available through redundancy
> while Spark recovers from faults using RDD lineage recomputation.  Our
> roadmap includes plans for providing integration with the Spark
> platform.
>
> Apache Ignite (incubating) offers distributed in-memory processing
> capabilities which in some ways overlap with Geode.  However, Geode
> has been in this field for more than 10 years and the product API's,
> design, and implementation details are quite different.  In addition,
> Geode offers highly optimized shared-nothing disk persistence for
> in-memory data which does not appear to be available with Ignite.
>
> Apache Cassandra is a highly scalable, distributed key-value store
> that focuses on eventual consistency.  It uses log-structured merge
> trees to handle write-heavy workloads.  The Geode distributed
> in-memory cluster provides highly performant and advanced capabilities
> including network partition detection and recovery, version-based
> state synchronization and conflict resolution, and single IO disk
> operations.
>
> Apache ActiveMQ and its sub project Apache Apollo offers a powerful
> message queue framework that is being considered for an open source
> implementation of Geode's WAN replication capabilities.
>
> Apache Storm is a streaming engine that processes events through a
> directed graph of computation. It requires Apache Zookeeper for
> coordination and Apache Kafka to reliably store the streaming data
> source. Geode provides builtin capabilities for these functions. In
> addition, Geode offers data locality for related entities and
> in-process access to reference data typically used during processing.
>
> Apache Kafka offers distributed and durable publish-subscribe
> messaging. Geode expands beyond publish-subscribe messaging to support
> data oriented notifications delivered from highly available, fault
> tolerant event queues that can be easily correlated to related data
> for further processing. Apache Samza is a distributed processing
> framework heavily dependent on Apache Kafka and Apache Hadoop YARN for
> messaging and distributed fault-tolerant processing.  Geode is data
> source agnostic and leverages its own technology and implementation
> for such use cases.
>
> == Known Risks ==
> Development has been sponsored mostly by a single company (or its
> predecessors) thus far and coordinated mainly by the core Pivotal
> GemFire team.
>
> For the project to fully transition to the Apache Way governance
> model, development must shift towards the meritocracy-centric model of
> growing a community of contributors balanced with the needs for
> extreme stability and core implementation coherency.
>
> The tools and development practices in place for the Pivotal GemFire
> product are compatible with the ASF infrastructure and thus we do not
> anticipate any on-boarding pains. Migration from the current GitHub
> repository is also expected to be straightforward.
>
> The project currently includes a modified version of the JGroups
> software toolkit. JGroups was initially released under the LGPL
> license. Although we have complied with the terms of the LGPL by
> making the modified source available, LGPL is classified as an
> incompatible license by the ASF.  The JGroups project has since been
> re-licenced under ALv2 (see http://www.jgroups.org/license.html) and
> we plan to engage with the licensor to overcome this license
> incompatibility. If the license incompatibility cannot be overcome
> through our discussions with the licensor, we will need to rework this
> portion of the project based upon a newer version of the JGroups
> toolkit or via other alternative development efforts.
>
> === Orphaned products ===
> Pivotal is fully committed to Pivotal GemFire and the product will
> continue to be based on the Geode project. Moreover, Pivotal has a
> vested interest in making Geode succeed by driving its close
> integration with sister ASF projects. We expect this to further
> reduces the risk of orphaning the product.
>
> === Inexperience with Open Source ===
> Pivotal has embraced open source software since its formation by
> employing contributors/committers and by shepherding open source
> projects like Cloud Foundry, Spring, RabbitMQ and MADlib. Pivotal also
> supports other open source projects such as Redis, Chorus, Groovy and
> Grails. We have experience with the formation of vibrant communities
> around open technologies with the Cloud Foundry Foundation.  Although
> some of the initial committers have not been developers on an entirely
> open source, community-driven project, we expect to bring to bear the
> open development practices that have proven successful on longstanding
> Pivotal open source projects to the Geode project.  Additionally,
> several ASF veterans agreed to mentor the project and are listed in
> this proposal. The project will rely on their guidance and collective
> wisdom to quickly transition the entire team of initial committers
> towards practicing the Apache Way.
>
> === Homogeneous Developers ===
> While most of the initial committers are employed by Pivotal, we have
> already seen a healthy level of interest from our existing customers
> and partners. We intend to convert that interest directly into
> participation and will be investing in activities to recruit
> additional committers from other companies.
>
> === Reliance on Salaried Developers ===
> Most of the contributors are paid to work in the Big Data space. While
> they might wander from their current employers, they are unlikely to
> venture far from their core expertises and thus will continue to be
> engaged with the project regardless of their current employers.
>
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, Geode may consider various
> degrees of integration and code exchange with Apache Ignite
> (incubating), Apache Hadoop, Apache Storm, Apache Spark and Apache
> Kafka/Samza. Given the success that the Pivotal GemFire product
> enjoyed as an embedded service, we expect integration points to be
> inside and outside the project. We look forward to collaborating with
> these communities as well as other communities under the Apache
> umbrella.
>
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of Geode into Apache Incubator.
>
> == Documentation ==
> See documentation for the current state of the project documentation
> available as part of the GitHub repository at
> https://github.com/project-geode/docs and live at
> http://geode-docs.cfapps.io/
>
> == Initial Source ==
> Pivotal is releasing the source code for Geode under an Evaluation
> License at https://network.pivotal.io/products/project-geode .  We
> encourage ASF community members interested in  this proposal to
> download the source code, review and try out the software.
>
> == Source and Intellectual Property Submission Plan ==
> As soon as Geode is approved to join Apache Incubator, the source code
> will be transitioned via the Software Grant Agreement onto ASF
> infrastructure and in turn made available under the Apache License,
> version 2.0.  We know of no legal encumberments that would inhibit the
> transfer of source code to the ASF.
>
> == External Dependencies ==
>
> Embedded dependencies (relocated):
>    * json
>    * jgroups
>    * joptsimple
>
> Runtime dependencies:
>    * antlr
>    * classmate
>    * commons-fileupload
>    * commons-io
>    * commons-lang
>    * commons-modeler
>    * fastutil
>    * findbugs annotations
>    * guava
>    * jackson
>    * jansi
>    * javax.activation
>    * javax.mail-api
>    * javax.resource-api
>    * javax.servlet-api
>    * javax.transaction-api
>    * jetty
>    * jline
>    * jna
>    * json4s
>    * log4j
>    * mx4j
>    * paranamer
>    * scala
>    * slf4j
>    * snappy-java
>    * spring
>    * swagger
>
> Module or optional dependencies:
>    * None
>
> Build only dependencies:
>    * None
>
> Test only dependencies:
>    * cglib
>    * hamcrest
>    * jmock
>    * junit
>    * multithreadedtc
>    * objenesis
>
> Cryptography
> N/A
>
> == Required Resources ==
>
> === Mailing lists ===
>   * private@geode.incubator.apache.org (moderated subscriptions)
>   * commits@geode.incubator.apache.org
>   * dev@geode.incubator.apache.org
>   * issues@geode.incubator.apache.org
>   * user@geode.incubator.apache.org
>
> === Git Repository ===
> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>
> === Issue Tracking ===
> JIRA Project Geode (GEODE)
>
> === Other Resources ===
>
> Means of setting up regular builds for Geode on builds.apache.org
>
> == Initial Committers ==
>   * Amey Barve
>   * Adib Saikali
>   * Alan Strait
>   * Amogh Shetkar
>   * Anil Gingade
>   * Anilkumar Gingade
>   * Anthony Baker
>   * Ashvin Agrawal
>   * Asif Shahid
>   * Avinash Dongre
>   * Barry Oglesby
>   * Ben Reser
>   * Bruce Schuchardt
>   * Bruce Szalwinski
>   * Catherine Johnson
>   * Chip Childers
>   * Christian Tzolov
>   * Dan Smith
>   * Darrel Schneider
>   * Dave Muirhead
>   * David Yozie
>   * Dick Cavender
>   * Edin Zulich
>   * Eric Shu
>   * Gideon Low
>   * Greg Chase
>   * Hemant Bhanawat
>   * Henry Saputra
>   * Hitesh Khamesra
>   * Jacob Barrett
>   * Jags Ramnarayan
>   * Jan Iversen
>   * Jason Huynh
>   * Jens Deppe
>   * Jianxia Chen
>   * John Blum
>   * Justin Erenkrantz
>   * Ketan Deshpande
>   * Kirk Lund
>   * Kishor Bachhav
>   * Konstantin Boudnik
>   * Konstantin Ignatyev
>   * Lise Storc
>   * Luke Shannon
>   * Lyndon Adams
>   * Lynn Gallinat
>   * Lynn Hughes-Godfrey
>   * Mark Bretl
>   * Michael Schubert
>   * Namrata Thanvi
>   * Neeraj Kumar
>   * Nilkanth Patel
>   * Qihong Chen
>   * Rahul Diyewar
>   * Randy May
>   * Roman Shaposhnik
>   * Severine Tymon
>   * Shatarupa Nandi
>   * Shirish Deshmukh
>   * Sonal Agarwal
>   * Soubhik Chakraborty
>   * Sourabh Bansod
>   * Stephane Maldini
>   * Stuart Williams
>   * Sudhir Menon
>   * Sunil Jigyasu
>   * Supriya Pillai
>   * Suranjan Kumar
>   * Suyog Bhokare
>   * Swapnil Bawaskar
>   * Swati Sawant
>   * Tushar Khairnar
>   * Udo Kohlmeyer
>   * Vince Ford
>   * Vinesh Prasanna Manoharan
>   * Vivek Bhaskar
>   * Wes Williams
>   * William A. Rowe Jr.
>   * William Markito
>   * Will Schipp
>   * Xiaojian Zhou
>   * Yogesh Mahajan
>
> == Affiliations ==
>   * WANDisco: Konstantin Boudnik
>   * Bloomberg LP: Justin Erenkrantz
>   * Cloud Foundry Foundation: Chip Childers
>   * NASA JPL: Chris Mattmann
>   * Unaffiliated: Jan Iversen
>   * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
>   * Pivotal: everyone else on this proposal
>
> == Sponsors ==
>
> === Champion ===
> Roman Shaposhnik
>
> === Nominated Mentors ===
>
> The initial mentors are listed below:
>   * Chip Childers - Apache Member, Cloud Foundry Foundation
>   * Justin Erenkrantz - Apache Member, Bloomberg LP
>   * Konstantin Boudnik - Apache Member, WANDisco
>   * Jan Iversen - Apache Member, Self employed
>   * William A. Rowe Jr. - Apache Member, Pivotal
>   * Henry Saputra - Apache Member, Pivotal
>   * Roman Shaposhnik - Apache Member, Pivotal
>   * Chris Mattmann - Apache Member, NASA JPL
>
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>