Hi Rich, Thank you for reaching out and for the thoughtful introduction. I appreciate your interest in how the process works and your openness to questions.
Here is my perspective on why a project like KIE takes over two years (and likely a bit more) to graduate. First, this is not a new project. KIE has over 15 years of development history, originally under Red Hat. For most of its life, it operated under Red Hat's direction, with infrastructure, funding, and internal CI systems that are no longer in place. That legacy has shaped many of the challenges we face now. One clear example is project structure. The core of the project is split across five main repositories, which mirrors the number of engineering managers involved at Red Hat. This layout has some advantages, but also introduces a significant amount of complexity. At Red Hat, a dedicated team of around five to seven engineers was responsible for CI and builds. Today, this work is shared across contributors, which slows things down. Migrating from Red Hat's internal systems to Apache Jenkins and GitHub Actions was a huge effort. It took around eight to nine months to complete, but we are thankfully past that stage. Then there is the code itself. Much of it is naturally aligned with Red Hat ecosystems, such as Quarkus and Spring Boot. One major issue was Hibernate, which had an LGPL license that is not compatible with ASF requirements. This was a problem because Hibernate is the only supported ORM in Quarkus. The good news is that the Hibernate team recently relicensed everything under ASLv2, so that blocker is being resolved, though it will take a bit longer to stabilize in our stack. Another big challenge is the use of GWT (Google Web Toolkit). Additionally, the team developed a comprehensive framework called Errai [1] to integrate Java EE features into the browser. This included some GPL (with classpath exception) code, which must now be removed. We also have a BPMN editor that relies on Eclipse EMF to marshal XML to browser-friendly objects. As a result, we had parts of EMF copied and pasted into the codebase, which is another issue for graduation. We are making progress. A new graphical editor is already in place without GWT, and a new BPMN editor is in development to eliminate the EMF footprint. These are not quick wins. Building a full BPMN editor takes serious time. For reference, you can try our current graphical editors here [2]. Another factor is the number of vendors involved. While this is a sign of a healthy ecosystem, it also means most contributors are balancing this work with full-time jobs elsewhere. It becomes challenging to prioritize tasks such as documentation and site reorganization when the same individuals are also responsible for maintaining CI, replacing frontends, and addressing compliance issues. In short, moving a large and mature codebase into the ASF is a significant effort. Even without the ASF-specific requirements, this type of migration would be a considerable amount of work. The ASF process adds an extra layer of needed diligence. I hope this helps give a clearer picture. I'm happy to continue the discussion here or offline, if you prefer. [1] http://erraiframework.org/ [2] https://sandbox.kie.org/#/ - Alex On Fri, Jul 18, 2025 at 9:03 AM Rich Bowen <rbo...@rcbowen.com> wrote: > > Hi, folks. > > Just wanted to introduce myself and my hidden agenda. I’m Rich. I’m a board > member who is interested in how the Incubator works, and I figured the best > way to learn was to lurk on an incubating project. I’m particularly > interested in why a project takes 2+ years to go through this process, and > whether that’s something that we (we, collectively, the ASF) can help > shorten. I don’t think that this is a failing on your part, or really on > anyone’s part, but it does feel like something we can attempt to streamline, > but I’m utterly ignorant as to where the bottlenecks are. > > As such, I’m interested in the process, rather than (sorry, folks) your very > interesting software. A project is, after all, in the Incubator not to learn > how to make amazing software (you clearly already know that) but how to be an > ASF project. > > So, I’ll be here lurking and watching and asking awkward questions. Please > understand that it’s not about you. It's about the ASF and how we can make > things better for projects. Please understand that my questions are not > mandates from the board, or any suggestion that you’re doing things wrong. > I’m trying to learn, and the last time I actually got engaged with an > incubating project was Allura, which graduated in 2019, (After almost SEVEN > years!!!) so many of my preconceptions are almost certainly wrong. > > So … carry on. (If you have specific concerns, suggestions, or complaints, I > am happy to hear them off-list. I really don’t want to derail the work you > are doing here by instigating dissent.) > > — > Rich Bowen > rbo...@rcbowen.com > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
