You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jason Porter <jp...@ibm.com.INVALID> on 2022/11/30 23:33:53 UTC
[DISCUSS] KIE Proposal
Abstract
KIE (Knowledge is Everything) is a community of solutions and supporting tooling for knowledge engineering and process automation, focusing on events, rules, and workflows.
Proposal<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal>
KIE is a community dedicated to supporting knowledge engineering and process automation, using standards from groups like OMG (BPMN, CMMN, DMN), CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is comprised of leading open-source projects (like Drools and jBPM), which provide modeling and code authoring tools in this space. The work has a strong emphasis on being a first-class citizen for Kubernetes but will continue to support embedded and other environments such as edge computing. Drools and jBPM are well-known projects in their areas of rules and workflow and they will be joined by another project, building on a shared core with jBPM, for CNCF’s Serverless Workflow - this project is going through a naming process at the time of this application. Kogito is the foundation project for workflow which jBPM and CNCF’s Serverless Workflow build on. Services and frameworks are provided to enable those projects in a cloud-native environment and tooling is made available through KIE Tools.
Background<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background>
Experience has shown that a holistic approach is a practical requirement for any knowledge engineering and process automation. This requires a breadth of capabilities able to model and execute an application’s data models, rules, workflows, and events. These projects aim to provide a holistic approach with a strong emphasis on congruency across them.
Rationale<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale>
Knowledge engineering and process automation have been and continue to play a large part in today’s software lifecycle. To date, there have been few truly open-source implementations of any of the specifications (DMN, PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement these standards and fill that gap of having an open-source implementation.
The projects within KIE also mesh well with other Apache projects such as Apache Camel and Apache Airavata. Integrations could be done at the IoT level with Apache PLC4X and others.
Developers need a solution that follows, implements, and collaborates with these industry specifications. The Apache Software Foundation would allow these projects to continue to grow in a vendor-neutral environment and promote further collaboration with existing integrations and future partners.
Initial Goals<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals>
First and foremost, we aim to enlarge the community. KIE has primarily been an open-source community of Red Hat Developers and users outside of Red Hat. Adding IBM to the list of developers helps, but we would like to see more. We have ideas for the various sub-projects, such as straight-through processing support in Kogito, better spec compliance for the tooling, and more research into language bindings for non-Java languages. We believe we can address some of these while an Apache Incubator project.
Current Status<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status>
Code for the various projects with the KIE community is all hosted on GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code is Apache 2 licensed. Red Hat has been the project’s custodian since its inception and has maintained leadership in that area. Moving forward into the Apache Incubator, we would need to establish the habit of holding votes and meetings and the project updates per the Apache Way.
We also currently maintain a YouTube channel dedicated to the community and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
Meritocracy:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy>
Red Hat runs all of its open-source projects as meritocracies, the KIE Community is no different. This aspect would not change any. Kogito currently does not make a distinction between “committer” and “PMC member” the same way Apache does. That aspect would need implementation.
Community:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community>
The KIE Community has an active base of contributors within and outside Red Hat. Community members currently use Zulip chat or mailing lists hosted by Google Groups as communication tools. It has been that way for many years. Before that, we were using IRC at Freenode for many years. There are also mailing lists hosted on Google Groups that are leveraged for those who prefer mailing list communication. Zulip was started as a standard communication medium for KIE Community back in 2020. IRC has been used since 2003.
Core Developers:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers>
Core developers would come from both Red Hat and IBM. They include people who have been working on related projects and the creation of the KIE Community since the beginning, and also people new to the project.
Alignment:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment>
Projects within the KIE Community align with multiple efforts within Apache, namely:
* Apache OpenWhisk
* Apache Airavata
* Apache Camel
We are currently actively involved in collaboration with Apache Camel, while the other two are more alignments and usages within the communities. There may be other Apache projects which could benefit from integration with KIE Community projects.
jBPM, the proposed Serverless Workflow project and the Kogito workflow foundation are targeting serverless and microservice deployments. It helps to create automation and integration with other technologies in a simple-to-use and understandable way. The Apache Software Foundation is a great place to collaborate with multiple companies and technologies. We’re looking to build a community that is inclusive, helpful, and a good citizen to the larger Open Source community.
Other projects within the KIE Community umbrella target a more standard enterprise software approach and deployment model.
Known Risks<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks>
The Kogito workflow foundation targets the Quarkus environment, an open-source project that Red Hat maintains. Should Red Hat no longer wish to maintain Quarkus or move it in a direction that harms Kogito, a pivot may be necessary. The Kogito workflow foundation will still run on other runtimes, so it is less of a risk as well.
There should not be any risks for other projects.
Project Name<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name>
All names and trademarks have been vetted by Red Hat’s legal team to be usable in the space. Transferring these over to Apache will not be a problem.
Orphaned products<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products>
Primary contributions to the KIE Community of projects will be made by engineers employed by Red Hat and IBM. IBM is a leading vendor in the Business Automation space. Red Hat up until the second half of 2022 was also a major vendor in the same space. While Red Hat is no longer pursuing the Business Automation market it does still need to augment the capabilities of its other products with workflow, rules, and event technologies in a way that aligns with Red Hat’s target audiences and Red Hat’s strategic direction. Red Hat will continue to pursue the development around CNCF serverless workflow, which will be built upon Kogito and Drools. There is no risk of these projects being orphaned by either company.
Inexperience with Open Source:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source>
All initial committers are well-versed in Open Source development.
Length of Incubation:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation>
Incubation should take somewhere between six to twelve months.
Homogenous Developers:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers>
The list of initial project committers includes developers from IBM and Red Hat, all from different locations around the world.
Reliance on Salaried Developers:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers>
Currently, the list of developers is from IBM and Red Hat. We’re hoping by moving to Apache we can grow this list of developers outside of those two companies. All the projects within KIE have been around for a long time and have a large user base. Developers have come and gone over the years, but the initial list of developers is coming from Red Hat and IBM.
Relationships with Other Apache Products:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products>
The Apache Camel project has had integrations with KIE Community projects, namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito and Camel also have integrations with Quarkus. Kogito is built using Apache Maven.
An Excessive Fascination with the Apache Brand:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand>
We have looked at both the Apache Software Foundation and the Eclipse Foundation and have decided that Apache would be a better place for the code base. Red Hat, and IBM, have worked with both foundations and continue to do so.
While the Apache brand is indeed well known and has great recognition, we’re looking more toward the neutral nature of being at Apache and keeping the project alive in an environment that is not solely controlled by a single entity.
Documentation<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation>
Kogito Documentation: https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
Drools Documentation: https://www.drools.org/learn/documentation.html
jBPM Documentation: https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
DMN Specification: https://www.omg.org/spec/DMN
BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
Cloud Events Specification: https://github.com/cloudevents/spec
Initial Source<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source>
All the code will be coming from the KIE Community GitHub repo at https://github.com/kiegroup. There will be multiple repositories including examples and code bases for Drools, jBPM, and Kogito.
Source and Intellectual Property Submission Plan<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan>
* Source code within GitHub
* Domains: kie.org, kogito.org, kogito.kie.org, blog.kie.org, jbpm.org, drools.org, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org are all currently owned by Red Hat
External Dependencies:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies>
There are some LGPL, and Eclipse dependencies for some of the projects in the test or provided scopes of the Maven poms. For example jdt dependencies for the Eclipse plugins, logback, junit, and similar. Hibernate jars are LGPL as well, those are in jBPM.
Cryptography:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography>
There are some calls to the JVM vault, for process migration.
Required Resources<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources>
Mailing lists:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists>
* private@kie.incubator.apache.org
* dev@kie.incubator.apache.org
* commits@kie.incubator.apache.org
Subversion Directory:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory>
None
Git Repositories:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories>
Assuming we can continue to use GitHub, though it may need to migrate to be beneath the Apache Organization.
Issue Tracking:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking>
If possible, we would like to use GitHub issues.
Other Resources:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources>
None.
Initial Committers<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers>
List of GitHub names:
Name
GitHub Username
Apache CLA
Apache Email
Mario Fusco
mariofusco
FALSE
Toshiya Kobayashi
tkobayas
TRUE
Matteo Mortari
tarilabs
TRUE
Tristan Radisson
radtriste
FALSE
Gabriele Cardosi
gitgabrio
FALSE
Edoardo Vacchi
evacchi
FALSE
Paolo Bizzarri
pibizza
FALSE
Cristiano Nicolai
cristianonicolai
FALSE
Michael Biarnés Kiefer
mbiarnes
FALSE
Enrique González Martínez
elguardian
FALSE
Vani Haripriya Mudadla
vaniharipriya
FALSE
Jason Porter
lightguard
TRUE
lightguardjp@apache.org
Gonzalo Muñoz
gmunozfe
FALSE
Francisco Javier Tirado Sarti
fjtirado
FALSE
Helber Belmiro
hbelmiro
TRUE
Antonio Fernandez Alhambra
afalhambra
FALSE
Abhijit Humbe
abhijithumbe
FALSE
Martin Weiler
martinweiler
FALSE
Enrique Mingorance Cano
ginxo
FALSE
Tiago Dolphine
tiagodolphine
FALSE
Alex Porcelli
porcelli
FALSE
Kris Verlaenen
krisv
TRUE
(requested krisv@apache.org)
Pere Fernández
pefernan
FALSE
Jan Stastny
jstastny-cz
FALSE
Jozef Marko
jomarko
FALSE
Walter Medvedeo
wmedvede
FALSE
Kennedy Bowers
kbowers-redhat
FALSE
Roberto Oliveira
rgdoliveira
FALSE
Andrea Lamparelli
lampajr
FALSE
Bai Xiaofeng
bxf12315
FALSE
Ruben Romero Montes
ruromero
FALSE
Filippe Spolti
spolti
FALSE
Massimiliano Dessì
desmax74
TRUE
Tiago Bento
tiagobento
FALSE
Yeser Amer
yesamer
FALSE
Guilherme Caponetto
caponetto
FALSE
Paulo Martins
paulovmr
FALSE
Thiago Lugli
thiagoelg
FALSE
William Antônio Siqueira
jesuino
FALSE
Fabrizio Antonangeli
fantonangeli
FALSE
Valentino Pellegrino
vpellegrino
FALSE
Ricardo Zanini
ricardozanini
FALSE
Tibor Zimányi
baldimir
FALSE
Eder Ignatowicz
ederign
FALSE
Mark Proctor
mdproctor
FALSE
Thiago Lugli
thiagoelg
FALSE
Luiz João Motta
ljmotta
FALSE
Jaime Enriquez
inodeman
FALSE
Luca Molteni
lucamolteni
FALSE
Davide Salerno
davidesalerno
TRUE
Edson Tirelli
etirelli
FALSE
Sponsors<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors>
IBM and Red Hat are the sponsors for the project.
Champion:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion>
Brian Proffitt
Nominated Mentors:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors>
Brian Proffitt
Claus Ibsen
Andrea Cosentino
Sponsoring Entity:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity>
Apache Camel
Jason Porter
Software Engineer
He/Him/His
IBM
Re: [DISCUSS] KIE Proposal
Posted by PJ Fanning <fa...@gmail.com>.
Is it possible the name is too generic and could cause confusion with
this existing ASF project?
* https://kie.readthedocs.io/en/latest/
* https://github.com/apache/servicecomb-kie
On Thu, 1 Dec 2022 at 22:36, Jason Porter <jp...@ibm.com.invalid> wrote:
>
> Abstract
>
> KIE (Knowledge is Everything) is a community of solutions and supporting tooling for knowledge engineering and process automation, focusing on events, rules, and workflows.
>
> Proposal<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal>
>
> KIE is a community dedicated to supporting knowledge engineering and process automation, using standards from groups like OMG (BPMN, CMMN, DMN), CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is comprised of leading open-source projects (like Drools and jBPM), which provide modeling and code authoring tools in this space. The work has a strong emphasis on being a first-class citizen for Kubernetes but will continue to support embedded and other environments such as edge computing. Drools and jBPM are well-known projects in their areas of rules and workflow and they will be joined by another project, building on a shared core with jBPM, for CNCF’s Serverless Workflow - this project is going through a naming process at the time of this application. Kogito is the foundation project for workflow which jBPM and CNCF’s Serverless Workflow build on. Services and frameworks are provided to enable those projects in a cloud-native environment and tooling is made available through KIE Tools.
>
> Background<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background>
>
> Experience has shown that a holistic approach is a practical requirement for any knowledge engineering and process automation. This requires a breadth of capabilities able to model and execute an application’s data models, rules, workflows, and events. These projects aim to provide a holistic approach with a strong emphasis on congruency across them.
>
> Rationale<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale>
>
> Knowledge engineering and process automation have been and continue to play a large part in today’s software lifecycle. To date, there have been few truly open-source implementations of any of the specifications (DMN, PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement these standards and fill that gap of having an open-source implementation.
>
>
> The projects within KIE also mesh well with other Apache projects such as Apache Camel and Apache Airavata. Integrations could be done at the IoT level with Apache PLC4X and others.
>
>
> Developers need a solution that follows, implements, and collaborates with these industry specifications. The Apache Software Foundation would allow these projects to continue to grow in a vendor-neutral environment and promote further collaboration with existing integrations and future partners.
>
> Initial Goals<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals>
>
> First and foremost, we aim to enlarge the community. KIE has primarily been an open-source community of Red Hat Developers and users outside of Red Hat. Adding IBM to the list of developers helps, but we would like to see more. We have ideas for the various sub-projects, such as straight-through processing support in Kogito, better spec compliance for the tooling, and more research into language bindings for non-Java languages. We believe we can address some of these while an Apache Incubator project.
>
> Current Status<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status>
>
> Code for the various projects with the KIE community is all hosted on GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code is Apache 2 licensed. Red Hat has been the project’s custodian since its inception and has maintained leadership in that area. Moving forward into the Apache Incubator, we would need to establish the habit of holding votes and meetings and the project updates per the Apache Way.
>
>
> We also currently maintain a YouTube channel dedicated to the community and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
>
> Meritocracy:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy>
>
> Red Hat runs all of its open-source projects as meritocracies, the KIE Community is no different. This aspect would not change any. Kogito currently does not make a distinction between “committer” and “PMC member” the same way Apache does. That aspect would need implementation.
>
> Community:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community>
>
> The KIE Community has an active base of contributors within and outside Red Hat. Community members currently use Zulip chat or mailing lists hosted by Google Groups as communication tools. It has been that way for many years. Before that, we were using IRC at Freenode for many years. There are also mailing lists hosted on Google Groups that are leveraged for those who prefer mailing list communication. Zulip was started as a standard communication medium for KIE Community back in 2020. IRC has been used since 2003.
>
> Core Developers:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers>
>
> Core developers would come from both Red Hat and IBM. They include people who have been working on related projects and the creation of the KIE Community since the beginning, and also people new to the project.
>
> Alignment:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment>
>
> Projects within the KIE Community align with multiple efforts within Apache, namely:
>
> * Apache OpenWhisk
>
> * Apache Airavata
>
> * Apache Camel
>
>
> We are currently actively involved in collaboration with Apache Camel, while the other two are more alignments and usages within the communities. There may be other Apache projects which could benefit from integration with KIE Community projects.
>
>
> jBPM, the proposed Serverless Workflow project and the Kogito workflow foundation are targeting serverless and microservice deployments. It helps to create automation and integration with other technologies in a simple-to-use and understandable way. The Apache Software Foundation is a great place to collaborate with multiple companies and technologies. We’re looking to build a community that is inclusive, helpful, and a good citizen to the larger Open Source community.
>
>
> Other projects within the KIE Community umbrella target a more standard enterprise software approach and deployment model.
>
> Known Risks<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks>
>
> The Kogito workflow foundation targets the Quarkus environment, an open-source project that Red Hat maintains. Should Red Hat no longer wish to maintain Quarkus or move it in a direction that harms Kogito, a pivot may be necessary. The Kogito workflow foundation will still run on other runtimes, so it is less of a risk as well.
>
> There should not be any risks for other projects.
>
> Project Name<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name>
>
> All names and trademarks have been vetted by Red Hat’s legal team to be usable in the space. Transferring these over to Apache will not be a problem.
>
> Orphaned products<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products>
>
> Primary contributions to the KIE Community of projects will be made by engineers employed by Red Hat and IBM. IBM is a leading vendor in the Business Automation space. Red Hat up until the second half of 2022 was also a major vendor in the same space. While Red Hat is no longer pursuing the Business Automation market it does still need to augment the capabilities of its other products with workflow, rules, and event technologies in a way that aligns with Red Hat’s target audiences and Red Hat’s strategic direction. Red Hat will continue to pursue the development around CNCF serverless workflow, which will be built upon Kogito and Drools. There is no risk of these projects being orphaned by either company.
>
> Inexperience with Open Source:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source>
>
> All initial committers are well-versed in Open Source development.
>
> Length of Incubation:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation>
>
> Incubation should take somewhere between six to twelve months.
>
> Homogenous Developers:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers>
>
> The list of initial project committers includes developers from IBM and Red Hat, all from different locations around the world.
>
> Reliance on Salaried Developers:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers>
>
> Currently, the list of developers is from IBM and Red Hat. We’re hoping by moving to Apache we can grow this list of developers outside of those two companies. All the projects within KIE have been around for a long time and have a large user base. Developers have come and gone over the years, but the initial list of developers is coming from Red Hat and IBM.
>
> Relationships with Other Apache Products:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products>
>
> The Apache Camel project has had integrations with KIE Community projects, namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito and Camel also have integrations with Quarkus. Kogito is built using Apache Maven.
>
> An Excessive Fascination with the Apache Brand:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand>
>
> We have looked at both the Apache Software Foundation and the Eclipse Foundation and have decided that Apache would be a better place for the code base. Red Hat, and IBM, have worked with both foundations and continue to do so.
>
>
> While the Apache brand is indeed well known and has great recognition, we’re looking more toward the neutral nature of being at Apache and keeping the project alive in an environment that is not solely controlled by a single entity.
>
> Documentation<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation>
>
> Kogito Documentation: https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
>
> Drools Documentation: https://www.drools.org/learn/documentation.html
>
> jBPM Documentation: https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
>
> Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
>
> DMN Specification: https://www.omg.org/spec/DMN
>
> BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
>
> Cloud Events Specification: https://github.com/cloudevents/spec
>
> Initial Source<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source>
>
> All the code will be coming from the KIE Community GitHub repo at https://github.com/kiegroup. There will be multiple repositories including examples and code bases for Drools, jBPM, and Kogito.
>
> Source and Intellectual Property Submission Plan<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan>
>
> * Source code within GitHub
>
> * Domains: kie.org, kogito.org, kogito.kie.org, blog.kie.org, jbpm.org, drools.org, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org are all currently owned by Red Hat
>
> External Dependencies:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies>
>
> There are some LGPL, and Eclipse dependencies for some of the projects in the test or provided scopes of the Maven poms. For example jdt dependencies for the Eclipse plugins, logback, junit, and similar. Hibernate jars are LGPL as well, those are in jBPM.
>
> Cryptography:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography>
>
> There are some calls to the JVM vault, for process migration.
>
> Required Resources<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources>
> Mailing lists:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists>
>
> * private@kie.incubator.apache.org
>
> * dev@kie.incubator.apache.org
>
> * commits@kie.incubator.apache.org
>
> Subversion Directory:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory>
>
> None
>
> Git Repositories:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories>
>
> Assuming we can continue to use GitHub, though it may need to migrate to be beneath the Apache Organization.
>
> Issue Tracking:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking>
>
> If possible, we would like to use GitHub issues.
>
> Other Resources:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources>
>
> None.
>
> Initial Committers<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers>
>
>
> List of GitHub names:
>
>
> Name
>
> GitHub Username
>
> Apache CLA
>
> Apache Email
>
> Mario Fusco
>
> mariofusco
>
> FALSE
>
>
> Toshiya Kobayashi
>
> tkobayas
>
> TRUE
>
>
> Matteo Mortari
>
> tarilabs
>
> TRUE
>
>
> Tristan Radisson
>
> radtriste
>
> FALSE
>
>
> Gabriele Cardosi
>
> gitgabrio
>
> FALSE
>
>
> Edoardo Vacchi
>
> evacchi
>
> FALSE
>
>
> Paolo Bizzarri
>
> pibizza
>
> FALSE
>
>
> Cristiano Nicolai
>
> cristianonicolai
>
> FALSE
>
>
> Michael Biarnés Kiefer
>
> mbiarnes
>
> FALSE
>
>
> Enrique González Martínez
>
> elguardian
>
> FALSE
>
>
> Vani Haripriya Mudadla
>
> vaniharipriya
>
> FALSE
>
>
> Jason Porter
>
> lightguard
>
> TRUE
>
> lightguardjp@apache.org
>
> Gonzalo Muñoz
>
> gmunozfe
>
> FALSE
>
>
> Francisco Javier Tirado Sarti
>
> fjtirado
>
> FALSE
>
>
> Helber Belmiro
>
> hbelmiro
>
> TRUE
>
>
> Antonio Fernandez Alhambra
>
> afalhambra
>
> FALSE
>
>
> Abhijit Humbe
>
> abhijithumbe
>
> FALSE
>
>
> Martin Weiler
>
> martinweiler
>
> FALSE
>
>
> Enrique Mingorance Cano
>
> ginxo
>
> FALSE
>
>
> Tiago Dolphine
>
> tiagodolphine
>
> FALSE
>
>
> Alex Porcelli
>
> porcelli
>
> FALSE
>
>
> Kris Verlaenen
>
> krisv
>
> TRUE
>
> (requested krisv@apache.org)
>
> Pere Fernández
>
> pefernan
>
> FALSE
>
>
> Jan Stastny
>
> jstastny-cz
>
> FALSE
>
>
> Jozef Marko
>
> jomarko
>
> FALSE
>
>
> Walter Medvedeo
>
> wmedvede
>
> FALSE
>
>
> Kennedy Bowers
>
> kbowers-redhat
>
> FALSE
>
>
> Roberto Oliveira
>
> rgdoliveira
>
> FALSE
>
>
> Andrea Lamparelli
>
> lampajr
>
> FALSE
>
>
> Bai Xiaofeng
>
> bxf12315
>
> FALSE
>
>
> Ruben Romero Montes
>
> ruromero
>
> FALSE
>
>
> Filippe Spolti
>
> spolti
>
> FALSE
>
>
> Massimiliano Dessì
>
> desmax74
>
> TRUE
>
>
> Tiago Bento
>
> tiagobento
>
> FALSE
>
>
> Yeser Amer
>
> yesamer
>
> FALSE
>
>
> Guilherme Caponetto
>
> caponetto
>
> FALSE
>
>
> Paulo Martins
>
> paulovmr
>
> FALSE
>
>
> Thiago Lugli
>
> thiagoelg
>
> FALSE
>
>
> William Antônio Siqueira
>
> jesuino
>
> FALSE
>
>
> Fabrizio Antonangeli
>
> fantonangeli
>
> FALSE
>
>
> Valentino Pellegrino
>
> vpellegrino
>
> FALSE
>
>
> Ricardo Zanini
>
> ricardozanini
>
> FALSE
>
>
> Tibor Zimányi
>
> baldimir
>
> FALSE
>
>
> Eder Ignatowicz
>
> ederign
>
> FALSE
>
>
> Mark Proctor
>
> mdproctor
>
> FALSE
>
>
> Thiago Lugli
>
> thiagoelg
>
> FALSE
>
>
> Luiz João Motta
>
> ljmotta
>
> FALSE
>
>
> Jaime Enriquez
>
> inodeman
>
> FALSE
>
>
> Luca Molteni
>
> lucamolteni
>
> FALSE
>
>
> Davide Salerno
>
> davidesalerno
>
> TRUE
>
>
> Edson Tirelli
>
> etirelli
>
> FALSE
>
> Sponsors<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors>
>
> IBM and Red Hat are the sponsors for the project.
>
> Champion:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion>
>
> Brian Proffitt
>
> Nominated Mentors:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors>
>
> Brian Proffitt
>
> Claus Ibsen
>
> Andrea Cosentino
>
> Sponsoring Entity:<https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity>
>
> Apache Camel
>
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Jason,
now this looks a lot more like something we can help support :-)
And projects don’t necessarily have to be mono repos. Stuff like examples, project websites … that’s quite common to be in separate repositories.
I guess the amount of additional work would not be that much … yeah … the reports have to be written, but most use templates for that and just fill in special things being noted.
Writing the reports for a project usually doesn’t take much time.
Regarding setting up of infra … I guess you would go a GitHub approach and not sign up for Jira and Confluence now that public user registrations are disabled.
I would dare to say the amount of work to set this up for one project and multiple project would be identical.
Chris
From: Jason Porter <jp...@ibm.com.INVALID>
Date: Tuesday, 6. December 2022 at 17:27
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: Re: [DISCUSS] KIE Proposal
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache and teach them how to do things, if they are doing their job correctly, they should also really audit the releases being done and help get the codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)? There each project could have their initial PPMC and committer lists and it would spread out the load a bit. However I would expect staffing 12 projects with enough work-willing mentors will still be challenging and I would assume not all of them to find enough of them, but it could be one first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
That is part of a broader question. Some of those repos are things like examples for kogito, the website, etc. Things that are part of the projects themselves, but don’t have a life outside of the project to which they belong. I understand we’ll probably have to collapse the structures within Apache and have a single repo per project. What we’re really looking at as far as projects being donated:
Kogito
Drools
jBPM
Then there are the supporting repos for things like examples, docs, website, tooling, etc. Many of the people working on these projects work on all of them, so it would probably be the same group of people with very little deviation in the list of committers. Could they be different PPMCs, but they’d basically be the same group, just more work with the reports, setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBMB�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[
��[�\�[ ][��X��ܚX�P[��X�]܋�\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
��[�\�[ Z[ [��X�]܋�\X�K�ܙ�B
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
Sure, how do I go about doing that?
Jason Porter
Software Engineer
He/Him/His
IBM
On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@ibm.com.invalid>> wrote:
Sounds like there aren’t any further questions, but I can appreciate people just getting back to work from the end of the year. I’ll give it another day before we move on to the next stage, which I believe is a call for a vote, correct?
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID>> wrote:
Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
If there are no further questions, are we able to go to a vote?
________________________________
From: Jason Porter <jp...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid>> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com>> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org<ma...@incubator.apache.org>
For additional commands, e-mail: general-help@incubator.apache.org<ma...@incubator.apache.org>
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
Hmm… I don’t seem to have edit access :(
Jason Porter
Software Engineer
He/Him/His
IBM
On Jan 3, 2023, at 11:55, PJ Fanning <fa...@gmail.com> wrote:
https://cwiki.apache.org/confluence/display/INCUBATOR/KIE+Proposal is
the work in progress page.
On Tue, 3 Jan 2023 at 19:53, PJ Fanning <fa...@gmail.com> wrote:
I did some of the wikification of the email but it's pretty time
consuming and I want to finish up for the evening.
The main item remaining is to put all the initial committers into the table.
On Tue, 3 Jan 2023 at 19:26, Jason Porter <jp...@ibm.com> wrote:
I was just going to do this but looks like you beat me to it, PJ, thank you.
Jason Porter
Software Engineer
He/Him/His
IBM
On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@ibm.com.invalid> wrote:
Sounds like there aren’t any further questions, but I can appreciate people just getting back to work from the end of the year. I’ll give it another day before we move on to the next stage, which I believe is a call for a vote, correct?
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID> wrote:
Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
If there are no further questions, are we able to go to a vote?
________________________________
From: Jason Porter <jp...@ibm.com.INVALID>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by PJ Fanning <fa...@gmail.com>.
https://cwiki.apache.org/confluence/display/INCUBATOR/KIE+Proposal is
the work in progress page.
On Tue, 3 Jan 2023 at 19:53, PJ Fanning <fa...@gmail.com> wrote:
>
> I did some of the wikification of the email but it's pretty time
> consuming and I want to finish up for the evening.
>
> The main item remaining is to put all the initial committers into the table.
>
> On Tue, 3 Jan 2023 at 19:26, Jason Porter <jp...@ibm.com> wrote:
> >
> > I was just going to do this but looks like you beat me to it, PJ, thank you.
> >
> > Jason Porter
> > Software Engineer
> > He/Him/His
> >
> > IBM
> >
> > On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
> >
> > This Message Is From an External Sender
> > This message came from outside your organization.
> > Could we get the proposal doc up on the ASF wiki?
> >
> > On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@ibm.com.invalid> wrote:
> >>
> >> Sounds like there aren’t any further questions, but I can appreciate people just getting back to work from the end of the year. I’ll give it another day before we move on to the next stage, which I believe is a call for a vote, correct?
> >>
> >> Jason Porter
> >> Software Engineer
> >> He/Him/His
> >>
> >> IBM
> >>
> >> On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID> wrote:
> >>
> >> Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
> >>
> >> If there are no further questions, are we able to go to a vote?
> >> ________________________________
> >> From: Jason Porter <jp...@ibm.com.INVALID>
> >> Sent: Tuesday, December 13, 2022 08:37
> >> To: general@incubator.apache.org <ge...@incubator.apache.org>
> >> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
> >>
> >>
> >>
> >> ________________________________
> >> From: Calvin Kirs <ki...@apache.org>
> >> Sent: Monday, December 12, 2022 23:31
> >> To: general@incubator.apache.org <ge...@incubator.apache.org>
> >> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
> >>
> >> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
> >>
> >> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
> >>
> >> That's not a problem If two projects are in different fields.
> >> we'd just need to be careful with the project description.
> >>
> >> Perfect! Thank you, Calvin.
> >>
> >>
> >>
> >> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
> >>
> >>
> >> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
> >>
> >>
> >> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
> >>
> >>
> >> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
> >>
> >>
> >>
> >> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
> >>
> >>
> >> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
> >>
> >>
> >> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
> >>
> >> Jason Porter
> >> Software Engineer
> >> He/Him/His
> >>
> >> IBM
> >>
> >> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
> >>
> >> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
> >>
> >>
> >> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> >> wrote:
> >>
> >> Hi Jason,
> >>
> >> Well, those numbers are a bit better than the initial ones.
> >> Thing is: Mentors will not only have to help onboard people to Apache
> >> and teach them how to do things, if they are doing their job correctly,
> >> they should also really audit the releases being done and help get the
> >> codebase into shape first.
> >>
> >> Even with 12 sub-projects, work-wise that would put a load on the
> >> mentors, as if they signed up for mentoring 12 projects.
> >>
> >> So how about bringing in projects separately (where it makes sense)?
> >> There each project could have their initial PPMC and committer lists and it
> >> would spread out the load a bit. However I would expect staffing 12
> >> projects with enough work-willing mentors will still be challenging and I
> >> would assume not all of them to find enough of them, but it could be one
> >> first step.
> >>
> >> Or is there an advantage of considering all projects as one unity?
> >>
> >> Chris
> >>
> >> [snip]
> >>
> >> That is part of a broader question. Some of those repos are things like
> >> examples for kogito, the website, etc. Things that are part of the projects
> >> themselves, but don’t have a life outside of the project to which they
> >> belong. I understand we’ll probably have to collapse the structures within
> >> Apache and have a single repo per project. What we’re really looking at as
> >> far as projects being donated:
> >>
> >> Kogito
> >> Drools
> >> jBPM
> >>
> >>
> >> I really think these should be separate projects. I realize theres a
> >> dependency/hierarchy between them (jBPM using Drools as its rules engine
> >> and Kogito using jBPM for its business process/workflow) - but people use
> >> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> >> set of contributors all work on all three projects, the aspiration here at
> >> Apache has to be to grow the community of contributors from the user
> >> community which will not be completely the same for the three projects.
> >> I've used Drools in the past, but not jBPM or Kogito.
> >>
> >> Niall
> >>
> >>
> >>
> >> Then there are the supporting repos for things like examples, docs,
> >> website, tooling, etc. Many of the people working on these projects work on
> >> all of them, so it would probably be the same group of people with very
> >> little deviation in the list of committers. Could they be different PPMCs,
> >> but they’d basically be the same group, just more work with the reports,
> >> setup, infra, etc.
> >>
> >> Jason Porter
> >> Software Engineer
> >> He/Him/His
> >>
> >> IBM
> >>
> >>
> >>
> >> --
> >> Best wishes！
> >> CalvinKirs
> >>
> >> ---------------------------------------------------------------------
> >> 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] KIE Proposal
Posted by PJ Fanning <fa...@gmail.com>.
I did some of the wikification of the email but it's pretty time
consuming and I want to finish up for the evening.
The main item remaining is to put all the initial committers into the table.
On Tue, 3 Jan 2023 at 19:26, Jason Porter <jp...@ibm.com> wrote:
>
> I was just going to do this but looks like you beat me to it, PJ, thank you.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
>
> This Message Is From an External Sender
> This message came from outside your organization.
> Could we get the proposal doc up on the ASF wiki?
>
> On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@ibm.com.invalid> wrote:
>>
>> Sounds like there aren’t any further questions, but I can appreciate people just getting back to work from the end of the year. I’ll give it another day before we move on to the next stage, which I believe is a call for a vote, correct?
>>
>> Jason Porter
>> Software Engineer
>> He/Him/His
>>
>> IBM
>>
>> On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID> wrote:
>>
>> Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
>>
>> If there are no further questions, are we able to go to a vote?
>> ________________________________
>> From: Jason Porter <jp...@ibm.com.INVALID>
>> Sent: Tuesday, December 13, 2022 08:37
>> To: general@incubator.apache.org <ge...@incubator.apache.org>
>> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>>
>>
>>
>> ________________________________
>> From: Calvin Kirs <ki...@apache.org>
>> Sent: Monday, December 12, 2022 23:31
>> To: general@incubator.apache.org <ge...@incubator.apache.org>
>> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>>
>> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
>>
>> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
>>
>> That's not a problem If two projects are in different fields.
>> we'd just need to be careful with the project description.
>>
>> Perfect! Thank you, Calvin.
>>
>>
>>
>> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
>>
>>
>> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
>>
>>
>> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
>>
>>
>> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
>>
>>
>>
>> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
>>
>>
>> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
>>
>>
>> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
>>
>> Jason Porter
>> Software Engineer
>> He/Him/His
>>
>> IBM
>>
>> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
>>
>> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
>>
>>
>> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
>> wrote:
>>
>> Hi Jason,
>>
>> Well, those numbers are a bit better than the initial ones.
>> Thing is: Mentors will not only have to help onboard people to Apache
>> and teach them how to do things, if they are doing their job correctly,
>> they should also really audit the releases being done and help get the
>> codebase into shape first.
>>
>> Even with 12 sub-projects, work-wise that would put a load on the
>> mentors, as if they signed up for mentoring 12 projects.
>>
>> So how about bringing in projects separately (where it makes sense)?
>> There each project could have their initial PPMC and committer lists and it
>> would spread out the load a bit. However I would expect staffing 12
>> projects with enough work-willing mentors will still be challenging and I
>> would assume not all of them to find enough of them, but it could be one
>> first step.
>>
>> Or is there an advantage of considering all projects as one unity?
>>
>> Chris
>>
>> [snip]
>>
>> That is part of a broader question. Some of those repos are things like
>> examples for kogito, the website, etc. Things that are part of the projects
>> themselves, but don’t have a life outside of the project to which they
>> belong. I understand we’ll probably have to collapse the structures within
>> Apache and have a single repo per project. What we’re really looking at as
>> far as projects being donated:
>>
>> Kogito
>> Drools
>> jBPM
>>
>>
>> I really think these should be separate projects. I realize theres a
>> dependency/hierarchy between them (jBPM using Drools as its rules engine
>> and Kogito using jBPM for its business process/workflow) - but people use
>> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
>> set of contributors all work on all three projects, the aspiration here at
>> Apache has to be to grow the community of contributors from the user
>> community which will not be completely the same for the three projects.
>> I've used Drools in the past, but not jBPM or Kogito.
>>
>> Niall
>>
>>
>>
>> Then there are the supporting repos for things like examples, docs,
>> website, tooling, etc. Many of the people working on these projects work on
>> all of them, so it would probably be the same group of people with very
>> little deviation in the list of committers. Could they be different PPMCs,
>> but they’d basically be the same group, just more work with the reports,
>> setup, infra, etc.
>>
>> Jason Porter
>> Software Engineer
>> He/Him/His
>>
>> IBM
>>
>>
>>
>> --
>> Best wishes！
>> CalvinKirs
>>
>> ---------------------------------------------------------------------
>> 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] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
I was just going to do this but looks like you beat me to it, PJ, thank you.
Jason Porter
Software Engineer
He/Him/His
IBM
On Jan 3, 2023, at 09:42, PJ Fanning <fa...@apache.org> wrote:
This Message Is From an External Sender
This message came from outside your organization.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@ibm.com.invalid>> wrote:
Sounds like there aren’t any further questions, but I can appreciate people just getting back to work from the end of the year. I’ll give it another day before we move on to the next stage, which I believe is a call for a vote, correct?
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID>> wrote:
Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
If there are no further questions, are we able to go to a vote?
________________________________
From: Jason Porter <jp...@ibm.com.INVALID>>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid>> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com>> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org<ma...@incubator.apache.org>
For additional commands, e-mail: general-help@incubator.apache.org<ma...@incubator.apache.org>
Re: [DISCUSS] KIE Proposal
Posted by PJ Fanning <fa...@apache.org>.
Could we get the proposal doc up on the ASF wiki?
On Tue 3 Jan 2023, 17:25 Jason Porter, <jp...@ibm.com.invalid> wrote:
> Sounds like there aren’t any further questions, but I can appreciate
> people just getting back to work from the end of the year. I’ll give it
> another day before we move on to the next stage, which I believe is a call
> for a vote, correct?
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID> wrote:
>
> Are there any further questions anyone has about KIE? I know we're nearing
> the end of the year and people may not be watching as closely, but wanted
> to make sure since the discussion has died down.
>
> If there are no further questions, are we able to go to a vote?
> ________________________________
> From: Jason Porter <jp...@ibm.com.INVALID>
> Sent: Tuesday, December 13, 2022 08:37
> To: general@incubator.apache.org <ge...@incubator.apache.org>
> Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
>
>
>
> ________________________________
> From: Calvin Kirs <ki...@apache.org>
> Sent: Monday, December 12, 2022 23:31
> To: general@incubator.apache.org <ge...@incubator.apache.org>
> Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
>
> On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid>
> wrote:
>
> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE-
> Knowledge Is Everything), and the other is a suffix. Both projects are very
> different as well. Servicecomb-kie is a configuration center for
> microservices written in Go, whereas KIE is a knowledge engineering and
> process automation solution written in Java. For example, how was this
> handled in the context of Apache DeltaCloud and Apache DeltaSpike; or
> Apache DataFu and Apache DataLab? Is there precedence within the ASF for
> similarly named projects? The two communities have also co-existed for
> roughly the same time, using the same names without clashes.
>
> That's not a problem If two projects are in different fields.
> we'd just need to be careful with the project description.
>
> Perfect! Thank you, Calvin.
>
>
>
> As was stated previously, the number of projects is much smaller than the
> number of GitHub repos. This is because KIE did not use a singular
> repository model within the GitHub organization. The projects we’re
> currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools,
> and another project for the CNCF Serverless Workflow implementation that is
> going through a naming process now. KIE-Tools is a little odd, though, as
> it doesn’t stand on its own well. The existing code base contains a lot of
> modules and code, which could be considered legacy, which we do not plan to
> move over. There will be a cleaning and pruning process to ensure a more
> relevant, sustainable, and forward-looking set of modules as code is moved
> over. This should further reduce the amount of code that is moved over. We
> understand we may need to collapse the repositories moving over to the ASF.
> Let us know if you want to see how everything rolls into a more flat
> structure.
>
>
> Regarding umbrella versus standalone projects, we believe that the unified
> and cohesive experience provides more value than just the sum of its parts.
> This is also not just about where we are now, but where we hope to evolve
> as a knowledge engineering platform. On the surface, those projects can be
> seen as independent in their business rules, decisions, and workflow
> domains. However, real-world use cases are more complex. Usually, they
> require a lot of interdependencies, for example, business rules
> orchestration is accomplished by using a workflow file definition (i.e.,
> BPMN), and complex workflow decisions are better modeled in DMN models. The
> aim is to try and drive consistency and ease of use across those
> technologies, in an integrated and holistic manner.
>
>
> If those projects end up as individual TLPs, it'll be up to users to write
> a lot of boiler-plate code - or create additional new projects to handle
> and abstract the unified experience.
>
>
> Of course, as a consequence of the unified vision, the current codebase is
> taking advantage of this unification, which means there's a lot of shared
> code among the projects. Moving away from this will also result in more
> top-level supporting projects to provide additional code, needed as
> foundational code or integration code, which may actually create more
> complexity and end-user confusion.
>
>
>
> Although it might not be the most popular example within Apache, KIE aims
> to provide a similar umbrella cohesiveness that Apache OpenOffice has for
> their sub-projects like Write and Calc. We really want the community to
> think of knowledge engineering as a whole domain of technologies for
> problem-solving, and not on individual silo technologies.
>
>
> Lastly, fracturing the community we have already created around the KIE
> brand and concept is certainly not ideal and will weaken the overall
> project brands and success. We believe we'll be able to leverage further
> what we currently have in the community and build upon it to create a more
> cohesive knowledge-processing solution if everything stays together and
> people remain invested in the success of the knowledge engineering platform
> as a whole, rather than their individual technologies.
>
>
> We would like to initially keep the PPMC small, ideally 5-7 people. We
> have around 50 people identified as initial committers, but having a PMC
> that large during incubation is not ideal for the issues that have been
> mentioned.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com>
> wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jporter@ibm.com.invalid<mailto:
> jporter@ibm.com.invalid>> wrote:
>
>
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache
> and teach them how to do things, if they are doing their job correctly,
> they should also really audit the releases being done and help get the
> codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the
> mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)?
> There each project could have their initial PPMC and committer lists and it
> would spread out the load a bit. However I would expect staffing 12
> projects with enough work-willing mentors will still be challenging and I
> would assume not all of them to find enough of them, but it could be one
> first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
>
> That is part of a broader question. Some of those repos are things like
> examples for kogito, the website, etc. Things that are part of the projects
> themselves, but don’t have a life outside of the project to which they
> belong. I understand we’ll probably have to collapse the structures within
> Apache and have a single repo per project. What we’re really looking at as
> far as projects being donated:
>
> Kogito
> Drools
> jBPM
>
>
> I really think these should be separate projects. I realize theres a
> dependency/hierarchy between them (jBPM using Drools as its rules engine
> and Kogito using jBPM for its business process/workflow) - but people use
> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> set of contributors all work on all three projects, the aspiration here at
> Apache has to be to grow the community of contributors from the user
> community which will not be completely the same for the three projects.
> I've used Drools in the past, but not jBPM or Kogito.
>
> Niall
>
>
>
> Then there are the supporting repos for things like examples, docs,
> website, tooling, etc. Many of the people working on these projects work on
> all of them, so it would probably be the same group of people with very
> little deviation in the list of committers. Could they be different PPMCs,
> but they’d basically be the same group, just more work with the reports,
> setup, infra, etc.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
>
>
> --
> Best wishes！
> CalvinKirs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
Sounds like there aren’t any further questions, but I can appreciate people just getting back to work from the end of the year. I’ll give it another day before we move on to the next stage, which I believe is a call for a vote, correct?
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 23, 2022, at 09:20, Jason Porter <jp...@ibm.com.INVALID> wrote:
Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
If there are no further questions, are we able to go to a vote?
________________________________
From: Jason Porter <jp...@ibm.com.INVALID>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
Are there any further questions anyone has about KIE? I know we're nearing the end of the year and people may not be watching as closely, but wanted to make sure since the discussion has died down.
If there are no further questions, are we able to go to a vote?
________________________________
From: Jason Porter <jp...@ibm.com.INVALID>
Sent: Tuesday, December 13, 2022 08:37
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] RE: [DISCUSS] KIE Proposal
________________________________
From: Calvin Kirs <ki...@apache.org>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
>
> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
>
>
> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
>
>
> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
>
>
> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
>
>
> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
>
>
>
> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
>
>
> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
>
>
> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
>
>
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache
> and teach them how to do things, if they are doing their job correctly,
> they should also really audit the releases being done and help get the
> codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the
> mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)?
> There each project could have their initial PPMC and committer lists and it
> would spread out the load a bit. However I would expect staffing 12
> projects with enough work-willing mentors will still be challenging and I
> would assume not all of them to find enough of them, but it could be one
> first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
>
> That is part of a broader question. Some of those repos are things like
> examples for kogito, the website, etc. Things that are part of the projects
> themselves, but don’t have a life outside of the project to which they
> belong. I understand we’ll probably have to collapse the structures within
> Apache and have a single repo per project. What we’re really looking at as
> far as projects being donated:
>
> Kogito
> Drools
> jBPM
>
>
> I really think these should be separate projects. I realize theres a
> dependency/hierarchy between them (jBPM using Drools as its rules engine
> and Kogito using jBPM for its business process/workflow) - but people use
> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> set of contributors all work on all three projects, the aspiration here at
> Apache has to be to grow the community of contributors from the user
> community which will not be completely the same for the three projects.
> I've used Drools in the past, but not jBPM or Kogito.
>
> Niall
>
>
>
> Then there are the supporting repos for things like examples, docs,
> website, tooling, etc. Many of the people working on these projects work on
> all of them, so it would probably be the same group of people with very
> little deviation in the list of committers. Could they be different PPMCs,
> but they’d basically be the same group, just more work with the reports,
> setup, infra, etc.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
________________________________
From: Calvin Kirs <ki...@apache.org>
Sent: Monday, December 12, 2022 23:31
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: [EXTERNAL] Re: [DISCUSS] KIE Proposal
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
>
> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
Perfect! Thank you, Calvin.
>
>
> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
>
>
> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
>
>
> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
>
>
> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
>
>
>
> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
>
>
> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
>
>
> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
>
>
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache
> and teach them how to do things, if they are doing their job correctly,
> they should also really audit the releases being done and help get the
> codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the
> mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)?
> There each project could have their initial PPMC and committer lists and it
> would spread out the load a bit. However I would expect staffing 12
> projects with enough work-willing mentors will still be challenging and I
> would assume not all of them to find enough of them, but it could be one
> first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
>
> That is part of a broader question. Some of those repos are things like
> examples for kogito, the website, etc. Things that are part of the projects
> themselves, but don’t have a life outside of the project to which they
> belong. I understand we’ll probably have to collapse the structures within
> Apache and have a single repo per project. What we’re really looking at as
> far as projects being donated:
>
> Kogito
> Drools
> jBPM
>
>
> I really think these should be separate projects. I realize theres a
> dependency/hierarchy between them (jBPM using Drools as its rules engine
> and Kogito using jBPM for its business process/workflow) - but people use
> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> set of contributors all work on all three projects, the aspiration here at
> Apache has to be to grow the community of contributors from the user
> community which will not be completely the same for the three projects.
> I've used Drools in the past, but not jBPM or Kogito.
>
> Niall
>
>
>
> Then there are the supporting repos for things like examples, docs,
> website, tooling, etc. Many of the people working on these projects work on
> all of them, so it would probably be the same group of people with very
> little deviation in the list of committers. Could they be different PPMCs,
> but they’d basically be the same group, just more work with the reports,
> setup, infra, etc.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Calvin Kirs <ki...@apache.org>.
On Fri, Dec 9, 2022 at 11:45 PM Jason Porter <jp...@ibm.com.invalid> wrote:
>
> We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
That's not a problem If two projects are in different fields.
we'd just need to be careful with the project description.
>
>
> As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
>
>
> Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
>
>
> If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
>
>
> Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
>
>
>
> Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
>
>
> Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
>
>
> We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
> On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
>
>
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache
> and teach them how to do things, if they are doing their job correctly,
> they should also really audit the releases being done and help get the
> codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the
> mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)?
> There each project could have their initial PPMC and committer lists and it
> would spread out the load a bit. However I would expect staffing 12
> projects with enough work-willing mentors will still be challenging and I
> would assume not all of them to find enough of them, but it could be one
> first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
>
> That is part of a broader question. Some of those repos are things like
> examples for kogito, the website, etc. Things that are part of the projects
> themselves, but don’t have a life outside of the project to which they
> belong. I understand we’ll probably have to collapse the structures within
> Apache and have a single repo per project. What we’re really looking at as
> far as projects being donated:
>
> Kogito
> Drools
> jBPM
>
>
> I really think these should be separate projects. I realize theres a
> dependency/hierarchy between them (jBPM using Drools as its rules engine
> and Kogito using jBPM for its business process/workflow) - but people use
> Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
> set of contributors all work on all three projects, the aspiration here at
> Apache has to be to grow the community of contributors from the user
> community which will not be completely the same for the three projects.
> I've used Drools in the past, but not jBPM or Kogito.
>
> Niall
>
>
>
> Then there are the supporting repos for things like examples, docs,
> website, tooling, etc. Many of the people working on these projects work on
> all of them, so it would probably be the same group of people with very
> little deviation in the list of committers. Could they be different PPMCs,
> but they’d basically be the same group, just more work with the reports,
> setup, infra, etc.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
--
Best wishes！
CalvinKirs
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
We don’t feel like KIE and Servicecomb-kie clash. One is an acronym (KIE- Knowledge Is Everything), and the other is a suffix. Both projects are very different as well. Servicecomb-kie is a configuration center for microservices written in Go, whereas KIE is a knowledge engineering and process automation solution written in Java. For example, how was this handled in the context of Apache DeltaCloud and Apache DeltaSpike; or Apache DataFu and Apache DataLab? Is there precedence within the ASF for similarly named projects? The two communities have also co-existed for roughly the same time, using the same names without clashes.
As was stated previously, the number of projects is much smaller than the number of GitHub repos. This is because KIE did not use a singular repository model within the GitHub organization. The projects we’re currently considering in this proposal are Kogito, jBPM, Drools, KIE-Tools, and another project for the CNCF Serverless Workflow implementation that is going through a naming process now. KIE-Tools is a little odd, though, as it doesn’t stand on its own well. The existing code base contains a lot of modules and code, which could be considered legacy, which we do not plan to move over. There will be a cleaning and pruning process to ensure a more relevant, sustainable, and forward-looking set of modules as code is moved over. This should further reduce the amount of code that is moved over. We understand we may need to collapse the repositories moving over to the ASF. Let us know if you want to see how everything rolls into a more flat structure.
Regarding umbrella versus standalone projects, we believe that the unified and cohesive experience provides more value than just the sum of its parts. This is also not just about where we are now, but where we hope to evolve as a knowledge engineering platform. On the surface, those projects can be seen as independent in their business rules, decisions, and workflow domains. However, real-world use cases are more complex. Usually, they require a lot of interdependencies, for example, business rules orchestration is accomplished by using a workflow file definition (i.e., BPMN), and complex workflow decisions are better modeled in DMN models. The aim is to try and drive consistency and ease of use across those technologies, in an integrated and holistic manner.
If those projects end up as individual TLPs, it'll be up to users to write a lot of boiler-plate code - or create additional new projects to handle and abstract the unified experience.
Of course, as a consequence of the unified vision, the current codebase is taking advantage of this unification, which means there's a lot of shared code among the projects. Moving away from this will also result in more top-level supporting projects to provide additional code, needed as foundational code or integration code, which may actually create more complexity and end-user confusion.
Although it might not be the most popular example within Apache, KIE aims to provide a similar umbrella cohesiveness that Apache OpenOffice has for their sub-projects like Write and Calc. We really want the community to think of knowledge engineering as a whole domain of technologies for problem-solving, and not on individual silo technologies.
Lastly, fracturing the community we have already created around the KIE brand and concept is certainly not ideal and will weaken the overall project brands and success. We believe we'll be able to leverage further what we currently have in the community and build upon it to create a more cohesive knowledge-processing solution if everything stays together and people remain invested in the success of the knowledge engineering platform as a whole, rather than their individual technologies.
We would like to initially keep the PPMC small, ideally 5-7 people. We have around 50 people identified as initial committers, but having a PMC that large during incubation is not ideal for the issues that have been mentioned.
Jason Porter
Software Engineer
He/Him/His
IBM
On Dec 9, 2022, at 08:17, Niall Pemberton <ni...@gmail.com> wrote:
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid>> wrote:
On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
wrote:
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache
and teach them how to do things, if they are doing their job correctly,
they should also really audit the releases being done and help get the
codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the
mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)?
There each project could have their initial PPMC and committer lists and it
would spread out the load a bit. However I would expect staffing 12
projects with enough work-willing mentors will still be challenging and I
would assume not all of them to find enough of them, but it could be one
first step.
Or is there an advantage of considering all projects as one unity?
Chris
[snip]
That is part of a broader question. Some of those repos are things like
examples for kogito, the website, etc. Things that are part of the projects
themselves, but don’t have a life outside of the project to which they
belong. I understand we’ll probably have to collapse the structures within
Apache and have a single repo per project. What we’re really looking at as
far as projects being donated:
Kogito
Drools
jBPM
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
Then there are the supporting repos for things like examples, docs,
website, tooling, etc. Many of the people working on these projects work on
all of them, so it would probably be the same group of people with very
little deviation in the list of committers. Could they be different PPMCs,
but they’d basically be the same group, just more work with the reports,
setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
Re: [DISCUSS] KIE Proposal
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, 6 Dec 2022 at 16:27, Jason Porter <jp...@ibm.com.invalid> wrote:
>
> > On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de>
> wrote:
> >
> > Hi Jason,
> >
> > Well, those numbers are a bit better than the initial ones.
> > Thing is: Mentors will not only have to help onboard people to Apache
> and teach them how to do things, if they are doing their job correctly,
> they should also really audit the releases being done and help get the
> codebase into shape first.
> >
> > Even with 12 sub-projects, work-wise that would put a load on the
> mentors, as if they signed up for mentoring 12 projects.
> >
> > So how about bringing in projects separately (where it makes sense)?
> There each project could have their initial PPMC and committer lists and it
> would spread out the load a bit. However I would expect staffing 12
> projects with enough work-willing mentors will still be challenging and I
> would assume not all of them to find enough of them, but it could be one
> first step.
> >
> > Or is there an advantage of considering all projects as one unity?
> >
> > Chris
> >
> > [snip]
>
> That is part of a broader question. Some of those repos are things like
> examples for kogito, the website, etc. Things that are part of the projects
> themselves, but don’t have a life outside of the project to which they
> belong. I understand we’ll probably have to collapse the structures within
> Apache and have a single repo per project. What we’re really looking at as
> far as projects being donated:
>
> Kogito
> Drools
> jBPM
>
I really think these should be separate projects. I realize theres a
dependency/hierarchy between them (jBPM using Drools as its rules engine
and Kogito using jBPM for its business process/workflow) - but people use
Drools without jBPM and (I assume) jBPM without Kogito. Even if the current
set of contributors all work on all three projects, the aspiration here at
Apache has to be to grow the community of contributors from the user
community which will not be completely the same for the three projects.
I've used Drools in the past, but not jBPM or Kogito.
Niall
>
> Then there are the supporting repos for things like examples, docs,
> website, tooling, etc. Many of the people working on these projects work on
> all of them, so it would probably be the same group of people with very
> little deviation in the list of committers. Could they be different PPMCs,
> but they’d basically be the same group, just more work with the reports,
> setup, infra, etc.
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
> On Dec 6, 2022, at 01:43, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Jason,
>
> Well, those numbers are a bit better than the initial ones.
> Thing is: Mentors will not only have to help onboard people to Apache and teach them how to do things, if they are doing their job correctly, they should also really audit the releases being done and help get the codebase into shape first.
>
> Even with 12 sub-projects, work-wise that would put a load on the mentors, as if they signed up for mentoring 12 projects.
>
> So how about bringing in projects separately (where it makes sense)? There each project could have their initial PPMC and committer lists and it would spread out the load a bit. However I would expect staffing 12 projects with enough work-willing mentors will still be challenging and I would assume not all of them to find enough of them, but it could be one first step.
>
> Or is there an advantage of considering all projects as one unity?
>
> Chris
>
> [snip]
That is part of a broader question. Some of those repos are things like examples for kogito, the website, etc. Things that are part of the projects themselves, but don’t have a life outside of the project to which they belong. I understand we’ll probably have to collapse the structures within Apache and have a single repo per project. What we’re really looking at as far as projects being donated:
Kogito
Drools
jBPM
Then there are the supporting repos for things like examples, docs, website, tooling, etc. Many of the people working on these projects work on all of them, so it would probably be the same group of people with very little deviation in the list of committers. Could they be different PPMCs, but they’d basically be the same group, just more work with the reports, setup, infra, etc.
Jason Porter
Software Engineer
He/Him/His
IBM
Re: [DISCUSS] KIE Proposal
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Jason,
Well, those numbers are a bit better than the initial ones.
Thing is: Mentors will not only have to help onboard people to Apache and teach them how to do things, if they are doing their job correctly, they should also really audit the releases being done and help get the codebase into shape first.
Even with 12 sub-projects, work-wise that would put a load on the mentors, as if they signed up for mentoring 12 projects.
So how about bringing in projects separately (where it makes sense)? There each project could have their initial PPMC and committer lists and it would spread out the load a bit. However I would expect staffing 12 projects with enough work-willing mentors will still be challenging and I would assume not all of them to find enough of them, but it could be one first step.
Or is there an advantage of considering all projects as one unity?
Chris
From: Jason Porter <jp...@ibm.com.INVALID>
Date: Monday, 5. December 2022 at 19:08
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: Re: [DISCUSS] KIE Proposal
On Dec 5, 2022, at 01:23, Christofer Dutz <ch...@c-ware.de> wrote:
Hi all,
as you already mentioned PLC4X, I think in general supporting something to do logic-decisions based on industrial data-streams would be a nice addition. I do also agree that adding 80 projects might be quite a big gulp for us to ingest.
How many people are we talking about being on the IPMC/committers? Mentoring a project with hundreds of people would probably require a fleet of mentors.
Hey Chris,
The size of the PPMC is a good question. Per the Incubator site [https://incubator.apache.org/guides/ppmc.html] it is typically made up of the initial committers and mentors. We have 51 people currently tagged for being initial committers and three people as mentors. Most have not done anything with Apache. That feels like a lot of people for an initial PPMC. We were initially thinking of something small around 7 people initially. Not sure how that plays in with the list of initial committers though, unless we par that down as well and bring people in during the incubation.
WRT the number of projects, we’re not looking at donating all of those. We’re still in discussion on the final list, but that list is considerably smaller. Discussions are leaning toward 12 or so.
Jason Porter
Software Engineer
He/Him/His
IBM
Chris
From: Willem Jiang <wi...@gmail.com>>
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
<ni...@gmail.com> wrote:
Wow, 137 GitHub repositories!
OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?
Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.
To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
* drools
* jbpm
* kogito
* optaplanner
* kie ???
Niall
On Thu, 1 Dec 2022 at 21:36, Jason Porter <jp...@ibm.com.invalid> wrote:
Abstract
KIE (Knowledge is Everything) is a community of solutions and supporting
tooling for knowledge engineering and process automation, focusing on
events, rules, and workflows.
Proposal<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
KIE is a community dedicated to supporting knowledge engineering and
process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
comprised of leading open-source projects (like Drools and jBPM), which
provide modeling and code authoring tools in this space. The work has a
strong emphasis on being a first-class citizen for Kubernetes but will
continue to support embedded and other environments such as edge computing.
Drools and jBPM are well-known projects in their areas of rules and
workflow and they will be joined by another project, building on a shared
core with jBPM, for CNCF’s Serverless Workflow - this project is going
through a naming process at the time of this application. Kogito is the
foundation project for workflow which jBPM and CNCF’s Serverless Workflow
build on. Services and frameworks are provided to enable those projects in
a cloud-native environment and tooling is made available through KIE Tools.
Background<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
Experience has shown that a holistic approach is a practical requirement
for any knowledge engineering and process automation. This requires a
breadth of capabilities able to model and execute an application’s data
models, rules, workflows, and events. These projects aim to provide a
holistic approach with a strong emphasis on congruency across them.
Rationale<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
Knowledge engineering and process automation have been and continue to
play a large part in today’s software lifecycle. To date, there have been
few truly open-source implementations of any of the specifications (DMN,
PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
these standards and fill that gap of having an open-source implementation.
The projects within KIE also mesh well with other Apache projects such as
Apache Camel and Apache Airavata. Integrations could be done at the IoT
level with Apache PLC4X and others.
Developers need a solution that follows, implements, and collaborates with
these industry specifications. The Apache Software Foundation would allow
these projects to continue to grow in a vendor-neutral environment and
promote further collaboration with existing integrations and future
partners.
Initial Goals<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
First and foremost, we aim to enlarge the community. KIE has primarily
been an open-source community of Red Hat Developers and users outside of
Red Hat. Adding IBM to the list of developers helps, but we would like to
see more. We have ideas for the various sub-projects, such as
straight-through processing support in Kogito, better spec compliance for
the tooling, and more research into language bindings for non-Java
languages. We believe we can address some of these while an Apache
Incubator project.
Current Status<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
Code for the various projects with the KIE community is all hosted on
GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code
is Apache 2 licensed. Red Hat has been the project’s custodian since its
inception and has maintained leadership in that area. Moving forward into
the Apache Incubator, we would need to establish the habit of holding votes
and meetings and the project updates per the Apache Way.
We also currently maintain a YouTube channel dedicated to the community
and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
Meritocracy:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy
Red Hat runs all of its open-source projects as meritocracies, the KIE
Community is no different. This aspect would not change any. Kogito
currently does not make a distinction between “committer” and “PMC member”
the same way Apache does. That aspect would need implementation.
Community:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community
The KIE Community has an active base of contributors within and outside
Red Hat. Community members currently use Zulip chat or mailing lists hosted
by Google Groups as communication tools. It has been that way for many
years. Before that, we were using IRC at Freenode for many years. There are
also mailing lists hosted on Google Groups that are leveraged for those who
prefer mailing list communication. Zulip was started as a standard
communication medium for KIE Community back in 2020. IRC has been used
since 2003.
Core Developers:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers
Core developers would come from both Red Hat and IBM. They include people
who have been working on related projects and the creation of the KIE
Community since the beginning, and also people new to the project.
Alignment:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment
Projects within the KIE Community align with multiple efforts within
Apache, namely:
* Apache OpenWhisk
* Apache Airavata
* Apache Camel
We are currently actively involved in collaboration with Apache Camel,
while the other two are more alignments and usages within the communities.
There may be other Apache projects which could benefit from integration
with KIE Community projects.
jBPM, the proposed Serverless Workflow project and the Kogito workflow
foundation are targeting serverless and microservice deployments. It helps
to create automation and integration with other technologies in a
simple-to-use and understandable way. The Apache Software Foundation is a
great place to collaborate with multiple companies and technologies. We’re
looking to build a community that is inclusive, helpful, and a good citizen
to the larger Open Source community.
Other projects within the KIE Community umbrella target a more standard
enterprise software approach and deployment model.
Known Risks<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks
The Kogito workflow foundation targets the Quarkus environment, an
open-source project that Red Hat maintains. Should Red Hat no longer wish
to maintain Quarkus or move it in a direction that harms Kogito, a pivot
may be necessary. The Kogito workflow foundation will still run on other
runtimes, so it is less of a risk as well.
There should not be any risks for other projects.
Project Name<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name
All names and trademarks have been vetted by Red Hat’s legal team to be
usable in the space. Transferring these over to Apache will not be a
problem.
Orphaned products<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products
Primary contributions to the KIE Community of projects will be made by
engineers employed by Red Hat and IBM. IBM is a leading vendor in the
Business Automation space. Red Hat up until the second half of 2022 was
also a major vendor in the same space. While Red Hat is no longer pursuing
the Business Automation market it does still need to augment the
capabilities of its other products with workflow, rules, and event
technologies in a way that aligns with Red Hat’s target audiences and Red
Hat’s strategic direction. Red Hat will continue to pursue the development
around CNCF serverless workflow, which will be built upon Kogito and
Drools. There is no risk of these projects being orphaned by either company.
Inexperience with Open Source:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source
All initial committers are well-versed in Open Source development.
Length of Incubation:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation
Incubation should take somewhere between six to twelve months.
Homogenous Developers:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers
The list of initial project committers includes developers from IBM and
Red Hat, all from different locations around the world.
Reliance on Salaried Developers:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers
Currently, the list of developers is from IBM and Red Hat. We’re hoping by
moving to Apache we can grow this list of developers outside of those two
companies. All the projects within KIE have been around for a long time and
have a large user base. Developers have come and gone over the years, but
the initial list of developers is coming from Red Hat and IBM.
Relationships with Other Apache Products:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products
The Apache Camel project has had integrations with KIE Community projects,
namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito
and Camel also have integrations with Quarkus. Kogito is built using Apache
Maven.
An Excessive Fascination with the Apache Brand:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand
We have looked at both the Apache Software Foundation and the Eclipse
Foundation and have decided that Apache would be a better place for the
code base. Red Hat, and IBM, have worked with both foundations and continue
to do so.
While the Apache brand is indeed well known and has great recognition,
we’re looking more toward the neutral nature of being at Apache and keeping
the project alive in an environment that is not solely controlled by a
single entity.
Documentation<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation
Kogito Documentation:
https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
Drools Documentation: https://www.drools.org/learn/documentation.html
jBPM Documentation:
https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
DMN Specification: https://www.omg.org/spec/DMN
BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
Cloud Events Specification: https://github.com/cloudevents/spec
Initial Source<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source
All the code will be coming from the KIE Community GitHub repo at
https://github.com/kiegroup . There will be multiple repositories
including examples and code bases for Drools, jBPM, and Kogito.
Source and Intellectual Property Submission Plan<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan
* Source code within GitHub
* Domains: kie.org<http://kie.org/>, kogito.org<http://kogito.org/>, kogito.kie.org<http://kogito.kie.org/>, blog.kie.org<http://blog.kie.org/>, jbpm.org<http://jbpm.org/>,
drools.org<http://drools.org/>, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org<http://sandbox.kie.org/> are all
currently owned by Red Hat
External Dependencies:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies
There are some LGPL, and Eclipse dependencies for some of the projects in
the test or provided scopes of the Maven poms. For example jdt dependencies
for the Eclipse plugins, logback, junit, and similar. Hibernate jars are
LGPL as well, those are in jBPM.
Cryptography:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography
There are some calls to the JVM vault, for process migration.
Required Resources<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources
Mailing lists:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists
* private@kie.incubator.apache.org<ma...@kie.incubator.apache.org>
* dev@kie.incubator.apache.org<ma...@kie.incubator.apache.org>
* commits@kie.incubator.apache.org<ma...@kie.incubator.apache.org>
Subversion Directory:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory
None
Git Repositories:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories
Assuming we can continue to use GitHub, though it may need to migrate to
be beneath the Apache Organization.
Issue Tracking:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking
If possible, we would like to use GitHub issues.
Other Resources:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources
None.
Initial Committers<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers
List of GitHub names:
Name
GitHub Username
Apache CLA
Apache Email
Mario Fusco
mariofusco
FALSE
Toshiya Kobayashi
tkobayas
TRUE
Matteo Mortari
tarilabs
TRUE
Tristan Radisson
radtriste
FALSE
Gabriele Cardosi
gitgabrio
FALSE
Edoardo Vacchi
evacchi
FALSE
Paolo Bizzarri
pibizza
FALSE
Cristiano Nicolai
cristianonicolai
FALSE
Michael Biarnés Kiefer
mbiarnes
FALSE
Enrique González Martínez
elguardian
FALSE
Vani Haripriya Mudadla
vaniharipriya
FALSE
Jason Porter
lightguard
TRUE
lightguardjp@apache.org<ma...@apache.org>
Gonzalo Muñoz
gmunozfe
FALSE
Francisco Javier Tirado Sarti
fjtirado
FALSE
Helber Belmiro
hbelmiro
TRUE
Antonio Fernandez Alhambra
afalhambra
FALSE
Abhijit Humbe
abhijithumbe
FALSE
Martin Weiler
martinweiler
FALSE
Enrique Mingorance Cano
ginxo
FALSE
Tiago Dolphine
tiagodolphine
FALSE
Alex Porcelli
porcelli
FALSE
Kris Verlaenen
krisv
TRUE
(requested krisv@apache.org<ma...@apache.org>)
Pere Fernández
pefernan
FALSE
Jan Stastny
jstastny-cz
FALSE
Jozef Marko
jomarko
FALSE
Walter Medvedeo
wmedvede
FALSE
Kennedy Bowers
kbowers-redhat
FALSE
Roberto Oliveira
rgdoliveira
FALSE
Andrea Lamparelli
lampajr
FALSE
Bai Xiaofeng
bxf12315
FALSE
Ruben Romero Montes
ruromero
FALSE
Filippe Spolti
spolti
FALSE
Massimiliano Dessì
desmax74
TRUE
Tiago Bento
tiagobento
FALSE
Yeser Amer
yesamer
FALSE
Guilherme Caponetto
caponetto
FALSE
Paulo Martins
paulovmr
FALSE
Thiago Lugli
thiagoelg
FALSE
William Antônio Siqueira
jesuino
FALSE
Fabrizio Antonangeli
fantonangeli
FALSE
Valentino Pellegrino
vpellegrino
FALSE
Ricardo Zanini
ricardozanini
FALSE
Tibor Zimányi
baldimir
FALSE
Eder Ignatowicz
ederign
FALSE
Mark Proctor
mdproctor
FALSE
Thiago Lugli
thiagoelg
FALSE
Luiz João Motta
ljmotta
FALSE
Jaime Enriquez
inodeman
FALSE
Luca Molteni
lucamolteni
FALSE
Davide Salerno
davidesalerno
TRUE
Edson Tirelli
etirelli
FALSE
Sponsors<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors
IBM and Red Hat are the sponsors for the project.
Champion:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion
Brian Proffitt
Nominated Mentors:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors
Brian Proffitt
Claus Ibsen
Andrea Cosentino
Sponsoring Entity:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity
Apache Camel
Jason Porter
Software Engineer
He/Him/His
IBM
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org<ma...@incubator.apache.org>
For additional commands, e-mail: general-help@incubator.apache.org<ma...@incubator.apache.org>
Re: [DISCUSS] KIE Proposal
Posted by Jason Porter <jp...@ibm.com.INVALID>.
On Dec 5, 2022, at 01:23, Christofer Dutz <ch...@c-ware.de> wrote:
Hi all,
as you already mentioned PLC4X, I think in general supporting something to do logic-decisions based on industrial data-streams would be a nice addition. I do also agree that adding 80 projects might be quite a big gulp for us to ingest.
How many people are we talking about being on the IPMC/committers? Mentoring a project with hundreds of people would probably require a fleet of mentors.
Hey Chris,
The size of the PPMC is a good question. Per the Incubator site [https://incubator.apache.org/guides/ppmc.html] it is typically made up of the initial committers and mentors. We have 51 people currently tagged for being initial committers and three people as mentors. Most have not done anything with Apache. That feels like a lot of people for an initial PPMC. We were initially thinking of something small around 7 people initially. Not sure how that plays in with the list of initial committers though, unless we par that down as well and bring people in during the incubation.
WRT the number of projects, we’re not looking at donating all of those. We’re still in discussion on the final list, but that list is considerably smaller. Discussions are leaning toward 12 or so.
Jason Porter
Software Engineer
He/Him/His
IBM
Chris
From: Willem Jiang <wi...@gmail.com>>
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org<ma...@incubator.apache.org> <ge...@incubator.apache.org>>
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
<ni...@gmail.com> wrote:
Wow, 137 GitHub repositories!
OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?
Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.
To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
* drools
* jbpm
* kogito
* optaplanner
* kie ???
Niall
On Thu, 1 Dec 2022 at 21:36, Jason Porter <jp...@ibm.com.invalid> wrote:
Abstract
KIE (Knowledge is Everything) is a community of solutions and supporting
tooling for knowledge engineering and process automation, focusing on
events, rules, and workflows.
Proposal<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
KIE is a community dedicated to supporting knowledge engineering and
process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
comprised of leading open-source projects (like Drools and jBPM), which
provide modeling and code authoring tools in this space. The work has a
strong emphasis on being a first-class citizen for Kubernetes but will
continue to support embedded and other environments such as edge computing.
Drools and jBPM are well-known projects in their areas of rules and
workflow and they will be joined by another project, building on a shared
core with jBPM, for CNCF’s Serverless Workflow - this project is going
through a naming process at the time of this application. Kogito is the
foundation project for workflow which jBPM and CNCF’s Serverless Workflow
build on. Services and frameworks are provided to enable those projects in
a cloud-native environment and tooling is made available through KIE Tools.
Background<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
Experience has shown that a holistic approach is a practical requirement
for any knowledge engineering and process automation. This requires a
breadth of capabilities able to model and execute an application’s data
models, rules, workflows, and events. These projects aim to provide a
holistic approach with a strong emphasis on congruency across them.
Rationale<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
Knowledge engineering and process automation have been and continue to
play a large part in today’s software lifecycle. To date, there have been
few truly open-source implementations of any of the specifications (DMN,
PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
these standards and fill that gap of having an open-source implementation.
The projects within KIE also mesh well with other Apache projects such as
Apache Camel and Apache Airavata. Integrations could be done at the IoT
level with Apache PLC4X and others.
Developers need a solution that follows, implements, and collaborates with
these industry specifications. The Apache Software Foundation would allow
these projects to continue to grow in a vendor-neutral environment and
promote further collaboration with existing integrations and future
partners.
Initial Goals<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
First and foremost, we aim to enlarge the community. KIE has primarily
been an open-source community of Red Hat Developers and users outside of
Red Hat. Adding IBM to the list of developers helps, but we would like to
see more. We have ideas for the various sub-projects, such as
straight-through processing support in Kogito, better spec compliance for
the tooling, and more research into language bindings for non-Java
languages. We believe we can address some of these while an Apache
Incubator project.
Current Status<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
Code for the various projects with the KIE community is all hosted on
GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code
is Apache 2 licensed. Red Hat has been the project’s custodian since its
inception and has maintained leadership in that area. Moving forward into
the Apache Incubator, we would need to establish the habit of holding votes
and meetings and the project updates per the Apache Way.
We also currently maintain a YouTube channel dedicated to the community
and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
Meritocracy:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy
Red Hat runs all of its open-source projects as meritocracies, the KIE
Community is no different. This aspect would not change any. Kogito
currently does not make a distinction between “committer” and “PMC member”
the same way Apache does. That aspect would need implementation.
Community:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community
The KIE Community has an active base of contributors within and outside
Red Hat. Community members currently use Zulip chat or mailing lists hosted
by Google Groups as communication tools. It has been that way for many
years. Before that, we were using IRC at Freenode for many years. There are
also mailing lists hosted on Google Groups that are leveraged for those who
prefer mailing list communication. Zulip was started as a standard
communication medium for KIE Community back in 2020. IRC has been used
since 2003.
Core Developers:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers
Core developers would come from both Red Hat and IBM. They include people
who have been working on related projects and the creation of the KIE
Community since the beginning, and also people new to the project.
Alignment:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment
Projects within the KIE Community align with multiple efforts within
Apache, namely:
* Apache OpenWhisk
* Apache Airavata
* Apache Camel
We are currently actively involved in collaboration with Apache Camel,
while the other two are more alignments and usages within the communities.
There may be other Apache projects which could benefit from integration
with KIE Community projects.
jBPM, the proposed Serverless Workflow project and the Kogito workflow
foundation are targeting serverless and microservice deployments. It helps
to create automation and integration with other technologies in a
simple-to-use and understandable way. The Apache Software Foundation is a
great place to collaborate with multiple companies and technologies. We’re
looking to build a community that is inclusive, helpful, and a good citizen
to the larger Open Source community.
Other projects within the KIE Community umbrella target a more standard
enterprise software approach and deployment model.
Known Risks<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks
The Kogito workflow foundation targets the Quarkus environment, an
open-source project that Red Hat maintains. Should Red Hat no longer wish
to maintain Quarkus or move it in a direction that harms Kogito, a pivot
may be necessary. The Kogito workflow foundation will still run on other
runtimes, so it is less of a risk as well.
There should not be any risks for other projects.
Project Name<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name
All names and trademarks have been vetted by Red Hat’s legal team to be
usable in the space. Transferring these over to Apache will not be a
problem.
Orphaned products<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products
Primary contributions to the KIE Community of projects will be made by
engineers employed by Red Hat and IBM. IBM is a leading vendor in the
Business Automation space. Red Hat up until the second half of 2022 was
also a major vendor in the same space. While Red Hat is no longer pursuing
the Business Automation market it does still need to augment the
capabilities of its other products with workflow, rules, and event
technologies in a way that aligns with Red Hat’s target audiences and Red
Hat’s strategic direction. Red Hat will continue to pursue the development
around CNCF serverless workflow, which will be built upon Kogito and
Drools. There is no risk of these projects being orphaned by either company.
Inexperience with Open Source:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source
All initial committers are well-versed in Open Source development.
Length of Incubation:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation
Incubation should take somewhere between six to twelve months.
Homogenous Developers:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers
The list of initial project committers includes developers from IBM and
Red Hat, all from different locations around the world.
Reliance on Salaried Developers:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers
Currently, the list of developers is from IBM and Red Hat. We’re hoping by
moving to Apache we can grow this list of developers outside of those two
companies. All the projects within KIE have been around for a long time and
have a large user base. Developers have come and gone over the years, but
the initial list of developers is coming from Red Hat and IBM.
Relationships with Other Apache Products:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products
The Apache Camel project has had integrations with KIE Community projects,
namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito
and Camel also have integrations with Quarkus. Kogito is built using Apache
Maven.
An Excessive Fascination with the Apache Brand:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand
We have looked at both the Apache Software Foundation and the Eclipse
Foundation and have decided that Apache would be a better place for the
code base. Red Hat, and IBM, have worked with both foundations and continue
to do so.
While the Apache brand is indeed well known and has great recognition,
we’re looking more toward the neutral nature of being at Apache and keeping
the project alive in an environment that is not solely controlled by a
single entity.
Documentation<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation
Kogito Documentation:
https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
Drools Documentation: https://www.drools.org/learn/documentation.html
jBPM Documentation:
https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
DMN Specification: https://www.omg.org/spec/DMN
BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
Cloud Events Specification: https://github.com/cloudevents/spec
Initial Source<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source
All the code will be coming from the KIE Community GitHub repo at
https://github.com/kiegroup . There will be multiple repositories
including examples and code bases for Drools, jBPM, and Kogito.
Source and Intellectual Property Submission Plan<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan
* Source code within GitHub
* Domains: kie.org<http://kie.org/>, kogito.org<http://kogito.org/>, kogito.kie.org<http://kogito.kie.org/>, blog.kie.org<http://blog.kie.org/>, jbpm.org<http://jbpm.org/>,
drools.org<http://drools.org/>, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org<http://sandbox.kie.org/> are all
currently owned by Red Hat
External Dependencies:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies
There are some LGPL, and Eclipse dependencies for some of the projects in
the test or provided scopes of the Maven poms. For example jdt dependencies
for the Eclipse plugins, logback, junit, and similar. Hibernate jars are
LGPL as well, those are in jBPM.
Cryptography:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography
There are some calls to the JVM vault, for process migration.
Required Resources<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources
Mailing lists:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists
* private@kie.incubator.apache.org<ma...@kie.incubator.apache.org>
* dev@kie.incubator.apache.org<ma...@kie.incubator.apache.org>
* commits@kie.incubator.apache.org<ma...@kie.incubator.apache.org>
Subversion Directory:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory
None
Git Repositories:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories
Assuming we can continue to use GitHub, though it may need to migrate to
be beneath the Apache Organization.
Issue Tracking:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking
If possible, we would like to use GitHub issues.
Other Resources:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources
None.
Initial Committers<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers
List of GitHub names:
Name
GitHub Username
Apache CLA
Apache Email
Mario Fusco
mariofusco
FALSE
Toshiya Kobayashi
tkobayas
TRUE
Matteo Mortari
tarilabs
TRUE
Tristan Radisson
radtriste
FALSE
Gabriele Cardosi
gitgabrio
FALSE
Edoardo Vacchi
evacchi
FALSE
Paolo Bizzarri
pibizza
FALSE
Cristiano Nicolai
cristianonicolai
FALSE
Michael Biarnés Kiefer
mbiarnes
FALSE
Enrique González Martínez
elguardian
FALSE
Vani Haripriya Mudadla
vaniharipriya
FALSE
Jason Porter
lightguard
TRUE
lightguardjp@apache.org<ma...@apache.org>
Gonzalo Muñoz
gmunozfe
FALSE
Francisco Javier Tirado Sarti
fjtirado
FALSE
Helber Belmiro
hbelmiro
TRUE
Antonio Fernandez Alhambra
afalhambra
FALSE
Abhijit Humbe
abhijithumbe
FALSE
Martin Weiler
martinweiler
FALSE
Enrique Mingorance Cano
ginxo
FALSE
Tiago Dolphine
tiagodolphine
FALSE
Alex Porcelli
porcelli
FALSE
Kris Verlaenen
krisv
TRUE
(requested krisv@apache.org<ma...@apache.org>)
Pere Fernández
pefernan
FALSE
Jan Stastny
jstastny-cz
FALSE
Jozef Marko
jomarko
FALSE
Walter Medvedeo
wmedvede
FALSE
Kennedy Bowers
kbowers-redhat
FALSE
Roberto Oliveira
rgdoliveira
FALSE
Andrea Lamparelli
lampajr
FALSE
Bai Xiaofeng
bxf12315
FALSE
Ruben Romero Montes
ruromero
FALSE
Filippe Spolti
spolti
FALSE
Massimiliano Dessì
desmax74
TRUE
Tiago Bento
tiagobento
FALSE
Yeser Amer
yesamer
FALSE
Guilherme Caponetto
caponetto
FALSE
Paulo Martins
paulovmr
FALSE
Thiago Lugli
thiagoelg
FALSE
William Antônio Siqueira
jesuino
FALSE
Fabrizio Antonangeli
fantonangeli
FALSE
Valentino Pellegrino
vpellegrino
FALSE
Ricardo Zanini
ricardozanini
FALSE
Tibor Zimányi
baldimir
FALSE
Eder Ignatowicz
ederign
FALSE
Mark Proctor
mdproctor
FALSE
Thiago Lugli
thiagoelg
FALSE
Luiz João Motta
ljmotta
FALSE
Jaime Enriquez
inodeman
FALSE
Luca Molteni
lucamolteni
FALSE
Davide Salerno
davidesalerno
TRUE
Edson Tirelli
etirelli
FALSE
Sponsors<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors
IBM and Red Hat are the sponsors for the project.
Champion:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion
Brian Proffitt
Nominated Mentors:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors
Brian Proffitt
Claus Ibsen
Andrea Cosentino
Sponsoring Entity:<
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity
Apache Camel
Jason Porter
Software Engineer
He/Him/His
IBM
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org<ma...@incubator.apache.org>
For additional commands, e-mail: general-help@incubator.apache.org<ma...@incubator.apache.org>
Re: [DISCUSS] KIE Proposal
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
as you already mentioned PLC4X, I think in general supporting something to do logic-decisions based on industrial data-streams would be a nice addition. I do also agree that adding 80 projects might be quite a big gulp for us to ingest.
How many people are we talking about being on the IPMC/committers? Mentoring a project with hundreds of people would probably require a fleet of mentors.
Chris
From: Willem Jiang <wi...@gmail.com>
Date: Monday, 5. December 2022 at 04:15
To: general@incubator.apache.org <ge...@incubator.apache.org>
Subject: Re: [DISCUSS] KIE Proposal
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
<ni...@gmail.com> wrote:
>
> Wow, 137 GitHub repositories!
>
> OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
> have a rough idea of how many of those would be part of the incubation?
>
> Historically, Apache has been against "Umbrella Projects" - encouraging
> them to break up and become individual Top Level Projects (TLP) in their
> own right - the biggest example of that was Jakarta which used to be
> anything java related - but there have been others where sub-projects which
> have a life of their own have moved out to become TLPs.
>
> To me this looks like it should be 4 or 5 projects - its not clear whether
> kie is a product in its own right (with releasable artifcats) or just the
> umbrella that the others are grouped under?
> * drools
> * jbpm
> * kogito
> * optaplanner
> * kie ???
>
> Niall
>
>
> On Thu, 1 Dec 2022 at 21:36, Jason Porter <jp...@ibm.com.invalid> wrote:
>
> > Abstract
> >
> > KIE (Knowledge is Everything) is a community of solutions and supporting
> > tooling for knowledge engineering and process automation, focusing on
> > events, rules, and workflows.
> >
> > Proposal<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> > >
> >
> > KIE is a community dedicated to supporting knowledge engineering and
> > process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> > CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> > comprised of leading open-source projects (like Drools and jBPM), which
> > provide modeling and code authoring tools in this space. The work has a
> > strong emphasis on being a first-class citizen for Kubernetes but will
> > continue to support embedded and other environments such as edge computing.
> > Drools and jBPM are well-known projects in their areas of rules and
> > workflow and they will be joined by another project, building on a shared
> > core with jBPM, for CNCF’s Serverless Workflow - this project is going
> > through a naming process at the time of this application. Kogito is the
> > foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> > build on. Services and frameworks are provided to enable those projects in
> > a cloud-native environment and tooling is made available through KIE Tools.
> >
> > Background<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> > >
> >
> > Experience has shown that a holistic approach is a practical requirement
> > for any knowledge engineering and process automation. This requires a
> > breadth of capabilities able to model and execute an application’s data
> > models, rules, workflows, and events. These projects aim to provide a
> > holistic approach with a strong emphasis on congruency across them.
> >
> > Rationale<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> > >
> >
> > Knowledge engineering and process automation have been and continue to
> > play a large part in today’s software lifecycle. To date, there have been
> > few truly open-source implementations of any of the specifications (DMN,
> > PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> > these standards and fill that gap of having an open-source implementation.
> >
> >
> > The projects within KIE also mesh well with other Apache projects such as
> > Apache Camel and Apache Airavata. Integrations could be done at the IoT
> > level with Apache PLC4X and others.
> >
> >
> > Developers need a solution that follows, implements, and collaborates with
> > these industry specifications. The Apache Software Foundation would allow
> > these projects to continue to grow in a vendor-neutral environment and
> > promote further collaboration with existing integrations and future
> > partners.
> >
> > Initial Goals<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
> > >
> >
> > First and foremost, we aim to enlarge the community. KIE has primarily
> > been an open-source community of Red Hat Developers and users outside of
> > Red Hat. Adding IBM to the list of developers helps, but we would like to
> > see more. We have ideas for the various sub-projects, such as
> > straight-through processing support in Kogito, better spec compliance for
> > the tooling, and more research into language bindings for non-Java
> > languages. We believe we can address some of these while an Apache
> > Incubator project.
> >
> > Current Status<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
> > >
> >
> > Code for the various projects with the KIE community is all hosted on
> > GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code
> > is Apache 2 licensed. Red Hat has been the project’s custodian since its
> > inception and has maintained leadership in that area. Moving forward into
> > the Apache Incubator, we would need to establish the habit of holding votes
> > and meetings and the project updates per the Apache Way.
> >
> >
> > We also currently maintain a YouTube channel dedicated to the community
> > and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
> >
> > Meritocracy:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy
> > >
> >
> > Red Hat runs all of its open-source projects as meritocracies, the KIE
> > Community is no different. This aspect would not change any. Kogito
> > currently does not make a distinction between “committer” and “PMC member”
> > the same way Apache does. That aspect would need implementation.
> >
> > Community:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community
> > >
> >
> > The KIE Community has an active base of contributors within and outside
> > Red Hat. Community members currently use Zulip chat or mailing lists hosted
> > by Google Groups as communication tools. It has been that way for many
> > years. Before that, we were using IRC at Freenode for many years. There are
> > also mailing lists hosted on Google Groups that are leveraged for those who
> > prefer mailing list communication. Zulip was started as a standard
> > communication medium for KIE Community back in 2020. IRC has been used
> > since 2003.
> >
> > Core Developers:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers
> > >
> >
> > Core developers would come from both Red Hat and IBM. They include people
> > who have been working on related projects and the creation of the KIE
> > Community since the beginning, and also people new to the project.
> >
> > Alignment:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment
> > >
> >
> > Projects within the KIE Community align with multiple efforts within
> > Apache, namely:
> >
> > * Apache OpenWhisk
> >
> > * Apache Airavata
> >
> > * Apache Camel
> >
> >
> > We are currently actively involved in collaboration with Apache Camel,
> > while the other two are more alignments and usages within the communities.
> > There may be other Apache projects which could benefit from integration
> > with KIE Community projects.
> >
> >
> > jBPM, the proposed Serverless Workflow project and the Kogito workflow
> > foundation are targeting serverless and microservice deployments. It helps
> > to create automation and integration with other technologies in a
> > simple-to-use and understandable way. The Apache Software Foundation is a
> > great place to collaborate with multiple companies and technologies. We’re
> > looking to build a community that is inclusive, helpful, and a good citizen
> > to the larger Open Source community.
> >
> >
> > Other projects within the KIE Community umbrella target a more standard
> > enterprise software approach and deployment model.
> >
> > Known Risks<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks
> > >
> >
> > The Kogito workflow foundation targets the Quarkus environment, an
> > open-source project that Red Hat maintains. Should Red Hat no longer wish
> > to maintain Quarkus or move it in a direction that harms Kogito, a pivot
> > may be necessary. The Kogito workflow foundation will still run on other
> > runtimes, so it is less of a risk as well.
> >
> > There should not be any risks for other projects.
> >
> > Project Name<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name
> > >
> >
> > All names and trademarks have been vetted by Red Hat’s legal team to be
> > usable in the space. Transferring these over to Apache will not be a
> > problem.
> >
> > Orphaned products<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products
> > >
> >
> > Primary contributions to the KIE Community of projects will be made by
> > engineers employed by Red Hat and IBM. IBM is a leading vendor in the
> > Business Automation space. Red Hat up until the second half of 2022 was
> > also a major vendor in the same space. While Red Hat is no longer pursuing
> > the Business Automation market it does still need to augment the
> > capabilities of its other products with workflow, rules, and event
> > technologies in a way that aligns with Red Hat’s target audiences and Red
> > Hat’s strategic direction. Red Hat will continue to pursue the development
> > around CNCF serverless workflow, which will be built upon Kogito and
> > Drools. There is no risk of these projects being orphaned by either company.
> >
> > Inexperience with Open Source:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source
> > >
> >
> > All initial committers are well-versed in Open Source development.
> >
> > Length of Incubation:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation
> > >
> >
> > Incubation should take somewhere between six to twelve months.
> >
> > Homogenous Developers:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers
> > >
> >
> > The list of initial project committers includes developers from IBM and
> > Red Hat, all from different locations around the world.
> >
> > Reliance on Salaried Developers:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers
> > >
> >
> > Currently, the list of developers is from IBM and Red Hat. We’re hoping by
> > moving to Apache we can grow this list of developers outside of those two
> > companies. All the projects within KIE have been around for a long time and
> > have a large user base. Developers have come and gone over the years, but
> > the initial list of developers is coming from Red Hat and IBM.
> >
> > Relationships with Other Apache Products:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products
> > >
> >
> > The Apache Camel project has had integrations with KIE Community projects,
> > namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito
> > and Camel also have integrations with Quarkus. Kogito is built using Apache
> > Maven.
> >
> > An Excessive Fascination with the Apache Brand:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand
> > >
> >
> > We have looked at both the Apache Software Foundation and the Eclipse
> > Foundation and have decided that Apache would be a better place for the
> > code base. Red Hat, and IBM, have worked with both foundations and continue
> > to do so.
> >
> >
> > While the Apache brand is indeed well known and has great recognition,
> > we’re looking more toward the neutral nature of being at Apache and keeping
> > the project alive in an environment that is not solely controlled by a
> > single entity.
> >
> > Documentation<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation
> > >
> >
> > Kogito Documentation:
> > https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
> >
> > Drools Documentation: https://www.drools.org/learn/documentation.html
> >
> > jBPM Documentation:
> > https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
> >
> > Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
> >
> > DMN Specification: https://www.omg.org/spec/DMN
> >
> > BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
> >
> > Cloud Events Specification: https://github.com/cloudevents/spec
> >
> > Initial Source<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source
> > >
> >
> > All the code will be coming from the KIE Community GitHub repo at
> > https://github.com/kiegroup. There will be multiple repositories
> > including examples and code bases for Drools, jBPM, and Kogito.
> >
> > Source and Intellectual Property Submission Plan<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan
> > >
> >
> > * Source code within GitHub
> >
> > * Domains: kie.org, kogito.org, kogito.kie.org, blog.kie.org, jbpm.org,
> > drools.org, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org are all
> > currently owned by Red Hat
> >
> > External Dependencies:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies
> > >
> >
> > There are some LGPL, and Eclipse dependencies for some of the projects in
> > the test or provided scopes of the Maven poms. For example jdt dependencies
> > for the Eclipse plugins, logback, junit, and similar. Hibernate jars are
> > LGPL as well, those are in jBPM.
> >
> > Cryptography:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography
> > >
> >
> > There are some calls to the JVM vault, for process migration.
> >
> > Required Resources<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources
> > >
> > Mailing lists:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists
> > >
> >
> > * private@kie.incubator.apache.org
> >
> > * dev@kie.incubator.apache.org
> >
> > * commits@kie.incubator.apache.org
> >
> > Subversion Directory:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory
> > >
> >
> > None
> >
> > Git Repositories:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories
> > >
> >
> > Assuming we can continue to use GitHub, though it may need to migrate to
> > be beneath the Apache Organization.
> >
> > Issue Tracking:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking
> > >
> >
> > If possible, we would like to use GitHub issues.
> >
> > Other Resources:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources
> > >
> >
> > None.
> >
> > Initial Committers<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers
> > >
> >
> >
> > List of GitHub names:
> >
> >
> > Name
> >
> > GitHub Username
> >
> > Apache CLA
> >
> > Apache Email
> >
> > Mario Fusco
> >
> > mariofusco
> >
> > FALSE
> >
> >
> > Toshiya Kobayashi
> >
> > tkobayas
> >
> > TRUE
> >
> >
> > Matteo Mortari
> >
> > tarilabs
> >
> > TRUE
> >
> >
> > Tristan Radisson
> >
> > radtriste
> >
> > FALSE
> >
> >
> > Gabriele Cardosi
> >
> > gitgabrio
> >
> > FALSE
> >
> >
> > Edoardo Vacchi
> >
> > evacchi
> >
> > FALSE
> >
> >
> > Paolo Bizzarri
> >
> > pibizza
> >
> > FALSE
> >
> >
> > Cristiano Nicolai
> >
> > cristianonicolai
> >
> > FALSE
> >
> >
> > Michael Biarnés Kiefer
> >
> > mbiarnes
> >
> > FALSE
> >
> >
> > Enrique González Martínez
> >
> > elguardian
> >
> > FALSE
> >
> >
> > Vani Haripriya Mudadla
> >
> > vaniharipriya
> >
> > FALSE
> >
> >
> > Jason Porter
> >
> > lightguard
> >
> > TRUE
> >
> > lightguardjp@apache.org
> >
> > Gonzalo Muñoz
> >
> > gmunozfe
> >
> > FALSE
> >
> >
> > Francisco Javier Tirado Sarti
> >
> > fjtirado
> >
> > FALSE
> >
> >
> > Helber Belmiro
> >
> > hbelmiro
> >
> > TRUE
> >
> >
> > Antonio Fernandez Alhambra
> >
> > afalhambra
> >
> > FALSE
> >
> >
> > Abhijit Humbe
> >
> > abhijithumbe
> >
> > FALSE
> >
> >
> > Martin Weiler
> >
> > martinweiler
> >
> > FALSE
> >
> >
> > Enrique Mingorance Cano
> >
> > ginxo
> >
> > FALSE
> >
> >
> > Tiago Dolphine
> >
> > tiagodolphine
> >
> > FALSE
> >
> >
> > Alex Porcelli
> >
> > porcelli
> >
> > FALSE
> >
> >
> > Kris Verlaenen
> >
> > krisv
> >
> > TRUE
> >
> > (requested krisv@apache.org)
> >
> > Pere Fernández
> >
> > pefernan
> >
> > FALSE
> >
> >
> > Jan Stastny
> >
> > jstastny-cz
> >
> > FALSE
> >
> >
> > Jozef Marko
> >
> > jomarko
> >
> > FALSE
> >
> >
> > Walter Medvedeo
> >
> > wmedvede
> >
> > FALSE
> >
> >
> > Kennedy Bowers
> >
> > kbowers-redhat
> >
> > FALSE
> >
> >
> > Roberto Oliveira
> >
> > rgdoliveira
> >
> > FALSE
> >
> >
> > Andrea Lamparelli
> >
> > lampajr
> >
> > FALSE
> >
> >
> > Bai Xiaofeng
> >
> > bxf12315
> >
> > FALSE
> >
> >
> > Ruben Romero Montes
> >
> > ruromero
> >
> > FALSE
> >
> >
> > Filippe Spolti
> >
> > spolti
> >
> > FALSE
> >
> >
> > Massimiliano Dessì
> >
> > desmax74
> >
> > TRUE
> >
> >
> > Tiago Bento
> >
> > tiagobento
> >
> > FALSE
> >
> >
> > Yeser Amer
> >
> > yesamer
> >
> > FALSE
> >
> >
> > Guilherme Caponetto
> >
> > caponetto
> >
> > FALSE
> >
> >
> > Paulo Martins
> >
> > paulovmr
> >
> > FALSE
> >
> >
> > Thiago Lugli
> >
> > thiagoelg
> >
> > FALSE
> >
> >
> > William Antônio Siqueira
> >
> > jesuino
> >
> > FALSE
> >
> >
> > Fabrizio Antonangeli
> >
> > fantonangeli
> >
> > FALSE
> >
> >
> > Valentino Pellegrino
> >
> > vpellegrino
> >
> > FALSE
> >
> >
> > Ricardo Zanini
> >
> > ricardozanini
> >
> > FALSE
> >
> >
> > Tibor Zimányi
> >
> > baldimir
> >
> > FALSE
> >
> >
> > Eder Ignatowicz
> >
> > ederign
> >
> > FALSE
> >
> >
> > Mark Proctor
> >
> > mdproctor
> >
> > FALSE
> >
> >
> > Thiago Lugli
> >
> > thiagoelg
> >
> > FALSE
> >
> >
> > Luiz João Motta
> >
> > ljmotta
> >
> > FALSE
> >
> >
> > Jaime Enriquez
> >
> > inodeman
> >
> > FALSE
> >
> >
> > Luca Molteni
> >
> > lucamolteni
> >
> > FALSE
> >
> >
> > Davide Salerno
> >
> > davidesalerno
> >
> > TRUE
> >
> >
> > Edson Tirelli
> >
> > etirelli
> >
> > FALSE
> >
> > Sponsors<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors
> > >
> >
> > IBM and Red Hat are the sponsors for the project.
> >
> > Champion:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion
> > >
> >
> > Brian Proffitt
> >
> > Nominated Mentors:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors
> > >
> >
> > Brian Proffitt
> >
> > Claus Ibsen
> >
> > Andrea Cosentino
> >
> > Sponsoring Entity:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity
> > >
> >
> > Apache Camel
> >
> >
> > Jason Porter
> > Software Engineer
> > He/Him/His
> >
> > IBM
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Willem Jiang <wi...@gmail.com>.
We need to go through the IP clearance and help the project to do the
release that follows the Apache police.
It could be a nightmare for the incubator if we donate an "Umbrella Project."
Can we consider donating sub-projects such as kogito one by one?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Dec 2, 2022 at 9:21 AM Niall Pemberton
<ni...@gmail.com> wrote:
>
> Wow, 137 GitHub repositories!
>
> OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
> have a rough idea of how many of those would be part of the incubation?
>
> Historically, Apache has been against "Umbrella Projects" - encouraging
> them to break up and become individual Top Level Projects (TLP) in their
> own right - the biggest example of that was Jakarta which used to be
> anything java related - but there have been others where sub-projects which
> have a life of their own have moved out to become TLPs.
>
> To me this looks like it should be 4 or 5 projects - its not clear whether
> kie is a product in its own right (with releasable artifcats) or just the
> umbrella that the others are grouped under?
> * drools
> * jbpm
> * kogito
> * optaplanner
> * kie ???
>
> Niall
>
>
> On Thu, 1 Dec 2022 at 21:36, Jason Porter <jp...@ibm.com.invalid> wrote:
>
> > Abstract
> >
> > KIE (Knowledge is Everything) is a community of solutions and supporting
> > tooling for knowledge engineering and process automation, focusing on
> > events, rules, and workflows.
> >
> > Proposal<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> > >
> >
> > KIE is a community dedicated to supporting knowledge engineering and
> > process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> > CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> > comprised of leading open-source projects (like Drools and jBPM), which
> > provide modeling and code authoring tools in this space. The work has a
> > strong emphasis on being a first-class citizen for Kubernetes but will
> > continue to support embedded and other environments such as edge computing.
> > Drools and jBPM are well-known projects in their areas of rules and
> > workflow and they will be joined by another project, building on a shared
> > core with jBPM, for CNCF’s Serverless Workflow - this project is going
> > through a naming process at the time of this application. Kogito is the
> > foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> > build on. Services and frameworks are provided to enable those projects in
> > a cloud-native environment and tooling is made available through KIE Tools.
> >
> > Background<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> > >
> >
> > Experience has shown that a holistic approach is a practical requirement
> > for any knowledge engineering and process automation. This requires a
> > breadth of capabilities able to model and execute an application’s data
> > models, rules, workflows, and events. These projects aim to provide a
> > holistic approach with a strong emphasis on congruency across them.
> >
> > Rationale<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> > >
> >
> > Knowledge engineering and process automation have been and continue to
> > play a large part in today’s software lifecycle. To date, there have been
> > few truly open-source implementations of any of the specifications (DMN,
> > PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> > these standards and fill that gap of having an open-source implementation.
> >
> >
> > The projects within KIE also mesh well with other Apache projects such as
> > Apache Camel and Apache Airavata. Integrations could be done at the IoT
> > level with Apache PLC4X and others.
> >
> >
> > Developers need a solution that follows, implements, and collaborates with
> > these industry specifications. The Apache Software Foundation would allow
> > these projects to continue to grow in a vendor-neutral environment and
> > promote further collaboration with existing integrations and future
> > partners.
> >
> > Initial Goals<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
> > >
> >
> > First and foremost, we aim to enlarge the community. KIE has primarily
> > been an open-source community of Red Hat Developers and users outside of
> > Red Hat. Adding IBM to the list of developers helps, but we would like to
> > see more. We have ideas for the various sub-projects, such as
> > straight-through processing support in Kogito, better spec compliance for
> > the tooling, and more research into language bindings for non-Java
> > languages. We believe we can address some of these while an Apache
> > Incubator project.
> >
> > Current Status<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
> > >
> >
> > Code for the various projects with the KIE community is all hosted on
> > GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code
> > is Apache 2 licensed. Red Hat has been the project’s custodian since its
> > inception and has maintained leadership in that area. Moving forward into
> > the Apache Incubator, we would need to establish the habit of holding votes
> > and meetings and the project updates per the Apache Way.
> >
> >
> > We also currently maintain a YouTube channel dedicated to the community
> > and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
> >
> > Meritocracy:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy
> > >
> >
> > Red Hat runs all of its open-source projects as meritocracies, the KIE
> > Community is no different. This aspect would not change any. Kogito
> > currently does not make a distinction between “committer” and “PMC member”
> > the same way Apache does. That aspect would need implementation.
> >
> > Community:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community
> > >
> >
> > The KIE Community has an active base of contributors within and outside
> > Red Hat. Community members currently use Zulip chat or mailing lists hosted
> > by Google Groups as communication tools. It has been that way for many
> > years. Before that, we were using IRC at Freenode for many years. There are
> > also mailing lists hosted on Google Groups that are leveraged for those who
> > prefer mailing list communication. Zulip was started as a standard
> > communication medium for KIE Community back in 2020. IRC has been used
> > since 2003.
> >
> > Core Developers:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers
> > >
> >
> > Core developers would come from both Red Hat and IBM. They include people
> > who have been working on related projects and the creation of the KIE
> > Community since the beginning, and also people new to the project.
> >
> > Alignment:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment
> > >
> >
> > Projects within the KIE Community align with multiple efforts within
> > Apache, namely:
> >
> > * Apache OpenWhisk
> >
> > * Apache Airavata
> >
> > * Apache Camel
> >
> >
> > We are currently actively involved in collaboration with Apache Camel,
> > while the other two are more alignments and usages within the communities.
> > There may be other Apache projects which could benefit from integration
> > with KIE Community projects.
> >
> >
> > jBPM, the proposed Serverless Workflow project and the Kogito workflow
> > foundation are targeting serverless and microservice deployments. It helps
> > to create automation and integration with other technologies in a
> > simple-to-use and understandable way. The Apache Software Foundation is a
> > great place to collaborate with multiple companies and technologies. We’re
> > looking to build a community that is inclusive, helpful, and a good citizen
> > to the larger Open Source community.
> >
> >
> > Other projects within the KIE Community umbrella target a more standard
> > enterprise software approach and deployment model.
> >
> > Known Risks<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks
> > >
> >
> > The Kogito workflow foundation targets the Quarkus environment, an
> > open-source project that Red Hat maintains. Should Red Hat no longer wish
> > to maintain Quarkus or move it in a direction that harms Kogito, a pivot
> > may be necessary. The Kogito workflow foundation will still run on other
> > runtimes, so it is less of a risk as well.
> >
> > There should not be any risks for other projects.
> >
> > Project Name<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name
> > >
> >
> > All names and trademarks have been vetted by Red Hat’s legal team to be
> > usable in the space. Transferring these over to Apache will not be a
> > problem.
> >
> > Orphaned products<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products
> > >
> >
> > Primary contributions to the KIE Community of projects will be made by
> > engineers employed by Red Hat and IBM. IBM is a leading vendor in the
> > Business Automation space. Red Hat up until the second half of 2022 was
> > also a major vendor in the same space. While Red Hat is no longer pursuing
> > the Business Automation market it does still need to augment the
> > capabilities of its other products with workflow, rules, and event
> > technologies in a way that aligns with Red Hat’s target audiences and Red
> > Hat’s strategic direction. Red Hat will continue to pursue the development
> > around CNCF serverless workflow, which will be built upon Kogito and
> > Drools. There is no risk of these projects being orphaned by either company.
> >
> > Inexperience with Open Source:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source
> > >
> >
> > All initial committers are well-versed in Open Source development.
> >
> > Length of Incubation:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation
> > >
> >
> > Incubation should take somewhere between six to twelve months.
> >
> > Homogenous Developers:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers
> > >
> >
> > The list of initial project committers includes developers from IBM and
> > Red Hat, all from different locations around the world.
> >
> > Reliance on Salaried Developers:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers
> > >
> >
> > Currently, the list of developers is from IBM and Red Hat. We’re hoping by
> > moving to Apache we can grow this list of developers outside of those two
> > companies. All the projects within KIE have been around for a long time and
> > have a large user base. Developers have come and gone over the years, but
> > the initial list of developers is coming from Red Hat and IBM.
> >
> > Relationships with Other Apache Products:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products
> > >
> >
> > The Apache Camel project has had integrations with KIE Community projects,
> > namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito
> > and Camel also have integrations with Quarkus. Kogito is built using Apache
> > Maven.
> >
> > An Excessive Fascination with the Apache Brand:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand
> > >
> >
> > We have looked at both the Apache Software Foundation and the Eclipse
> > Foundation and have decided that Apache would be a better place for the
> > code base. Red Hat, and IBM, have worked with both foundations and continue
> > to do so.
> >
> >
> > While the Apache brand is indeed well known and has great recognition,
> > we’re looking more toward the neutral nature of being at Apache and keeping
> > the project alive in an environment that is not solely controlled by a
> > single entity.
> >
> > Documentation<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation
> > >
> >
> > Kogito Documentation:
> > https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
> >
> > Drools Documentation: https://www.drools.org/learn/documentation.html
> >
> > jBPM Documentation:
> > https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
> >
> > Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
> >
> > DMN Specification: https://www.omg.org/spec/DMN
> >
> > BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
> >
> > Cloud Events Specification: https://github.com/cloudevents/spec
> >
> > Initial Source<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source
> > >
> >
> > All the code will be coming from the KIE Community GitHub repo at
> > https://github.com/kiegroup. There will be multiple repositories
> > including examples and code bases for Drools, jBPM, and Kogito.
> >
> > Source and Intellectual Property Submission Plan<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan
> > >
> >
> > * Source code within GitHub
> >
> > * Domains: kie.org, kogito.org, kogito.kie.org, blog.kie.org, jbpm.org,
> > drools.org, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org are all
> > currently owned by Red Hat
> >
> > External Dependencies:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies
> > >
> >
> > There are some LGPL, and Eclipse dependencies for some of the projects in
> > the test or provided scopes of the Maven poms. For example jdt dependencies
> > for the Eclipse plugins, logback, junit, and similar. Hibernate jars are
> > LGPL as well, those are in jBPM.
> >
> > Cryptography:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography
> > >
> >
> > There are some calls to the JVM vault, for process migration.
> >
> > Required Resources<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources
> > >
> > Mailing lists:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists
> > >
> >
> > * private@kie.incubator.apache.org
> >
> > * dev@kie.incubator.apache.org
> >
> > * commits@kie.incubator.apache.org
> >
> > Subversion Directory:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory
> > >
> >
> > None
> >
> > Git Repositories:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories
> > >
> >
> > Assuming we can continue to use GitHub, though it may need to migrate to
> > be beneath the Apache Organization.
> >
> > Issue Tracking:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking
> > >
> >
> > If possible, we would like to use GitHub issues.
> >
> > Other Resources:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources
> > >
> >
> > None.
> >
> > Initial Committers<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers
> > >
> >
> >
> > List of GitHub names:
> >
> >
> > Name
> >
> > GitHub Username
> >
> > Apache CLA
> >
> > Apache Email
> >
> > Mario Fusco
> >
> > mariofusco
> >
> > FALSE
> >
> >
> > Toshiya Kobayashi
> >
> > tkobayas
> >
> > TRUE
> >
> >
> > Matteo Mortari
> >
> > tarilabs
> >
> > TRUE
> >
> >
> > Tristan Radisson
> >
> > radtriste
> >
> > FALSE
> >
> >
> > Gabriele Cardosi
> >
> > gitgabrio
> >
> > FALSE
> >
> >
> > Edoardo Vacchi
> >
> > evacchi
> >
> > FALSE
> >
> >
> > Paolo Bizzarri
> >
> > pibizza
> >
> > FALSE
> >
> >
> > Cristiano Nicolai
> >
> > cristianonicolai
> >
> > FALSE
> >
> >
> > Michael Biarnés Kiefer
> >
> > mbiarnes
> >
> > FALSE
> >
> >
> > Enrique González Martínez
> >
> > elguardian
> >
> > FALSE
> >
> >
> > Vani Haripriya Mudadla
> >
> > vaniharipriya
> >
> > FALSE
> >
> >
> > Jason Porter
> >
> > lightguard
> >
> > TRUE
> >
> > lightguardjp@apache.org
> >
> > Gonzalo Muñoz
> >
> > gmunozfe
> >
> > FALSE
> >
> >
> > Francisco Javier Tirado Sarti
> >
> > fjtirado
> >
> > FALSE
> >
> >
> > Helber Belmiro
> >
> > hbelmiro
> >
> > TRUE
> >
> >
> > Antonio Fernandez Alhambra
> >
> > afalhambra
> >
> > FALSE
> >
> >
> > Abhijit Humbe
> >
> > abhijithumbe
> >
> > FALSE
> >
> >
> > Martin Weiler
> >
> > martinweiler
> >
> > FALSE
> >
> >
> > Enrique Mingorance Cano
> >
> > ginxo
> >
> > FALSE
> >
> >
> > Tiago Dolphine
> >
> > tiagodolphine
> >
> > FALSE
> >
> >
> > Alex Porcelli
> >
> > porcelli
> >
> > FALSE
> >
> >
> > Kris Verlaenen
> >
> > krisv
> >
> > TRUE
> >
> > (requested krisv@apache.org)
> >
> > Pere Fernández
> >
> > pefernan
> >
> > FALSE
> >
> >
> > Jan Stastny
> >
> > jstastny-cz
> >
> > FALSE
> >
> >
> > Jozef Marko
> >
> > jomarko
> >
> > FALSE
> >
> >
> > Walter Medvedeo
> >
> > wmedvede
> >
> > FALSE
> >
> >
> > Kennedy Bowers
> >
> > kbowers-redhat
> >
> > FALSE
> >
> >
> > Roberto Oliveira
> >
> > rgdoliveira
> >
> > FALSE
> >
> >
> > Andrea Lamparelli
> >
> > lampajr
> >
> > FALSE
> >
> >
> > Bai Xiaofeng
> >
> > bxf12315
> >
> > FALSE
> >
> >
> > Ruben Romero Montes
> >
> > ruromero
> >
> > FALSE
> >
> >
> > Filippe Spolti
> >
> > spolti
> >
> > FALSE
> >
> >
> > Massimiliano Dessì
> >
> > desmax74
> >
> > TRUE
> >
> >
> > Tiago Bento
> >
> > tiagobento
> >
> > FALSE
> >
> >
> > Yeser Amer
> >
> > yesamer
> >
> > FALSE
> >
> >
> > Guilherme Caponetto
> >
> > caponetto
> >
> > FALSE
> >
> >
> > Paulo Martins
> >
> > paulovmr
> >
> > FALSE
> >
> >
> > Thiago Lugli
> >
> > thiagoelg
> >
> > FALSE
> >
> >
> > William Antônio Siqueira
> >
> > jesuino
> >
> > FALSE
> >
> >
> > Fabrizio Antonangeli
> >
> > fantonangeli
> >
> > FALSE
> >
> >
> > Valentino Pellegrino
> >
> > vpellegrino
> >
> > FALSE
> >
> >
> > Ricardo Zanini
> >
> > ricardozanini
> >
> > FALSE
> >
> >
> > Tibor Zimányi
> >
> > baldimir
> >
> > FALSE
> >
> >
> > Eder Ignatowicz
> >
> > ederign
> >
> > FALSE
> >
> >
> > Mark Proctor
> >
> > mdproctor
> >
> > FALSE
> >
> >
> > Thiago Lugli
> >
> > thiagoelg
> >
> > FALSE
> >
> >
> > Luiz João Motta
> >
> > ljmotta
> >
> > FALSE
> >
> >
> > Jaime Enriquez
> >
> > inodeman
> >
> > FALSE
> >
> >
> > Luca Molteni
> >
> > lucamolteni
> >
> > FALSE
> >
> >
> > Davide Salerno
> >
> > davidesalerno
> >
> > TRUE
> >
> >
> > Edson Tirelli
> >
> > etirelli
> >
> > FALSE
> >
> > Sponsors<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors
> > >
> >
> > IBM and Red Hat are the sponsors for the project.
> >
> > Champion:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion
> > >
> >
> > Brian Proffitt
> >
> > Nominated Mentors:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors
> > >
> >
> > Brian Proffitt
> >
> > Claus Ibsen
> >
> > Andrea Cosentino
> >
> > Sponsoring Entity:<
> > https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity
> > >
> >
> > Apache Camel
> >
> >
> > Jason Porter
> > Software Engineer
> > He/Him/His
> >
> > IBM
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] KIE Proposal
Posted by Niall Pemberton <ni...@gmail.com>.
Wow, 137 GitHub repositories!
OK, so 38 are archived and 19 are forks, but that still leaves 80! Do you
have a rough idea of how many of those would be part of the incubation?
Historically, Apache has been against "Umbrella Projects" - encouraging
them to break up and become individual Top Level Projects (TLP) in their
own right - the biggest example of that was Jakarta which used to be
anything java related - but there have been others where sub-projects which
have a life of their own have moved out to become TLPs.
To me this looks like it should be 4 or 5 projects - its not clear whether
kie is a product in its own right (with releasable artifcats) or just the
umbrella that the others are grouped under?
* drools
* jbpm
* kogito
* optaplanner
* kie ???
Niall
On Thu, 1 Dec 2022 at 21:36, Jason Porter <jp...@ibm.com.invalid> wrote:
> Abstract
>
> KIE (Knowledge is Everything) is a community of solutions and supporting
> tooling for knowledge engineering and process automation, focusing on
> events, rules, and workflows.
>
> Proposal<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#proposal
> >
>
> KIE is a community dedicated to supporting knowledge engineering and
> process automation, using standards from groups like OMG (BPMN, CMMN, DMN),
> CNCF (Serverless Workflow, Cloud Events), and DMG (PMML, PFA). KIE is
> comprised of leading open-source projects (like Drools and jBPM), which
> provide modeling and code authoring tools in this space. The work has a
> strong emphasis on being a first-class citizen for Kubernetes but will
> continue to support embedded and other environments such as edge computing.
> Drools and jBPM are well-known projects in their areas of rules and
> workflow and they will be joined by another project, building on a shared
> core with jBPM, for CNCF’s Serverless Workflow - this project is going
> through a naming process at the time of this application. Kogito is the
> foundation project for workflow which jBPM and CNCF’s Serverless Workflow
> build on. Services and frameworks are provided to enable those projects in
> a cloud-native environment and tooling is made available through KIE Tools.
>
> Background<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#background
> >
>
> Experience has shown that a holistic approach is a practical requirement
> for any knowledge engineering and process automation. This requires a
> breadth of capabilities able to model and execute an application’s data
> models, rules, workflows, and events. These projects aim to provide a
> holistic approach with a strong emphasis on congruency across them.
>
> Rationale<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#rationale
> >
>
> Knowledge engineering and process automation have been and continue to
> play a large part in today’s software lifecycle. To date, there have been
> few truly open-source implementations of any of the specifications (DMN,
> PMML, BPMN, CNCF Workflow, etc). The projects within Red Hat implement
> these standards and fill that gap of having an open-source implementation.
>
>
> The projects within KIE also mesh well with other Apache projects such as
> Apache Camel and Apache Airavata. Integrations could be done at the IoT
> level with Apache PLC4X and others.
>
>
> Developers need a solution that follows, implements, and collaborates with
> these industry specifications. The Apache Software Foundation would allow
> these projects to continue to grow in a vendor-neutral environment and
> promote further collaboration with existing integrations and future
> partners.
>
> Initial Goals<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-goals
> >
>
> First and foremost, we aim to enlarge the community. KIE has primarily
> been an open-source community of Red Hat Developers and users outside of
> Red Hat. Adding IBM to the list of developers helps, but we would like to
> see more. We have ideas for the various sub-projects, such as
> straight-through processing support in Kogito, better spec compliance for
> the tooling, and more research into language bindings for non-Java
> languages. We believe we can address some of these while an Apache
> Incubator project.
>
> Current Status<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#current-status
> >
>
> Code for the various projects with the KIE community is all hosted on
> GitHub. This includes Kogito, Drools, jBPM, and KIE Tools. All of the code
> is Apache 2 licensed. Red Hat has been the project’s custodian since its
> inception and has maintained leadership in that area. Moving forward into
> the Apache Incubator, we would need to establish the habit of holding votes
> and meetings and the project updates per the Apache Way.
>
>
> We also currently maintain a YouTube channel dedicated to the community
> and projects, a Twitter presence, and a LinkedIn page for the KIE Community.
>
> Meritocracy:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#meritocracy
> >
>
> Red Hat runs all of its open-source projects as meritocracies, the KIE
> Community is no different. This aspect would not change any. Kogito
> currently does not make a distinction between “committer” and “PMC member”
> the same way Apache does. That aspect would need implementation.
>
> Community:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#community
> >
>
> The KIE Community has an active base of contributors within and outside
> Red Hat. Community members currently use Zulip chat or mailing lists hosted
> by Google Groups as communication tools. It has been that way for many
> years. Before that, we were using IRC at Freenode for many years. There are
> also mailing lists hosted on Google Groups that are leveraged for those who
> prefer mailing list communication. Zulip was started as a standard
> communication medium for KIE Community back in 2020. IRC has been used
> since 2003.
>
> Core Developers:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#core-developers
> >
>
> Core developers would come from both Red Hat and IBM. They include people
> who have been working on related projects and the creation of the KIE
> Community since the beginning, and also people new to the project.
>
> Alignment:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#alignment
> >
>
> Projects within the KIE Community align with multiple efforts within
> Apache, namely:
>
> * Apache OpenWhisk
>
> * Apache Airavata
>
> * Apache Camel
>
>
> We are currently actively involved in collaboration with Apache Camel,
> while the other two are more alignments and usages within the communities.
> There may be other Apache projects which could benefit from integration
> with KIE Community projects.
>
>
> jBPM, the proposed Serverless Workflow project and the Kogito workflow
> foundation are targeting serverless and microservice deployments. It helps
> to create automation and integration with other technologies in a
> simple-to-use and understandable way. The Apache Software Foundation is a
> great place to collaborate with multiple companies and technologies. We’re
> looking to build a community that is inclusive, helpful, and a good citizen
> to the larger Open Source community.
>
>
> Other projects within the KIE Community umbrella target a more standard
> enterprise software approach and deployment model.
>
> Known Risks<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#known-risks
> >
>
> The Kogito workflow foundation targets the Quarkus environment, an
> open-source project that Red Hat maintains. Should Red Hat no longer wish
> to maintain Quarkus or move it in a direction that harms Kogito, a pivot
> may be necessary. The Kogito workflow foundation will still run on other
> runtimes, so it is less of a risk as well.
>
> There should not be any risks for other projects.
>
> Project Name<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#project-name
> >
>
> All names and trademarks have been vetted by Red Hat’s legal team to be
> usable in the space. Transferring these over to Apache will not be a
> problem.
>
> Orphaned products<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#orphaned-products
> >
>
> Primary contributions to the KIE Community of projects will be made by
> engineers employed by Red Hat and IBM. IBM is a leading vendor in the
> Business Automation space. Red Hat up until the second half of 2022 was
> also a major vendor in the same space. While Red Hat is no longer pursuing
> the Business Automation market it does still need to augment the
> capabilities of its other products with workflow, rules, and event
> technologies in a way that aligns with Red Hat’s target audiences and Red
> Hat’s strategic direction. Red Hat will continue to pursue the development
> around CNCF serverless workflow, which will be built upon Kogito and
> Drools. There is no risk of these projects being orphaned by either company.
>
> Inexperience with Open Source:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#inexperience-with-open-source
> >
>
> All initial committers are well-versed in Open Source development.
>
> Length of Incubation:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#length-of-incubation
> >
>
> Incubation should take somewhere between six to twelve months.
>
> Homogenous Developers:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#homogenous-developers
> >
>
> The list of initial project committers includes developers from IBM and
> Red Hat, all from different locations around the world.
>
> Reliance on Salaried Developers:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#reliance-on-salaried-developers
> >
>
> Currently, the list of developers is from IBM and Red Hat. We’re hoping by
> moving to Apache we can grow this list of developers outside of those two
> companies. All the projects within KIE have been around for a long time and
> have a large user base. Developers have come and gone over the years, but
> the initial list of developers is coming from Red Hat and IBM.
>
> Relationships with Other Apache Products:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#relationships-with-other-apache-products
> >
>
> The Apache Camel project has had integrations with KIE Community projects,
> namely jBPM and Drools. Camel K also has integrations with Kogito. Kogito
> and Camel also have integrations with Quarkus. Kogito is built using Apache
> Maven.
>
> An Excessive Fascination with the Apache Brand:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#a-excessive-fascination-with-the-apache-brand
> >
>
> We have looked at both the Apache Software Foundation and the Eclipse
> Foundation and have decided that Apache would be a better place for the
> code base. Red Hat, and IBM, have worked with both foundations and continue
> to do so.
>
>
> While the Apache brand is indeed well known and has great recognition,
> we’re looking more toward the neutral nature of being at Apache and keeping
> the project alive in an environment that is not solely controlled by a
> single entity.
>
> Documentation<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#documentation
> >
>
> Kogito Documentation:
> https://docs.kogito.kie.org/latest/html_single/#con-kogito-automation_kogito-docs
>
> Drools Documentation: https://www.drools.org/learn/documentation.html
>
> jBPM Documentation:
> https://docs.jbpm.org/7.73.0.Final/jbpm-docs/html_single/
>
> Drools DMN Engine landing page: https://www.drools.org/learn/dmn.html
>
> DMN Specification: https://www.omg.org/spec/DMN
>
> BPMN Specification: https://www.omg.org/spec/BPMN/2.0/
>
> Cloud Events Specification: https://github.com/cloudevents/spec
>
> Initial Source<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-source
> >
>
> All the code will be coming from the KIE Community GitHub repo at
> https://github.com/kiegroup. There will be multiple repositories
> including examples and code bases for Drools, jBPM, and Kogito.
>
> Source and Intellectual Property Submission Plan<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#source-and-intellectual-property-submission-plan
> >
>
> * Source code within GitHub
>
> * Domains: kie.org, kogito.org, kogito.kie.org, blog.kie.org, jbpm.org,
> drools.org, bpmn.new, dmn.new, pmml.new, and sandbox.kie.org are all
> currently owned by Red Hat
>
> External Dependencies:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#external-dependencies
> >
>
> There are some LGPL, and Eclipse dependencies for some of the projects in
> the test or provided scopes of the Maven poms. For example jdt dependencies
> for the Eclipse plugins, logback, junit, and similar. Hibernate jars are
> LGPL as well, those are in jBPM.
>
> Cryptography:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#cryptography
> >
>
> There are some calls to the JVM vault, for process migration.
>
> Required Resources<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#required-resources
> >
> Mailing lists:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#mailing-lists
> >
>
> * private@kie.incubator.apache.org
>
> * dev@kie.incubator.apache.org
>
> * commits@kie.incubator.apache.org
>
> Subversion Directory:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#subversion-directory
> >
>
> None
>
> Git Repositories:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#git-repositories
> >
>
> Assuming we can continue to use GitHub, though it may need to migrate to
> be beneath the Apache Organization.
>
> Issue Tracking:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#issue-tracking
> >
>
> If possible, we would like to use GitHub issues.
>
> Other Resources:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#other-resources
> >
>
> None.
>
> Initial Committers<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#initial-committers
> >
>
>
> List of GitHub names:
>
>
> Name
>
> GitHub Username
>
> Apache CLA
>
> Apache Email
>
> Mario Fusco
>
> mariofusco
>
> FALSE
>
>
> Toshiya Kobayashi
>
> tkobayas
>
> TRUE
>
>
> Matteo Mortari
>
> tarilabs
>
> TRUE
>
>
> Tristan Radisson
>
> radtriste
>
> FALSE
>
>
> Gabriele Cardosi
>
> gitgabrio
>
> FALSE
>
>
> Edoardo Vacchi
>
> evacchi
>
> FALSE
>
>
> Paolo Bizzarri
>
> pibizza
>
> FALSE
>
>
> Cristiano Nicolai
>
> cristianonicolai
>
> FALSE
>
>
> Michael Biarnés Kiefer
>
> mbiarnes
>
> FALSE
>
>
> Enrique González Martínez
>
> elguardian
>
> FALSE
>
>
> Vani Haripriya Mudadla
>
> vaniharipriya
>
> FALSE
>
>
> Jason Porter
>
> lightguard
>
> TRUE
>
> lightguardjp@apache.org
>
> Gonzalo Muñoz
>
> gmunozfe
>
> FALSE
>
>
> Francisco Javier Tirado Sarti
>
> fjtirado
>
> FALSE
>
>
> Helber Belmiro
>
> hbelmiro
>
> TRUE
>
>
> Antonio Fernandez Alhambra
>
> afalhambra
>
> FALSE
>
>
> Abhijit Humbe
>
> abhijithumbe
>
> FALSE
>
>
> Martin Weiler
>
> martinweiler
>
> FALSE
>
>
> Enrique Mingorance Cano
>
> ginxo
>
> FALSE
>
>
> Tiago Dolphine
>
> tiagodolphine
>
> FALSE
>
>
> Alex Porcelli
>
> porcelli
>
> FALSE
>
>
> Kris Verlaenen
>
> krisv
>
> TRUE
>
> (requested krisv@apache.org)
>
> Pere Fernández
>
> pefernan
>
> FALSE
>
>
> Jan Stastny
>
> jstastny-cz
>
> FALSE
>
>
> Jozef Marko
>
> jomarko
>
> FALSE
>
>
> Walter Medvedeo
>
> wmedvede
>
> FALSE
>
>
> Kennedy Bowers
>
> kbowers-redhat
>
> FALSE
>
>
> Roberto Oliveira
>
> rgdoliveira
>
> FALSE
>
>
> Andrea Lamparelli
>
> lampajr
>
> FALSE
>
>
> Bai Xiaofeng
>
> bxf12315
>
> FALSE
>
>
> Ruben Romero Montes
>
> ruromero
>
> FALSE
>
>
> Filippe Spolti
>
> spolti
>
> FALSE
>
>
> Massimiliano Dessì
>
> desmax74
>
> TRUE
>
>
> Tiago Bento
>
> tiagobento
>
> FALSE
>
>
> Yeser Amer
>
> yesamer
>
> FALSE
>
>
> Guilherme Caponetto
>
> caponetto
>
> FALSE
>
>
> Paulo Martins
>
> paulovmr
>
> FALSE
>
>
> Thiago Lugli
>
> thiagoelg
>
> FALSE
>
>
> William Antônio Siqueira
>
> jesuino
>
> FALSE
>
>
> Fabrizio Antonangeli
>
> fantonangeli
>
> FALSE
>
>
> Valentino Pellegrino
>
> vpellegrino
>
> FALSE
>
>
> Ricardo Zanini
>
> ricardozanini
>
> FALSE
>
>
> Tibor Zimányi
>
> baldimir
>
> FALSE
>
>
> Eder Ignatowicz
>
> ederign
>
> FALSE
>
>
> Mark Proctor
>
> mdproctor
>
> FALSE
>
>
> Thiago Lugli
>
> thiagoelg
>
> FALSE
>
>
> Luiz João Motta
>
> ljmotta
>
> FALSE
>
>
> Jaime Enriquez
>
> inodeman
>
> FALSE
>
>
> Luca Molteni
>
> lucamolteni
>
> FALSE
>
>
> Davide Salerno
>
> davidesalerno
>
> TRUE
>
>
> Edson Tirelli
>
> etirelli
>
> FALSE
>
> Sponsors<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsors
> >
>
> IBM and Red Hat are the sponsors for the project.
>
> Champion:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#champion
> >
>
> Brian Proffitt
>
> Nominated Mentors:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#nominated-mentors
> >
>
> Brian Proffitt
>
> Claus Ibsen
>
> Andrea Cosentino
>
> Sponsoring Entity:<
> https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal#sponsoring-entity
> >
>
> Apache Camel
>
>
> Jason Porter
> Software Engineer
> He/Him/His
>
> IBM
>
>
>