Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] The Opportunity

It's less a shift to a web IDE vs. a shift to distributed developer services.

There are three triggers:
1. Open source
2. Agile development
3. Embedded IOT systems

The story I gave in the speech wasn't a line of convenience. It was a true story.

My challenges and frustrations are universally felt. Vagrant is a great technology but is an 80% solution, and there are just as many companies that are frustrated by it, as they are satisfied with it.

People will not go in search of a Web IDE. I believe that in 100 years there will be 1000 IDEs and developers will have their biases.

But people will accept (and be thankful for) a Web IDE in circumstances where they didn't want to bother with tooling setup.

This starts by getting open source projects to badge their repositories with one-click setup. Generally, project committers would rather spend their time writing pull requests vs. helping new contributors get set up to make a contribution. The badging for contributors then makes the contribution workflow clearer and demonstrates that there are pockets of acceptance in the world for using such services. We have about 20 open source projects that will be putting up badges & Codenvy will give those projects free, unlimited usage for their team members or contributors.

The second step is agile development in the enterprise. Agile development is about getting feedback earlier in the cycle. The tool configuration tax is so high that many members of the agile team: users, PMs, QA cannot necessarily contribute to the code easily. Making a web IDE with one click setup lets the entire delivery stakeholder group have a way to contribute to code before it is merged.  The companies that we get to work with are usually driven by management, devops, or R&D VPs.  So this sort of productivity improvement is a management initiative.  We almost always go into an enterprise and do a dual setup of Eclipse + Codenvy, so for developers that want to continue using their own desktop configuration they can continue to do so.

The third step is embedded IDEs. Devices that have their own IDE for projects as they boot up. Plug the device in, get the IP address, and start building an application. It completely changes the approachability of IOT for children and those that have never programmed before.

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


On Sat, Mar 19, 2016 at 5:09 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
Yes, thanks Tyler for your detailed write up. It definitely helps us understand where you are coming from.

At the moment, I only have one question I guess. We we've been talking here and on the Twittersphere about the recently release Stack Overflow Developer Survey and its section on Development environments. For reference, the results are here:


We were actually quite pleased to see Eclipse still used by 23% of survey's respondents, ahead of IntelliJ though it's hard to tell once you factor in Android Studio. It was also interesting to note the popularity of text editors in this survey along with the top desktop IDEs. It appears from this survey that developers are still very focused, if not exclusively, on development on their desktops.

I was wondering, what factors you are seeing that will cause such a tectonic shift in developer behavior that they will start using web IDEs in the huge numbers you have mentioned. I understand the vision and the marketing, I'm just wondering how it will manifest itself on the ground.

Thanks!
Doug.

On Sat, Mar 19, 2016 at 6: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

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.


_______________________________________________
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.


Back to the top