I am going to migrate a customer to Operaton soon that relies on External Task Clients both in Java and Python.
For Operaton 1.0 I expect, the original clients will still work. But I assume on the long run, they may become incompatible.
The java client is part of Operaton, so I assume, that will be taken care of. But what would be the best strategy for community projects like the python-client? Will there be a Operaton-Hub? Or should I maybe fork the client in my company or private github?
We’re also very happy to see Operaton taking off — great work!
We have a similar question regarding community projects.
We’d love to keep using and contributing to some of the existing Camunda Community Hub projects (for example camunda-platform-scenario) together with Operaton.
Will there be a central place — like an “Operaton Hub” — where such community-driven extensions and forks can live?
It would be great to have a shared home for these projects to keep the ecosystem connected.
Thanks for joining the forum! Apologies, that the post was queued by the forum software, I approved it as soon as I saw it.
We are not planning on providing a community-hub, because the project itself is the community. If you’d like to contribute a project / an engine plugin, etc., you can suggest this either here in the forum or in a GitHub issue and we might just add it to our GitHub organization and provide you with the necessary access to contribute to it. We have not yet agreed on hard characteristics when to accept those requests and when such a contribution might be too specific for general interest and would be better suited as a project maintained independently, but I’m sure we will come to terms on these things and find a solution that works
what’s important for us is that we do not only need the initial code but also a commitment from new maintainers that they are going to maintain it for a foreseeable future. We can only pull plugins under the Operaton umbrella if we find enough contributors for it. We also need some evidence that the plugin is used in real world projects and of general interest. Our pledge is that we take care of all projects under the Operaton umbrella but unfortunately we can only do this if we also grow our contributor base.
Lars and I for example are maintaining the keycloak plugin, which is the only plugin we have adopted right now.
The question is not if Operaton team would maintain community projects.
I think a central place would be good. Otherwise we risk that several forks of community projects appear scattered across the Internet instead of joining forces.
We could either make Operaton community org. Or a GitHub project “awesome Operation tools” where just link other projects and repositories.
That makes perfect sense — thanks for clarifying!
I’d be happy to contribute and help maintain a community project, but it doesn’t have to be part of the main Operaton codebase right away.
Similar to what Markus suggested, it would be great to have a place where we can host community projects related to Operaton.
If some of these projects gain enough traction and adoption, they could always be considered for inclusion under the main Operaton umbrella later on — just like what happened with camunda-bpm-assert in the past.
If such a space becomes available, I’d be happy to share my fork there as well.
Perhaps we can find some new name for the ex “community hub”. As Tim already said, the whole project is now the community.
But there could be something like our “garden projects”, where everyone can publish their plugins without any guarantees that they will be maintained and/or be compatible with Operaton in the future.
I don’t like it to call it “incubator” or something like this because this would imply that it should/must be developed to an “officially maintained” project.
The most successful “garden projects” could be considered to become an “officially maintainted plugin” for Operaton if we get a commitment from their maintainers.
I think this could be a nice idea. What do you others think?