Re: [eclipse.org-architecture-council] The Opportunity

[Tyler Jewell <tyler@xxxxxxxxxxx>]

We are of the mindset that the Codenvy .exe installer was unhelpful, as it created an expectation that Che makes the installation perfect each time. The EXE installer installs Docker Toolbox (vbox, docker-machine, docker, git bash), and until that installer is perfected (it is not), we inherit its limitations. 

We are likely to remove support for the .exe installer. We will then offer two configurations:

1. A zip / tgz installation where docker-toolbox and java must be installed separately by the user, and

2. A logon to a hosted che, which requires a single click experience.

We will support companies in the ecosystem, like Yatta, which have signaled that they are authoring a launcher for embedded che services - which will provide its own form of installation of Che with virtualbox + docker.

Also, Codenvy has a hidden mode in Che that allows it to run without workspace portability - essentially using localhost machines, having it behave like desktop IDEs. We have withheld it and do not allow our developers to use it, as it's a slippery slope. One day you wake up and localhost machines are the default configuration in Che, ultimately defeating the original goal of movable workspaces, for which some sort of VM / container technology is required.

Our focus for the next two years will be supporting extension developers. While our engineers built a tool they wanted to use for Java, we'll defer more to the community to shape the plugins for different languages into the developer experience they want. Our job is primarily in supporting extension authors to prove viability of the system.  A week ago, I initiated an RFP process to find an outside partner that would create a plug-in developer resource center for Che -- docs, tutorials, training, webinars, and events. If there are ecosystem consulting companies that have strong Eclipse + Java expertise, we'd like for them to bid on the RFP.

Che already supports SSH through the Eclipse IDE. You can direct mount Che projects. We have an outdated Eclipse plug-in that also shows how you can stream build / run actions executing remotely on Che into the desktop IDE. There is nothing preventing that plugin from advancing further, all the way to the point where the Eclipse IDE had no local dependency on JDT - only using Che's hosted version. We've also tested WEBDAV and it works just fine.  Though the primary opportunity for consolidation is to make Eclipse IDE have a smart protocol that lets it float between local workspaces or remote ones, without losing access to intellisense services.  Let the workspace float to any location (che) and let the IDE use local or remote (Eclipse IDE) is the ultimately level of choice that satisfies developers, teams, enterprises, and organizations.  Every team will make their own choice on how to develop.

I am not technical enough to answer the reuse question. But I believe the work that our engineers did was to take JDT as a whole, and then added modifications for it to run headless with RESTful interfaces.

The RCP architecture of extensions and Che's are different. The portability path from one to the other will be guidelines and how-tos vs. any sort of auto-converter. Our engineers tried to honor the existing interfaces where possible, but the distributed & RESTful nature of Che forced us to deviate in many locations. For example, one area that we are working on is with SmartBear - their new SwaggerHub allows for stub generation of APIs. It is not a stretch to let a developer create a workspace, connect to that workspace's Swagger interface, tell Swagger to generate a new API, and Swagger will generate, compile, and deploy that API as a new Che extension deployed within the Che server and the targeted workspace. It's also possible to then generate both the Eclipse IDE plug-in and the Che IDE browser plug-in that consumes that service within the GUI.

Every day that goes by we learn a little bit more about how to build extensions that are distributed and deployable. I am sure our journey of learning will continue for many more years.

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55

On Sat, Mar 19, 2016 at 3:07 PM, Jay Jay Billings <jayjaybillings@xxxxxxxxx> wrote:

Tyler,

Thanks for the email. I'm very glad you reached out to us. Could you clarify a few things for me?

1.) What is your plan to make Che easier to install and run? I hear enough complaints about installing Eclipse, and installing Che is, relatively speaking, much harder. To wit, 5k downloads per day does not mean 5k new users per day, and to truly capitalize on your momentum you need to make sure you hook people quickly with a fast, smooth install process.

2.) Do you plan to provide extensive documentation on extending Che and to support the many members of the community that would like to build training services around Che?

3.) Do you plan to support hybrid configurations where the Che server and workspace are used via SSH through the Eclipse IDE? You mentioned this several times in your talk, but I am curious to what degree you will support it as one way to use Che.

4.) What level of compatibility and reuse is available for RCP plugins with Che? For example, how much of JDT were you able to reuse? CDT? WTP?

