# Name for the "runnable distribution" **URL:** \ **Category:** Development\ **Created:** [December 13, 2024, 10:55am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114 "2024-12-13T10:55:12Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![javahippie](https://forum.operaton.org/user_avatar/forum.operaton.org/javahippie/32/25_2.png) [@javahippie](https://forum.operaton.org/u/javahippie)\ **Post date:** [December 13, 2024, 10:55am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/1 "2024-12-13T10:55:12Z")
This is a thread to follow up on a discussion on a ticket: [Replace banner logos for Operaton · Issue #331 · operaton/operaton · GitHub](https://github.com/operaton/operaton/issues/331) @kthoms put in a lot of work to make the “run” distribution work again. It is now built in the nightly build and can be run without setting up any code in the project. It’s great to have that option again, thanks a lot! In the ticket, the question arose if we wanted to put “Operaton Run” in the startup banner or just “Operaton”, and this led to the question if “Operaton Run” was even the best choice for a name, or if it was too close to the upstream projects naming. I can think of several pro and contra arguments. E.g. “Camunda Run” was never really expressive in the first place, on the other hand most users coming from Camunda would immediately know what to expect behind the name. What do you think, I would love to read some more opinions on this. Some alternative ideas I came up with off the top of my head: - Operaton Standalone (does not carry the “local dev only” aspect) - Operaton Playground (might sond not serious enough) - Operaton Sandbox (also not serious, also sounds like it would contain something and prevent it from breaking out into the system) ---
**Author:** ![Julian](https://forum.operaton.org/user_avatar/forum.operaton.org/julian/32/30_2.png) [@Julian](https://forum.operaton.org/u/Julian)\ **Post date:** [December 13, 2024, 11:45am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/2 "2024-12-13T11:45:28Z")
Perhaps “Operaton Kickstart” would be also a catchy name ---
**Author:** ![Haiko](https://forum.operaton.org/user_avatar/forum.operaton.org/haiko/32/72_2.png) [@Haiko](https://forum.operaton.org/u/Haiko)\ **Post date:** [December 13, 2024, 1:04pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/3 "2024-12-13T13:04:49Z")
How about ‘Operaton Launch’? Has an active ring to it?! ---
**Author:** ![javahippie](https://forum.operaton.org/user_avatar/forum.operaton.org/javahippie/32/25_2.png) [@javahippie](https://forum.operaton.org/u/javahippie)\ **Post date:** [December 13, 2024, 2:15pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/4 "2024-12-13T14:15:17Z")
Hey @Haiko, welcome to the forum and thanks for the suggestion! I’d suggest collecting some suggestions over the weekend and then posting a poll here, would that be okay? ---
**Author:** ![jradesenv](https://forum.operaton.org/user_avatar/forum.operaton.org/jradesenv/32/24_2.png) [@jradesenv](https://forum.operaton.org/u/jradesenv)\ **Post date:** [December 13, 2024, 5:23pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/5 "2024-12-13T17:23:20Z")
I must say that in every presentation i had, i always had to explain that Run was the standalone version… so maybe “standalone” itself would be a better name than run and will explain it early 😅 But i never really used, as i always used my engine in spring project since the starter was created in 2018/2018, so my “standalone” info can be wrong ---
**Author:** ![fml2](https://forum.operaton.org/letter_avatar_proxy/v4/letter/f/d26b3c/32.png) [@fml2](https://forum.operaton.org/u/fml2)\ **Post date:** [December 13, 2024, 11:06pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/6 "2024-12-13T23:06:52Z")
What is this thing exactly for? What does it do? Also, I’ve heard that the latest SpringBoot does not log any banner under some conditions (IIRC, when the JSON logger is in use). ---
**Author:** ![javahippie](https://forum.operaton.org/user_avatar/forum.operaton.org/javahippie/32/25_2.png) [@javahippie](https://forum.operaton.org/u/javahippie)\ **Post date:** [December 15, 2024, 11:41am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/7 "2024-12-15T11:41:46Z")
The “Camunda Run” distribution is meant as a package to get started quickly with a standalone architecture. I have used it in trainings in the past. It is a Spring Boot setup, preconfigured with the web apps which can be started on Windows, Linux and MacOS with a shell script. It has folders provided in which you can drop the jars for cockpit engine plugins, without needing much Java Knowledge ---
**Author:** ![fml2](https://forum.operaton.org/letter_avatar_proxy/v4/letter/f/d26b3c/32.png) [@fml2](https://forum.operaton.org/u/fml2)\ **Post date:** [December 15, 2024, 12:10pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/8 "2024-12-15T12:10:56Z")
And the communication with the engine is done via the REST API? So that this setup implies the external task pattern, correct? ---
**Author:** ![javahippie](https://forum.operaton.org/user_avatar/forum.operaton.org/javahippie/32/25_2.png) [@javahippie](https://forum.operaton.org/u/javahippie)\ **Post date:** [December 15, 2024, 3:41pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/9 "2024-12-15T15:41:46Z")
That’s correct, yes. You can not (easily) add your own Java Delegates, or at least the setup does not expect you to ---
**Author:** ![fml2](https://forum.operaton.org/letter_avatar_proxy/v4/letter/f/d26b3c/32.png) [@fml2](https://forum.operaton.org/u/fml2)\ **Post date:** [December 15, 2024, 10:54pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/10 "2024-12-15T22:54:23Z")
Ok. Now we have to decide whether the name should reflect what it is or whether it should be just a catchy name that’s easy to pronounce and to recall. For the first type, it could be “Operaton EET” (or just "ET) for “engine for external tasks”. Or “ETS” for “external tasks server”. For the second type “Op. Run” or “Op. Now” would be ok. “Run” has the advantage of being similar to Camunda and familiar to its users. ---
**Author:** ![amzill](https://forum.operaton.org/user_avatar/forum.operaton.org/amzill/32/41_2.png) [@amzill](https://forum.operaton.org/u/amzill)\ **Post date:** [December 16, 2024, 8:21am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/11 "2024-12-16T08:21:56Z")
I would suggest the wording “Operaton Autonomic”. It is similar to “Standalone” but another word :). A bit more fancy sounding. 😉 ---
**Author:** ![Noordsestern](https://forum.operaton.org/user_avatar/forum.operaton.org/noordsestern/32/27_2.png) [@Noordsestern](https://forum.operaton.org/u/Noordsestern)\ **Post date:** [December 16, 2024, 1:36pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/12 "2024-12-16T13:36:02Z")
Why not “standalone”? Fits perfectly, imho. Works out of the box, can easily be extended with professional DB, authentication etc. That is what I expect from “standalone”. Then you have the other distros with wildfly in case you need to bundle the engine with other services l (which is not “standalone”). I’d go with standalone ---
**Author:** ![kthoms](https://forum.operaton.org/user_avatar/forum.operaton.org/kthoms/32/33_2.png) [@kthoms](https://forum.operaton.org/u/kthoms)\ **Post date:** [December 16, 2024, 8:05pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/13 "2024-12-16T20:05:22Z")
“Standalone” is kind of suitable, but also sounds a bit old-fashioned. I have no strong opinion on it, and like it more than other alternatives. The “ETS” version sounds “enterprisy” to me, I kind of like it, but am not sure if it is fully matching the use case. Does it really “serve” external tasks? It more interacts with them, so maybe even the opposite? May I throw new proposals: - Operaton Start - Operaton Ignite - Operaton Barebone ---
**Author:** ![Noordsestern](https://forum.operaton.org/user_avatar/forum.operaton.org/noordsestern/32/27_2.png) [@Noordsestern](https://forum.operaton.org/u/Noordsestern)\ **Post date:** [December 16, 2024, 10:41pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/14 "2024-12-16T22:41:59Z")
What if we just go with Operaton? Except for standalone I find all name suffixes irritating. Like the “run” version would be something not serious. - Operaton - Operaton Wildfly - … The the “core” version would still get the gravity it requires, imho. ---
**Author:** ![kthoms](https://forum.operaton.org/user_avatar/forum.operaton.org/kthoms/32/33_2.png) [@kthoms](https://forum.operaton.org/u/kthoms)\ **Post date:** [December 17, 2024, 6:53am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/15 "2024-12-17T06:53:44Z")
Can be so simple. Yes, why not just “Operaton”? ---
**Author:** ![Julian](https://forum.operaton.org/user_avatar/forum.operaton.org/julian/32/30_2.png) [@Julian](https://forum.operaton.org/u/Julian)\ **Post date:** [December 17, 2024, 10:31am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/16 "2024-12-17T10:31:02Z")
Yes why not, Operaton without the suffix is the “standalone” distribution, vs. Operaton embedded (or specifically Wildfly/Spring/Quarkus/etc) which is the embedded version ---
**Author:** ![javahippie](https://forum.operaton.org/user_avatar/forum.operaton.org/javahippie/32/25_2.png) [@javahippie](https://forum.operaton.org/u/javahippie)\ **Post date:** [December 17, 2024, 10:55am UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/17 "2024-12-17T10:55:30Z")
If I think of a Download page, this would mean we have: - Operaton Wildfly Distribution - Operaton Tomcat Distribution - Operaton This would imply that the “Operaton” one is the default one, the product you should use if you don’t need Tomcat or Wildfly. This argument could be made, as Camunda always stated that Run is production ready and preconfigured. We would name the Docker images in the same pattern, meaning that `operaton/operaton` is the default you should use if you need an Operaton instance which just works with little overhead. In this case we might consider changing defaults. For Camunda Run, according to the docs, you need to explicitly add the `--production` flag to run it in prod mode, this could surprise many people. But that’s a different topic 🙂 I started writing this response opposed to just naming it “Operaton”, but while writing I argued with myself enough to like the idea 😃 ---
**Author:** ![Andreas\_Klein](https://forum.operaton.org/user_avatar/forum.operaton.org/andreas_klein/32/140_2.png) [@Andreas\_Klein](https://forum.operaton.org/u/Andreas_Klein)\ **Post date:** [December 19, 2024, 12:07pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/18 "2024-12-19T12:07:28Z")
We should ask ourselves: “what is the default way we would like our users to use the engine”. In my oppinion using the external task pattern by default is a sensible engineering decision for many projects. Integrating the engine into your Spring Boot project is possible if you need to, but is not the “default” option. Therefore I concur with Julian, Karsten and you on this. We should then definitely run it production mode by default to prevent surprising our users. For local development we can add a `--dev` flag. @javahippie also on the Download page “Operaton” as the default should be on the top of the list 😃. ---
**Author:** ![javahippie](https://forum.operaton.org/user_avatar/forum.operaton.org/javahippie/32/25_2.png) [@javahippie](https://forum.operaton.org/u/javahippie)\ **Post date:** [December 19, 2024, 12:24pm UTC](https://forum.operaton.org/t/name-for-the-runnable-distribution/114/19 "2024-12-19T12:24:57Z")
I agree that Run is the default _for provided distributions_, although the embedded engine pattern is the most used overall in my experience. So I’m still on board with renaming “Camunda Run” to just “Operaton” on the distribution list. In general communication we need to be careful not to call it the default architecture, as it provides way more overhead than the embedded engine pattern