Camel K roadmap 2025

[squakez]

This is a placeholder we can use to discuss the roadmap for the project development during 2025.

Status of 2024 roadmap

Despite the difficulties we faced during 2024, we managed to accomplish most (if not all) the desired areas of development we had planned (see #5019). We have enhanced the build experience, giving a particular focus on the "Self managed" Integrations. We have reorganized the code of Kamelets, enabling the possibility to use versioning. We have deprecated several incomplete features that are not commonly used and increased the quality of code from around 30% to almost 50% coverage.

Areas of development for 2025

Here a list of areas where I think we should dedicate during this year:

• Make plain Quarkus runtime the default runtime
• Separate more builds and operations
• More Camel core and more Kubernetes core
• Drop unused features

I'll try to add some context in words in order to ease the meaning of each point.

Make plain Quarkus runtime the default runtime

From upcoming version 2.6.0 onward, you will be able to use plain Camel Quarkus application. This is a great simplification in terms of project management on our side and also for your application which are free to choose any Camel Quarkus as soon as they are released. This is also a great simplification in order to quickly and immediately move from a prototype built via Camel JBang to a running application on Kubernetes.

Separate more builds and operations

We have started this part already in 2024. We need to continue pushing on this area in order to have a cleaner separation of concerns between the builds and the rest of operations for any Camel application.

More Camel core and more Kubernetes core

Camel K should be thought as a Kubernetes manager for Camel applications. For this reason we should support Camel runtimes the way they are (hence, deprecating and removing Camel K Runtime) and simplify the configuration on Kubernetes. We should work more towards an automatic discovery of features by the operator in order to free the user from having to provide such a configuration manually. In that sense, we need to work on identifying those traits which can be further enhanced and any new feature commonly used in Kubernetes in conjunction with Camel applications.

We need also to continue the work of simplification changing the scope or even removing custom resources that may be no longer relevant (for example, the CamelCatalog or the IntegrationPlatform).

Drop unused features

We have plenty of features that have been introduced during these years and are not complete or not very commonly used. This is draining a lot of development time we should instead spare for the main features of the project. Let's identify unused features and we can drop them.

[cfitzw]

All of these sound great and attainable.

Some additional improvement ideas for the future:

• Improve documentation
  • Instead of having similar/seperate code segments on different pages, link back to the core page/example instead
  • Add links to Camel related features when/where mentioned
  • Add more examples, especially with YAML syntax
• Provide blogs for some opinionated production-like flows.
  • With the continuous improvement of separating builds from operations, having some guides as to how to implement would be helpful -- utilizing tools like Kustomize, ArgoCD, GitHub Actions, etc (and some of them in conjunction).

[squakez]

@cfitzw thanks for the feedback. Yeah, documentation and tech marketing are always a great thing to do. I hope community can help with more contributions as these are those kind of things where the existing user can easily add some contribution without needing to write code.