Thanks again for taking the time to write to us. I'm sure others will have questions too and your openness is greatly appreciated.

Jay

On Mar 19, 2016 15:50, "Tyler Jewell" <tyler@xxxxxxxxxxx> wrote:

At last week's EclipseCon, we had a public unveiling of Eclipse Che. 

Generally, the engagement and support has been substantial. There have been some concerns stated around the marketing tactics used by the project and potential confusion that this creates around the future of other projects within the Eclipse Foundation.

Here is my position.

Codenvy is completely committed to the Eclipse Foundation. Not Eclipse Che, but the Eclipse Foundation. Codenvy has a unique business strategy where Eclipse's universal success leads to commercial success for Codenvy. There are not many companies that can make this sort of statement about their relationship with an open source foundation.

Our relationship is one where we believe that 80% of Eclipse technology users are ultimately employees within organizations that we want to sell to. Growing the reach of Eclipse technology from 5M to 20M users is an essential part of our strategy.

From our humble beginnings 4 years ago, we always intended to take an open source strategy. We knew that ecosystem is the lifeblood of commercial opportunities, and we had aspirations to establish community that mirrored Eclipse's success.  Open source is the only way to achieve this.

Eclipse was not our first open source channel. We originally targeted the Apache Foundation because of the perceived lock-in of the Eclipse IDE at the Eclipse Foundation. We had made light overtures from time to time, but Eclipse Foundation's identity was intimately tied to a single product that could perceive our initiatives as a threat. It was the accidental and thoughtful dialog with key IBM engineers that opened doors with Mike's management team where the first signs of openness were expressed.  That was over 2 years ago.

The first year of our membership was an uncomfortable scenario where we had to perform significant engineering, to explore various positioning, learn how to operate in the open, and figure out how to overcome the built-in advantages afforded the Eclipse IDE while honoring its history.

At the same time, the Eclipse Foundation and the IDE itself suffered perception issues in the market. I honor everyone that bleeds the Eclipse IDE. It is a lifetime labor of love for those involved. Those involved deserve medals for their efforts.  Though, as an organization, we cannot turn a blind eye to the market perception - the IDE was losing market share, and market sentiment had turned negative. 

When this happens, incremental product improvements alone cannot change momentum. Momentum is altered by changing the market dynamics. To attract more developers to Eclipse, Eclipse needed to have an identity makeover that attaches it to "modern" & "innovative" criteria.  The working group and technology initiatives related to IOT and location tech are helpful, but the organization was publicly thought of as purely an IDE organization.

So we had to tackle the IDE perception issue directly. We felt that we needed to change the market dynamics from 3 products (netbeans, intellij, eclipse) to 4 (+che).

Eclipse Orion started down this path - but as the product narrowed its scope, its market perception became tied closer to web-technologies and web editing. Also, while a couple years ago we attemped to create a consolidated Eclipse Cloud Dev roadmap around a single vision, this consolidation did not occur.

In the summer of 2015, after our 3rd rewrite in 4 years of the kernel, we saw technology for the first time that gave us confidence that we could satisfy the essentials for generating a new platform:  a) extensible to the same degree as Eclipse, b) responsive with performance that would surprise and amaze, c) design that was professional, and d) configuration with docker such that workspace portability could really be solved.  We were convinced that we had solved the "innovative" criteria.

We just needed to solve the "modern" criteria.

Unfortunately, Google's adoption of JetBrains had accelerated the negative perception problem. There was a perception debt that also had to be paid down.  Also, in the past 2 years, most of our positioning exercises had attached to cloud development - and that story just fell flat.  We needed something more significant.

We recognized that the only way to grow the overall Eclpise community was to position in such a way where there was a story of the future, but also neutralized the realities that exist with negative perception.

The next-generation positioning combined with a story on fundamental problems faced by all workstation-based IDEs proved to be a magical combination. It was the right story as it allowed us to package a forward-looking story.  We did not have to be a dirty politician by attacking individual products, though we have no problem reminding the community that JetBrains is not truly open source.

That story has hit a nerve and there is significant engagement and adoption. I have provided the event summary below. Important to me - we are seeing about 75 GitHub issues posted / week, and about 10% of all pull requests are coming from non-committers. Just this week, Codenvy executed an agreement with a F100 IOT provider to build an embedded IDE for their devices based upon Che - it will be on display at a keynote in May and has potential reach to 10M people over 20 years.

