今年5月份，红帽宣布收购Codenvy。 Codenvy的工程师占了Eclipse Che贡献者基数的三分之一，是其创始人，也是其主要维护者。
Eclipse Che的大部分贡献者和提交者现在都是Red Hat的员工。红帽对开源的承诺使得员工有时间，资源和广泛的权力在开源社区继续他们的工作。
红帽获得Codenvy的动机是得到了他们对Eclipse Che的支持和热爱。当一个上游项目拥有广泛多样的生态系统时，红帽的产品和服务就更加强大了。
好消息 - Codenvy的源代码将使用Eclipse公共许可证进行开源。 Eclipse Che项目将重用许多Codenvy子系统，以扩展其在大型团队和企业中的适用性！
另一方面，Codenvy开始作为一个封闭的专有产品，建立了一个成功的客户和用户基础，后来将Eclipse Che构想为从我们的平台提取的开源内核。
Codenvy的策略是为开发人员提供有价值的开源技术，以证明工作区在计算机之间可移植，并为ISV提供用于构建插件，编程语言服务器，扩展和堆栈的SDK。我们对开放专有价值的信念是如此之强，以至于我们不断为Che增加改进，使生态系统能够在其上建立强大的产品，知道其中一些产品可能会变成Codenvy的竞争对手。
我们认定Che对个人和ISV是有利的，但是团队，工作组和企业应该为Che的多用户实施支付Codenvy支持和许可费用。为了执行此操作，Che的开源安装不支持多个用户，并且不能扩展到单个服务器之外。一个多用户Che要么需要购买Codenvy，要么建立一个Che farm，每个用户都配置了自己的Che VM。 Che农场难以建立，需要昂贵的物理资源才能运作。
这个开放的核心方法在Codenvy中运作良好，我们建立了良好的商业业务。但是，我们在市场上造成了意想不到的摩擦。
Che是一个“工作区服务器”，市场期望一个多用户系统。多少个服务器只支持一个用户？虽然Che允许单个服务器上的许多用户，但他们共享相同的用户配置文件和偏好。我们不包括用户数据库，登录框架，身份验证，授权，权限，资源管理或组管理。
我们在所提供的与所期望的之间创造了一种不和谐。这种不和谐是社区为克服这些局限性而进行的许多尝试（搜索Che的GitHub repo，与nginx，代理，多用户，身份验证和存储相关的问题）。
战略
我们认为开发团队采取持续交付所面临的最大挑战是管理其开发基础架构。一些开发团队花费高达50％的时间来管理基础架构。
现代的持续发展需要聊天，问题管理，管道，IDE，工作区，部署和编排。这是提供，配置和集成在一起的很多技术。有时候，个人开发团队成员必须自己进行配置，而在其他情况下，则是DevOps团队的负担。随着项目范围和复杂程度的增加，这种管理税率上升。
我们认为市场将越来越多地将这些技术打包在一起，创建预先集成的DevOps套件，试图降低管理开发基础架构的成本，同时将开发流程商品化。
这些预集成的DevOps套件将需要完全管理和动态调配的云工作空间。桌面IDE不能实现这个承诺，因为它们不能被开发基础设施调配。云IDE和工作区服务器是解决这些问题的唯一方法。随着Codenvy特性进入Eclipse Che，Che成为DevOps的云IDE标准。
我们的策略是让Eclipse Che成为个人和团队的完整工作空间服务器。 Che将能够作为工作组服务器独立运行，或嵌入并集成到DevOps套件中，在这些套件中，通过上下文对工作空间进行按需配置。
新的Eclipse che
我们正在努力将Codenvy的下列内容带入Eclipse Che：
多用户身份和配置文件。
用户认证与Keycloak。
用户数据库保存Postgres。
权限API（工作区访问限制）。
用户管理仪表板。
工作区和用户事件的电子邮件通知。
SSL。
团队和组织 - 用于管理工作空间和用户的结构
工作空间安全 - 通过标记和代理管理实现对工作空间的访问。工作空间闲置 - 当用户闲置时管理后台工作空间.
Codenvy的基础架构基于Docker Swarm，nginx，haproxy和postgres。 Che将分离基础架构关联，以便用户，工作空间，权限和资源的逻辑管理不受基础架构HA，可伸缩性和安全性方法的限制。我们将为Eclipse Che部署提供Docker和Kubernetes基础架构选择。您将能够将Che部署为无需身份验证和用户数据库的单用户版本，也可以将多个用户版本（包含用于代理的容器进行打包，使用keycloak进行身份验证以及使用postgres进行用户数据库管理）部署Docker基础架构，最多可支持50个团队。或者，您将能够将Che部署到Kubernetes集群，并利用HA，可扩展性和企业管理功能.Red Hat将提供一个版本的Che打包用于与RHEL，Red Hat OpenShift或Red Hat Docker一起部署以及Che栈的专用包装。这个包装是为了开发和生产支持而设计的。在我们对SDK的承诺和使ISVs保持不变的情况下， Che SDK将得到丰富，ISV生态系统不断培育，使我们的白标签和定制合作伙伴得到更多，而不是更少。时间框架尽快！实际上，可能大概是3-6个月。开源Codenvy的工作很简单。但是，我们需要通过Eclipse IP过程来验证一些IP，并用Kubernetes替换Codenvy的Swarm依赖关系。我们的工作要求：将Red Hat现有的OpenShift连接器分支移到Che的主分支中。这是红帽公司9个月前开始的工作，它为Che提供了一个界面，将其工作空间操作委托给Kubernetes API而不是Docker。我们希望这在下个月合并。创建如何将Che的Dockerfile部署到Kubernetes系统的说明和包装。我们有如何做到这一点和许多帮手脚本的经验。但是我们需要编写可靠的文档，并且可能包含Che CLI中的最佳实践。稳定Che 6 SPI，使长期可管理的封装不同的基础设施连接器成为可能。 Docker和Kubernetes连接器应该分别进行长期管理。通过Eclipse IP验证过程来移动Codenvy子系统。使用Keycloak（一个更灵活和更强大的系统）重写Codenvy的身份验证子系统。获得参与！有超过50人向Che文档，支持和代码库。我们希望您能够参与并帮助我们构建世界一流的工作区服务器。请查看我们的GitHub问题，帮助我们获得支持，并参加每周的社区会议，了解您可以为社区做出贡献的地方。
