RulesEngine Maintenance Alignment — Avoiding Fragmentation

[RenanCarlosPereira]

Hi everyone,

I would like to propose an alignment around the maintenance and future of RulesEngine.

---

Summary of recent events:

• In #604, @abbasc52 announced that he could no longer maintain the project after leaving Microsoft, and had received no clear response from Microsoft regarding a handover.
• As a result, community members like @timophe-91, @asulwer, and others created forks and started maintaining the project independently.
• @asulwer has been actively fixing issues and planning improvements, although with possible breaking changes ahead.
• Some users, including myself, are heavily relying on RulesEngine for critical business applications and have a strong preference for stability and backward compatibility (discussed in #604 as well).
• Meanwhile, there has been some small activity on the original repository, as seen in #609.
• Recently, @evan361425 suggested in #667 that we contribute back to the original Microsoft repository instead of maintaining forks separately.

---

Why am I creating this post?
We all have the same goal: keep RulesEngine alive, stable, and evolving.
However, right now we risk fragmentation between forks and the original repo.

This could confuse new users and harm adoption of the library.

Personally, I would be happy to contribute no matter the repository, but it’s crucial that we have alignment on:

• Which repository should be considered the "official" RulesEngine?
• What should be the maintenance and contribution model (governance)?
• How do we balance stability (backward compatibility) vs innovation (new features)?
• If moving to a fork: should we migrate issue tracking and community there?
• If reviving the original repo: can we get Microsoft's blessing/permission to proceed?

---

Suggestion:

• Start a formal discussion involving all active contributors (e.g., @pbhal, @abbasc52, @timophe-91, @asulwer, @evan361425, myself, and anyone else).
• Define together the future home for RulesEngine.
• Organize clear roles (who can approve PRs, manage releases, etc.).

---

Additional contribution:
While working with RulesEngine, I also started building a sample project to demonstrate how a RulesEngine-based application could work in practice:

• [Playground Demo (WIP)](http://rules-engine-pro.com/)
• [API Repository](https://github.com/RenanCarlosPereira/rules-engine-pro-api)
• [UI Repository](https://github.com/RenanCarlosPereira/rules-engine-pro-ui)

The goal is to provide a playground where users can easily test rule creation and execution, and also get inspiration on how to build UIs and services around RulesEngine.

If this project can be helpful to the official RulesEngine ecosystem, I’d be happy to collaborate and evolve it alongside the main project.

---

Thanks again to everyone who's been contributing so far!
Let's work together to keep this amazing project thriving for the long term. 🚀

Looking forward to hearing your thoughts!

[timophe-91]

Hey,

sounds good to me.

For me it is just important that i can trust the future home. Other than that i don't mind which will be the future home.

If we do major breaking changes, then do it properly with multiple of them in one version and not every other version has a breaking change. Also they must be well documented on how to get from one Version to the new. Nothing is more annoying to get to the new version with a ton of work and no where with proper instructions.

[asulwer]

@timophe-91 at the beginning i proposed possible future 'breaking changes'. nothing that has been introduced has created any 'breaking changes' that effect backwards compatibility. fixing issues as they appear has been the sole goal.

[abbasc52]

Couple of things I would like to add from my side-

1. We should ideally converge to a fork which is more active and well maintained. The reason things got fragmented was because there was a good time frame for which the original repo was not maintained
2. As @timophe-91 mentioned trust is an important factor. Till the time I maintained the repo, I was keen on not introducing breaking changes and provide high quality. In case, there was no way other than introducing breaking changes, they were always major version changes, with a detailed changelog to explain the required changes.
3. We don't just need an active repo, we would need a vision. I do believe maintaining an open source library is a significant overhead, let alone enhancing it. Keep it open to contribution helps, but if everyone adds their own thought process and features, it will get complicated and hard to use. We would need to accept/reject a contribution if it aligns with the vision we have for RulesEngine

From the context I have, @asulwer fork has might have most changes and we have had discussions in past which resulted in him ensuring everything is backward compatible.

I believe @pbhal and @YogeshPraj from Microsoft have recently started maintaining this repo (and the most used nuget variant) again but they can share how much commitment they have in terms of new features/bugs fixes etc.

If it is a matter of ensuring updates to RulesEngine are trustworthy, I can share the practices that I used to follow to ensure things don't break.

That being said excited to see so many people interested in taking it forward!

[RenanCarlosPereira]

everyone, that issue was created over a month ago could we have feedback on where the home will be? If it's here, we will need to create some pull requests with the fixes we implemented in the fork. I want that project to have a fast response on the issues if we are maintaining it here. thanks

Maintainers, please let us know.

[asulwer]

i haven't heard anything from the 'supposed' current maintainers on anything. so as far as i am concerned i will continue to move forward with my fork. i am willing to open up my fork to anyone that wants to help maintain it.

[pbhal]

@RenanCarlosPereira - We are broadly in alignment with the suggestions provided above. For a good amount of time, the repo had no active maintenance which caused natural diversions. To bring back the traction on the project, we can fixate on mutual understanding of taking this project forward.

-> We can assign optional reviewers to the Pull Requests for the project, but there has to remain an approver from our organization as it is published as one of the MSFT projects. We would also suggest keeping this version as the go-to library for RulesEngine.

-> We will try to manage the capacity from our end in case of complex/big feature releases, but right now due to capacity constraints I would be contributing to primarily managing and maintaining the repo from MSFT. We can align on biweekly minor releases/issue fixes, and major monthly releases.

Apologies for missing the contribution to project for quite some time but looking forward to bringing it back on track. Thanks!

[asulwer]

@pbhal there has not been any movement on this repo so we all assumed it was dead, plus original author stated it was. since you have taken over not much has changed.

[pbhal]

@asulwer - There was a period of time where the repo had no active owner. The backlog has grown over time from security issues, CG bugs, reported bugs and issues along with feature requests. Currently I am the alone contributor to the project. We have prioritized NuGet version upgrades and security CG bugs which are P0 from Microsoft's standpoint as well, along with minor dependent enhancements.

With all things, feedback taken, we will improve on the agility front to cover the backlog. Additionally, as an open-source project, we can look forward to the community contributing taking above mentioned discussion into consideration who can contribute actively to this.