This is substantial and meaningful for the Eclipse IDE:

1. The community at large does not make the distinction between the pockets of people who work on the Eclipse IDE or Eclipse Che. They just presume that we are all Eclipse people. We are, aren't we? The community believes that the people that brought them the Eclipse IDE is bringing them Che. This halo affect will create larger interest and immediacy in people's adoption of the Eclipse IDE. There are organizations that Codenvy is working with that were considering JetBrains purchases that are now reconsidering open source. Questions that rise about future investment in Eclipse IDE are simply answered with communication and a roadmap.

2. Our vision is more substantial than a portable workspace. We are moving into an era where developers care more about maintaining their right to choose their tools than following the corporate standard. At the same time, corporations desire team-based productivity enhancements, governance controls, and securing the devops workflow. Some of these problems can be solved on the edge device, and some can be solved in the server room. Each organization will have a bias as to whether their developer services (intellisense, development workflow, test environments, etc) should reside on each developer's machine or within the workgroup.  So let's let them have their choice.  The way we achieve that choice is to let enterprises choose their preferred tool and make interoperability between local services and remote services.  We are the only organization positioned to deliver on this vision - where intellisense, test runtimes, tooling stacks can float between the server and the desktop, giving the developer their choice of preferred tool: desktop IDE, browser IDE, or other.  The momentum of Che combined with Eclipse's existing base makes us the only vendor that could plausibly pursue this.  And this creates substantial commercial opportuntiies for each of our companies since the workspace workflow is the only component that is integrated into version control, issue management, and continuous integration. Leading on this front lets our organizations lead more ambitiously on continuous delivery + devops.

3. This momentum provides confidence to Codenvy's investors that there is a future, large commercial opportunity. Investors like to chase growth, and that perception historically does not exist with IDEs. With Codenvy's marketing budget approaching $1M and 80% of it dedicated to Eclipse-related engagement, I am not sure there is any other single company that is spending as much to promote Eclipse technologies. With investors focused on growth, as Codenvy demonstrates commercial viability, there is no reason that our marketing budget doesn't follow an exponential curve. This strategy allows us to pursue a business plan that excites potential investors, which leads to more investment dollars directly channeled into areas that benefit Eclipse.

For those organizations represented here that have had their marketing departments slow their sponsorship of Eclipse initiatives, the current marketing environment is an amazing opportunity to attach themselves to a growth wave that will fundamentally change the nature of development within enterprises for the next two decades.  I am happy to share with each and every one of your marketing departments why this opportunity is significant and how their historical investments and enhanced future investment can be directly beneficial to their enterprise sales objectives.

I believe our opportunity is to bring our projects closer together, establish Eclipse brand as innovative and modern, and to provide a vision of confidence to software development teams that we are collectively working on making their lives better.

Tyler

Keynote

http://www.infoq.com/presentations/eclipse-che-eclipsecon-2016?utm_source=infoq&utm_medium=videos_homepage&utm_campaign=videos_row1

SAP: 23:40

Red Hat: 28:20

IBM: 36:30

Microsoft: 43:45

Momentum:

- 250K views to Che site

- 2k tweets

- 1000 additional github stars added to our repo - we are in the upper 1% of all github repos

- ~5K downloads / day of Eclipse Che

eWeek

Eclipse Snags Microsoft, Lauches Che IDE for the Cloud

IDG News / PC World / InfoWorld

Codenvy Teams with Microsoft to Help Developers Work Together

SD Times

EclipseCon Kicks off with Che Release

The Next Web

Eclipse Che is a Cloud-Based IDE that wants to reimagine how developers work

Return GIS

Eclipse Che on Microsoft Azure

InfoQ

Eclipse Foundation releases next-generation IDE, Eclipse Che 4.0

Techcrunch

Microsoft joins the open source Eclipse Foundation

The New Stack

Eclipse Che: Portable shared development workspaces with built-in runtimes

Enterprise Times

SAP lures developers with Eclipse Che IDE

IT Business Edge

Eclipse Che IDE for the cloud enjoys broad support

Ars Technica

Microsoft joins the Eclipse Foundation, open sources some of its plugins

BetaNews

Codenvy and Microsoft streamline the developer workspace

WinBeta

Microsoft announces it is joining the open source Eclipse Foundation

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.