Rename Workspace to Dev Environment

[ivan-burazin]

Is your feature request related to a problem? Please describe. Renaming "workspace" to "dev environment" in DAYTONA can significantly improve clarity. The term "dev environment" is more specific and recognizable to developers, as it directly indicates a space meant for development-related tasks.

This specificity eliminates the ambiguity associated with the generic term "workspace," which can refer to any work area and not necessarily development.

Additionally, adopting "dev environment" aligns with industry standards and practices. Example; Docker uses "dev environments" to describe its configurable spaces for development. On the other hand, GitHub uses "codespaces" for its cloud-hosted development environments, while reserving "workspaces" for different purposes within their broader ecosystem

[Tpuljak]

I don't agree that renaming workspace to dev environment will improve clarity. On the contrary, I think it would reduce it.

TL;DR:

• Competitors and similar products use Workspaces.
• A Workspace is a development environment, describing Dev(elopment) Environments would require us to adapt what a development environment is, which might make it more confusing to users.
• Docker Dev Environments are no longer under active development so I wouldn't bring that into the conversation.

1. Competitors

Competitors and similar products have adopted the term Workspace for a development environment they manage. They have the same platform-"development environment" relationship that Daytona has and, I would argue, this goes in favor of us adopting the same term. I can assume that the term Workspace did not come lightly to products in question and that similar discussions were held. Landing on Workspace, multiple times over, just goes to show that it is a term that resonates with the userbase.

2. Redefining what a Development Environment is

If we were to adopt Dev(elopment) Environment as a term for what Daytona provides to the user and what the user is interacting with, this would require that we adapt the definition to our usecase. For example, we might be forced to say A Daytona Dev Environment can be multiple projects connected via a secure network. whereas, A Daytona Workspace is a development environment that has one or more projects connected via a secure network.

My point being, because a development environment is a well-defined term, that goes beyond Daytona, choosing Workspaces gives us more freedom in defining the specific relationship it has to our product.

3. Docker Dev Environments

Even Docker has a less than ideal description of their Dev Environments: Dev Environments let you create a configurable developer environment (source). Using developer environment to describe a Dev Environment.

Also, they are no longer under active development so wouldn't use them as a point in this discussion. https://docs.docker.com/desktop/dev-environments/

[vedranjukic]

@ivan-burazin can you please provide more examples on "Additionally, adopting "dev environment" aligns with industry standards and practices.", except for Docker? Because, on the contrary, the term "Workspace" is often used in the industry, while "Dev environment" is not. To be very specific, we are talking about the compute instance where the developer is doing the development. I am open to discussion but I believe that we should adopt the naming that aligns with Industry standards and that developers are accustomed to.

[ivan-burazin]

Here are some points I’d like to address regarding the use of terminology for development environments:

1. Terminology Usage:

   • While it may be subjective, I've commonly heard "dev environment" used frequently, but "workspace" is less common. This could vary by region or community, but "dev environment" is generally more recognizable.

2. Clarity:

   • @Tpuljak example proves that point; this enlists a level of complexity more stating a "Workspace is a development environment..." instead of just "development environment..."

3. Brand Consistency:

   • Using "dev environment" maintains our branding as a Dev Environment Manager (DEM) or even if we use Gartner's term - Cloud Dev Environment (CDE). Switching to "workspace" would require changing to Workspace Manager (WM) or Cloud Workspace (CW).

4. Examples of Dev Environment:

   • Docker Dev Environment
   • JetBrains Space Dev Environment
   • AWS CodeCatalyst Dev Environment

5. Marketing Terminology:

   • Some companies use unique terms for marketing, such as GitHub Codespaces and OpenShift DevSpaces. These terms might make sense with a significant marketing budget to support them. But as we have none, would not suggest a unique name for Daytona's unit of value.

6. Definition:

   • the term "workspace" in connection to Development, according to its definition is far less than what Daytona provides; "A workspace is (often) a file or directory that allows a user to gather various source code files and resources and work with them as a cohesive unit.[1]"

7. User Intent:

   • Searching for "Workspace" typically yields results for "Google Workspace," a productivity suite. Even searching for "developer workspace" doesn't yield much better results. However, searching for "Dev environment" provides relevant results related to the product we are offering.

[Tpuljak]

@ivan-burazin I think my points were a bit misunderstood.

I'm not saying that by using Workspace we would stop being a DEM or that we wouldn't be able to use dev environments in our web, marketing materials, etc. On the contrary, by using Workspace it would be much more clear.

We need a named term for the development environment that Daytona manages and the question is should we name it Dev Environment or Workspace. This discussion doesn't change the fact that we are a development environment manager nor would it change how we brand ourselves or handle SEO. A Workspace is the name of a Daytona development environment. It's not something that the user would search for nor is that the point. If we were to use Dev Environment we would have a collision in what the general understanding of a development environment is, and what Daytona manages.

I still believe that the strongest argument in favor of Workspaces is that products most similar to Daytona (apart from GH Codespaces) use Workspaces.

