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

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

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


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

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


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

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

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

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

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

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

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

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


All initial committers are well-versed in Open Source development.

Length of Incubation

Incubation should take somewhere between six to twelve months.


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

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

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

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


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

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

  *   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

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

There are some calls to the JVM vault, for process migration.


Required Resources


Mailing lists

  *   private@kie.incubator.apache.org
  *   dev@kie.incubator.apache.org
  *   commits@kie.incubator.apache.org

Subversion Directory

None


Git Repositories

Assuming we can continue to use GitHub, though it may need to migrate to be beneath the Apache Organization.

Issue Tracking

If possible, we would like to use GitHub issues.

Other Resources

None.

Initial Committers

List of GitHub names:


NameGitHub UsernameApache CLAApache Email
Mario Fuscomariofusco

false


Toshiya Kobayashitkobayastrue
Matteo Mortaritarilabstrue
Tristan Radisson
radtristefalse
Gabriele Cardosigitgabriofalse
Edoardo Vacchievacchifalse
Paolo Bizzarripibizzafalse
Cristiano Nicolaicristianonicolai
false
Michael Biarnés Kiefermbiarnes
false
Enrique González Martínezelguardian
false
Vani Haripriya Mudadlavaniharipriya
false
Jason Porterlightguardtruelightguardjp@apache.org
Gonzalo Muñoz
gmunozfefalse
Francisco Javier Tirado Sarti
fjtiradofalse
Helber Belmiro
hbelmirotrue
Antonio Fernandez Alhambra
afalhambrafalse
Abhijit Humbe
abhijithumbefalse
Martin Weiler
martinweilerfalse
Enrique Mingorance Cano
ginxofalse
Tiago Dolphine
tiagodolphinefalse
Alex Porcelli
porcellifalse
Kris Verlaenen
krisvtrue(requested krisv@apache.org)
Pere Fernández
pefernanfalse
Jan Stastny
jstastny-czfalse
Jozef Marko
jomarkofalse
Walter Medvedeo
wmedvedefalse
Kennedy Bowers
kbowers-redhatfalse
Roberto Oliveira
rgdoliveirafalse
Andrea Lamparelli
lampajrfalse
Bai Xiaofeng
bxf12315false
Ruben Romero Montes
ruromerofalse
Filippe Spolti
spoltifalse
Massimiliano Dessì
desmax74true
Tiago Bento
tiagobentofalse
Yeser Amer
yesamerfalse
Guilherme Caponetto
caponettofalse
Paulo Martins
paulovmrfalse
Thiago Lugli
thiagoelgfalse
William Antônio Siqueira
jesuinofalse
Fabrizio Antonangeli
fantonangelifalse
Valentino Pellegrino
vpellegrinofalse
Ricardo Zanini
ricardozaninifalse
Tibor Zimányi
baldimirfalse
Eder Ignatowicz
ederignfalse
Mark Proctor
mdproctorfalse
Thiago Lugli
thiagoelgfalse
Luiz João Motta
ljmottafalse
Jaime Enriquezinodemanfalse
Luca Moltenilucamoltenifalse
Davide Salernodavidesalernotrue
Edson Tirelli
etirellifalse


Sponsors

Champion

Brian Proffitt

Nominated Mentors

  • Brian Proffitt
  • Claus Ibsen
  • Andrea Cosentino

Sponsoring Entity

Apache Camel


  • No labels