Lastly,

JetBrains Space Dev Environment

They use dev environments, not Dev Environments. Their name for what they manage is Space dev environments.

AWS CodeCatalyst Dev Environment

AWS, from what I can tell, is the only product (that's not abandoned) that uses Dev Environments.

[ivan-burazin]

I'm not saying that by using Workspace we would stop being a DEM or that we wouldn't be able to use dev environments in our web, marketing materials, etc. On the contrary, by using Workspace it would be much more clear.

How can we market Dev Environment if there is no Dev Environment in the product? CCing @nkkko to weigh in as well

I still believe that the strongest argument in favor of Workspaces is that products most similar to Daytona (apart from GH Codespaces) use Workspaces.

Is doing something "jest because" competitors (in a niche market mind you) use it, a good reason?

They use dev environments, not Dev Environments. Their name for what they manage is Space dev environments.

What is this difference? They use dev environments, not Dev Environments? Also Space is a product on its own, like Codecatalyst and Dev Environments is a service inside it.

[Tpuljak]

What is this difference? They use dev environments, not Dev Environments?

Big difference. A development environment is just a noun that describes what they manage. It will be used in Daytona in the exact same way. Dev Environment is a name. Because it's a name, it needs explaining in the context of the product. Daytona Dev Environment is a development environment....

How can we market Dev Environment if there is no Dev Environment in the product?

We won't market Dev Environment, we will market dev(elopment) environment.

Is doing something "just because" competitors (in a niche market mind you) use it, a good reason?

It's not a "just because" argument, it's a "discussions were already held" argument.

Workspaces give us much more flexibility in how we define what it is in the context of Daytona.

[ivan-burazin]

Big difference. A development environment is just a noun that describes what they manage. It will be used in Daytona in the exact same way. Dev Environment is a name.

I use capitalisation for Title Case purposes - when you use it in a title. Fine that it is dev environment in written form when not a title.

We won't market Dev Environment, we will market dev(elopment) environment.

Same question as last time, how can we market dev(elopment) environment if there is no dev(elopment) environment in the product - there is just a workspace?

It's not a "just because" argument, it's a "discussions were already held" argument.

Who held the discussion? what is the argument?

[Tpuljak]

Same question as last time, how can we market dev(elopment) environment if there is no dev(elopment) environment in the product - there is just a workspace?

A Workspace is a development environment. We can market development environments all we want.

I use capitalisation for Title Case purposes - when you use it in a title. Fine that it is dev environment in written form when not a title.

It needs to be capital case because it needs to be a name for environments that Daytona manages.

Who held the discussion? What is the argument?

I don't know, but landing multiple times on Workspace (and none on Dev Environment) is enough to conclude that Workspace works with the userbase.

[ivan-burazin]

A Workspace is a development environment. We can market development environments all we want.

i dont see that: https://www.google.com/search?q=workspace&rlz=1C5CHFA_enHR1073HR1073&oq=worksp&gs_lcrp=EgZjaHJvbWUqCQgAEEUYOxiABDIJCAAQRRg7GIAEMgYIARBFGDkyBwgCEAAYgAQyBwgDEAAYgAQyBwgEEAAYgAQyBggFEEUYPTIGCAYQRRg8MgYIBxBFGD2oAgCwAgA&sourceid=chrome&ie=UTF-8

It needs to be capital case because it needs to be a name for environments that Daytona manages.

Why?

I don't know

Exactly thats why its not an argument

[Tpuljak]

The topic of this discussion is the name of environments that Daytona manages. The topic is: Should we call them Workspaces or Dev Environments.

Choosing either has nothing to do with marketing development environments because both represent development environments managed by Daytona.

Why?

Because we need a name. E.g. we need to have a section in the docs that explains what is a development environment managed by Daytona and it has to have a name, either Workspace or Dev Environment.

The term Workspace doesn't even have to be on our landing page, nor should it. The landing page and all marketing material will focus on development environments (lower case) but Workspaces will be in the Docs when people look for specifics about environments managed by Daytona.

Exactly that's why it's not an argument

The fact that Workspaces is most commonly used is the argument.

I suggest we stop here since we obviously don't see eye to eye and wait for others to chime in.

[nkkko]

If we consider our own definition, dev env is more than the workspace, it is a superset, for example it contains also an IDE.

I would put it like this:

1. Development Environment: Definition: A comprehensive ecosystem equipped with all necessary tools, configurations, and resources needed for development tasks. Key components: IDE, version control, package managers, build tools, deployment tools, etc.

2. Development Workspace: Definition: A specific segment within the Development Environment configured for particular tasks or stages of development (e.g., frontend development, backend development). Role: Acts as the context within which multiple repositories (codebases) can exist, offering specific configurations, toolsets, and resources.

The line is blurry and can be moved. I don't like that Dev Environment is a two word construct. Environment would be better in my opinion if we are considering this. For example: "The user can have multiple projects inside the same Environment", this is wrong atm, as for each repo we setup separate "environment".

I was avoiding to contribute here, as I have more confusion with Workspace - Projects relation. :D For example Github removed "Projects" and is now using repositories as term. This honestly, is not correct 100%, but I can understand that for typical user this brings in more clarity.

So some of the options could be:

• Workspace - Projects (as is)
• Dev Environment (or short DevEnv) - Projects
• Environment - Projects
• Environment - Repositories (personally like the most)

I agree that this is an important point, as the actual renaming would be impossible at the later stage (or really confusing and hard). It is always a question of spending time to educate. But also, I am not feeling terrible pain point here, and it could stay as is.

[ivan-burazin]

Choosing either has nothing to do with marketing development environments because both represent development environments managed by Daytona.

Of course it does. Example I am on a demo/presentation and state we "manage development environments" then on the next step i say now go to "workspaces". I have done this 100+ times and very often people stop me and say "what is a workspace?"

Using "Workspace" means introducing a new term, each new term complicates the experience for the user.

[Tpuljak]

Of course it does. Example I am on a demo/presentation and state we "manage development environments" then on the next step i say now go to "workspaces". I have done this 100+ times and very often people stop me and say "what is a workspace?" Using "Workspace" means introducing a new term, each new term complicates the experience for the user.

A Dev Environment is also a new term in the context of Daytona. We can't avoid a new term. The remedy for that situation above is: Workspaces are development environments managed by Daytona or Daytona dev environments are called Workspaces. Alternatively, Dev Environments are development environments managed by Daytona, which, in my opinion, doesn't sound right.

[Tpuljak]

Also, Niko mentioned our definition above. That's a definition for a development environment. If we choose to go with Dev Environment after this discussion, we will need to have development environment and Dev Environment in our glossary. I think that's infinitely more confusing than having development environment and Workspace.

[ivan-burazin]

bump for @nkkko also @osslate feel free to chime in

[nkkko]

Using direct terminology like "Environment" could minimize the cognitive load on users, who might not immediately understand what a "Workspace" is. Two-word construct is too much. But ideally, we could survey the user base.

[vedranjukic]

@ivan-burazin CodeCatalyst does not use the term "development environments" to describe instances of development environments.

JetBrains uses "Dev Environments" and that is a name for their instance of development environment: Dev environments are virtual machines running in the Space cloud. You can use these machines for software development instead of your local machine.

Personally, CodeCayalyst is much more appealing to me as it is a unique name that is not similar to the term "development environment".

[nkkko]

The issue with unique names is that you need to explain them and educate the user about them. CodeCatalyst doesn't convey information by the name itself on what it does. I think this is the main point of this issue as raised by Ivan. Reducing the cognitive burden of users.

[vedranjukic]

What is there to explain for the "Space"? It is as obvious as it can be.

[ivan-burazin]

What is there to explain for the "Space"? It is as obvious as it can be.

JetBrains Space: The Intelligent Code Collaboration Platform it is not the name of the Dev Environment product

[vedranjukic]

I'm not talking about JetBrains, but CodeCatalyst

[ivan-burazin]

Please elaborate this then, do not follow:

What is there to explain for the "Space"? It is as obvious as it can be.

[vedranjukic]

CodeCatalyst Space - the name of the development environment instance

[vedranjukic]

Adding more context on the CodeCatalyst naming.

Space - Project management context - eg. abstract organizational unit. Project - a collaboration space where development teams conduct development tasks. A Project context can contain one or more development resources. Dev Environments - Dev Environments are cloud-based development environments. These are VMs that allow developers to connect to and work on the code stored in the source repositories of your project.

[vedranjukic]

CodeCatalyst DevEnvironment is one per repository. Each Project consists of multiple repositories (one or more).

[vedranjukic]

There is ambiguity with the naming of Daytona "Projects" that we need to sort out before we continue the "Workspace - Dev Environment" discussion.

[Tpuljak]

I would argue that the parallel to the CodeCatalyst naming would be:

• Spaces => Daytona Server instance / profiles
• Projects => Workspaces
• Dev Environments => Projects

I think it's pretty clear this is a very subjective matter because, in my mind, I wouldn't associate a Project as having multiple repos that can have multiple dev environments.

[vedranjukic]

The goal of the discussion is to find the naming solution that aligns with what developers are used to in the best possible way. So I'd avoid subjective matters. I think we should avoid using terms that can cause ambiguity. Project is a term that can confuse users and requires additional effort to explain.

[vedranjukic]

Revisiting the initial naming convention, the "Project" is a contextual boundary around the single repository (or a project folder in case the same doesn't have a git repository - for example, a local project). The name "Project" was taken from the "Devfile" specification where the "Project" also serves as an entity to define the source of the project content (git repository or a zip file).

Daytona Workspace concept is very similar to the Devfile structure, while CodeCatalysts features a different paradigm for what the CodeCatalyst Project is used for.

Therefore I would conclude that the "Project" as a part of the "Workspace" makes sense and should stay.