Eclipse N!

The Eclipse Planning Council—with help from the community—is trying to sort out the name for our eleventh named simultaneous release in 2016. We had some trouble with the first set of names that we selected, and so we’re into the second round.

The Lynn Lobby has significant momentum.

The “Eclipse Lynn” Lobby has significant momentum.

We started following the alphabet a few years ago, naming our fifth release “Helios“, and now we’re up to the letter N. We’ve been bouncing around some N names on Twitter; I quite like the idea of just going with “N”, and stated as much.

I originally put in the exclamation mark to make it seem more exciting, but then it occurred to me that the exclamation mark has special meaning in Lisp. In a functional programming language like Lisp, you generally avoid changing state, so Lisp functions that make changes are marked with a cautionary exclamation point (spoken as “bang”). When you invoke a bang function, things are going to change:

It seems appropriate. Change is in the air. I’m excited by the prospect of having an actual installer. I’m excited by our vision of the future of the developer’s platform.

With Mars, our June 2015 release, we’re making a subtle shift to put more focus on the user experience. This takes the form of our Every Detail Matters for Mars effort which aims to tackle a handful of “little things” like getting more of the default preferences right in our packages, standardizing naming conventions, providing reasonable and useful package-specific new and noteworthy documentation, improving the story for adding simultaneous release plug-ins into an Eclipse-based IDE, and more. I’m pretty excited about some bits of the “and more” part, but I’ll save that discussion for another day.

Of course, we’re also trying to tackle some pretty big things. We’ve come a long way towards having a proper installer for Eclipse. I’m also optimistic that we’ll be including Gradle support in Eclipse (more on this later).

We need your help and so we’ve started the Great Fixes for Mars skills competition. To enter, all you need to do is take responsibility for a bug, mark it as “greatfix”, and submit a patch. We’ve even provided a list of great suggestions where you can make the biggest impact. There’s prizes. Cool prizes.

Enter the Great Fixes for Mars skills competition; there'll be prizes!

Enter the Great Fixes for Mars skills competition; there’ll be prizes!

This shift in momentum will build through Mars and into the 2016 release. I’m certain that N-bang will usher in even bigger changes.

But what do I know? I’m just an Old Dude Who Knows Smalltalk (and Lisp).

EclipseCon 2015

Posted in Other | Tagged , , | Leave a comment

A Vision of the Future of the Software Developer’s Platform

How will the developer’s platform change over the next three years? Will you still be using desktop-based development tools? Cloud-based software development options are getting more powerful, but will they completely replace the desktop? For a certain set of developers, cloud-based software development tools will be a natural fit and so we should expect migration to tools like Che. But the desktop will remain viable and vibrant well into the future: for many classes of problem, the desktop is the right solution.

Of course, there will be grey areas. Some problems can be addressed equally well by desktop- and cloud-based solutions. For these sorts of problems, the choice of development tools may be–at least in part–a matter of developer preference. There will be other drivers, of course (the exact nature of which is difficult to speculate). For this grey area, the ability for a software developer to pick and choose the tools that are most appropriate for the job is important. Further, the ability to mix and match development tool choices across a team will be a key factor.

I’ve spent a good part of the last few months working with a group of Eclipse developers to hammer out a vision for the future of the developer’s platform. Here’s what we came up with:

Our vision is to build leading desktop and cloud-based development solutions, but more importantly to offer a seamless development experience across them. Our goal is to ensure that developers will have the ability to build, deploy, and manage their assets using the device, location and platform best suited for the job at hand. Eclipse projects, the community, and ecosystem will all continue to invest in and grow desktop Eclipse. Full-function cloud-based developer tools delivered in the browser will emerge and revolutionize software development.

Continued focus on quality and performance, out-of-the-box experience, Java 9, and first class Maven, Gradle, and JVM Languages support also figure prominently in our vision of a powerful developer’s platform.

To paraphrase:

  • Desktop Eclipse will remain dominant for the foreseeable future;
  • Cloud-based developer environments like Che and Orion will revolutionize software development;
  • Developers will be able to choose the most appropriate tools and environment;
  • Projects can move from desktop to cloud and back;
  • Desktop Eclipse developer tools will gain momentum;
  • The community will continue to invest in desktop Eclipse-based IDEs;
  • Java™ 9 will be supported;
  • Developer environments will have great support for Maven and Gradle;
  • Support for JVM languages will continue to improve; and
  • User experience will become a primary focus

You’ve likely noticed that this is focused pretty extensively on Java development. This is not intended to exclude support for other programming languages, tools, and projects. As the expression goes, “a rising tide lifts all boats”: as we make improvements and shift focus to make Java development better, those improvements will have a cascading effect on everybody else.

My plan for the near future (Mars time-frame) is to get the Che project boot-strapped and latch onto the that last bullet with regard to the desktop IDE: user experience. While user experience is an important consideration for most Eclipse projects, it needs to be a top focus.

This vision of the future isn’t going to just happen. To succeed, we need organizations and individuals to step up and contribute. I’m aware that project teams are stretched pretty thin right now and many of the things on the list will require some big effort to make happen. Our strategy, then, is to start small.

I’m buoyed (in keeping with my sea metaphors) by the overwhelmingly positive response that we got when we turned line numbers on by default in some of the packages. I’ll admit that I don’t quite understand the excitement (it’s such an easy thing to toggle), but for many of our users, this was a very big and important change. The curious thing is that–while the change was preceded by a lengthy and time-consuming discussion–making the actual change was relatively simple.

My take away is that we can have some pretty big wins by doing some relatively small things. With this in mind, I’ve been poking at an informal programme that I’ve been calling “Every Detail Matters” (I borrowed this name from the Gnome community). Every Detail Matters will initially tackle things like names and labels, default settings for preferences, documentation, and the website/download experience (I’ve set up an Every Detail Matters for Mars umbrella bug to capture the issues that I believe make up the success criteria).

We’re also trying to tackle some relatively big things. The “installer problem” is one that I’m hopeful we’ll be able to address with via the Oomph project. I’m also pretty excited by the prospect of having Eclipse release bits available from the Fedora software repository on GA day.

In parallel, we’ve launched a more formal Great Fixes for Mars competition with prizes for winning contributors of fixes that improve the Java development experience.

Enter the Great Fixes for Mars skills competition; there'll be prizes!

Enter the Great Fixes for Mars skills competition; there’ll be prizes!

I’ll set up a BoF session at EclipseCon to discuss the vision and our strategy for making it real. It’d be great to see you there!

EclipseCon 2015

I wrote about the Platform Vision in the November Eclipse newsletter.

Posted in Community, Java | Tagged , , | Leave a comment

Great Fixes for Mars

We’re launching the “Great Fixes for Mars” programme. As is suggested by the name, we’re looking for great fixes in the form of contributions to Eclipse open source projects. There will be prizes.

EclipseCon 2015

A “Great Fix” is a contribution from a non-committer  that provides a significant improvement in the Java development experience using Eclipse. Ultimately, the committers will decide what constitutes a “Great Fix”, but special consideration will be given to performance or stability improvements, and patches that improve the user experience.

Now this is important: to qualify, a “Great Fix” must be a fix, not a new feature or enhancement. And, we’re particular about the nature of the fix: it must improve the Java development experience. I’ve asked committers from the Java development tools (JDT) project to suggest some bugs that they’re particularly keen to have addressed to seed the discussion. You can, of course, pick other bugs, but the suggested ones are most likely to result in success. We’ll be including other Java development related projects in this as well.

The first 100 bugs on the Eclipse Platform 4.5 Planning Bugs page are a great place to start. The Platform UI project provides a very comprehensive How to Contribute guide to get you started. I recommend that you use the Oomph Eclipse Installer to build and configure your complete development environment (Oomph provides a very intuitive workflow for provisioning an Eclipse-based development environment, complete with cloned Git repositories, that gets you ready to contribute patches via Gerrit in minutes; I’ll post a demonstration video later).

I mean no disrespect to the beginners out there, but this is also important: a “Great Fix” must be fixed by the contributor on their own qualifications. If your starting point is “I want to fix a bug, but don’t know much about the code; please explain how I should start”, then—respectfully—this programme isn’t for you. We’re looking specifically for “Great Fixes” that don’t take a lot of time for the committers to assess and accept (committer effort is part of the judging criteria).

The programme runs in cycles; submissions must be accepted by a project committer before 900h ET on the specified deadline date. We’ll announce the winners at the end of each cycle.

  1. Deadline: March 10/2015; the three top-prize winners will be announced on March 12 at EclipseCon
  2. Deadline: April 1/2015; the three top-prize winners will be announced on April 3 (Mars M6)
  3. Deadline: May 6/2015; the four top-prize winners will be announced on May 8 (Mars M7)

To qualify:

  1. Pick a bug;
  2. Take ownership of a bug (i.e. assign the bug to yourself);
  3. Add the “greatfix” keyword to that bug and use a comment to commit to a completion date; and
  4. Submit a patch via the preferred channel (likely Gerrit).

If a committer thinks that your fix has potential, they’ll +1 your comment in the bug. The +1 means that the committer is interested and will plan to review your contribution when it you submit it. I can’t guarantee that a committer will accept your fix, but if they do and it qualifies, you’ll be in the running for a prize.

Full details are on the web site. I’ll update that page periodically with more “seed” bugs and status.

To answer what I expect is an obvious question: you can qualify for this if you are already a committer on a different Eclipse open source project. In fact, I’d love for you to participate if you’re a committer on another Eclipse open source project.

So, what are the prizes? We have some state-of-the-art Nexus 9 Android tablets compliments of the good people at Google.

Nexus 9 Android Tablets

We’re picking multiple winners in each cycle. Runners up will get an awesome Eclipse t-shirt.

The EclipseCon Hackathon is a good place to get a leg up on the competition!

Posted in Community, Java | Tagged , , , | Leave a comment

Committer Bootcamp at EclipseCon 2015

Are you a new committer or project lead for an Eclipse, LocationTech, or PolarSys project? Are you thinking about proposing a new open source project? In this tutorial, Eclipse Foundation staff members will walk you through the information that you need to know to be an effective open source project committer. The discussion includes an overview of the Eclipse Development Process, the Intellectual Property Due Diligence Process, and the Tools and IT Infrastructure made available to open projects by the Eclipse Foundation.

We’ll be running the Eclipse Committer  Bootcamp at EclipseCon 2015. We’ve scheduled it on Sunday, to avoid conflicting with the fantastic tutorials that are running on Monday. The fun starts at 3 pm (PST); we normally run for about three hours, and–having learned valuable lessons from the past–include plenty of breaks and time for questions. You don’t have to prepare anything; we’ll take care of that.

There will be prizes.

There is some additional information, along with the presentation materials from past offerings of the Bootcamp in the wiki.

If you plan to attend, please send a quick to to to state your intent (so that we can have some sense for the number of committers we should expect).

I’m understand if you can’t make it to the Bootcamp. But you really do need to come to EclipseCon: it’s a fantastic way to connect with the community,  network, and learn.

EclipseCon 2015

Posted in Uncategorized | Leave a comment

What are you doing with Eclipse right now?

I recently attended a conference session on the topic of getting user feedback. One of the key takeaways for me was that people lie about how they use software. It’s not that they’re trying to be misleading, it’s more that it’s easy to misrepresent yourself out of context. The speaker suggested that you need to interrupt your users and find out what they’re doing at the moment. And you need to do this in regular intervals.

With such a large, diverse, and distributed community–combined with no actual budget–that’s going to be hard to do in any traditional sense.

So I tried a quick experiment on Twitter this morning, asking folks to stop what they’re doing and tell me which views they have on top in their currently-running Eclipse.

I’ve received six responses so far; seven if I count my own (with an audience this engaged, I’m thinking that it might be time to get verified).

  1. Package Explorer, History, and Console
  2. Package Explorer, and Git Staging
  3. Package Explorer, and Search
  4. Package Explorer, History, and Task List
  5. Package Explorer, Task List, Console, and Outline
  6. Package Explorer, Outline, and Console
  7. Package Explorer, Task List, and History

Clearly (and as expected), the Package Explorer get top billing. The Mylyn Task List shows up a lot which is encouraging. That almost half of the responds include the History view is a bit of a surprise (at least to me).

There’s not enough information here to make any real conclusions, but I think the method shows some promise. Let’s see what my next question brings…

Nothing so far…

Posted in Community | 2 Comments

Some “So Far” Stats for Eclipse Luna

I’m working out some of the queries that I’m going run to gather some stats for the Eclipse Luna release on June 25/2014. I’m starting with the Git repositories.

The Git query is relatively simple, taking all commits that have occurred since the Kepler release on all branches into consideration. So the numbers I’m getting do include commits that are not necessarily intended for Luna (e.g. it includes Kepler service release commits).

Here’s what I have so far:

Number of projects: 106

The Luna projects page only lists 71 projects. Many of these projects include subprojects with their release (the Eclipse project includes Platform, JDT, PDE, and others for example). The actual total is 117 projects and subprojects. Of those projects, only 106 actually have code (the Eclipse top-level project, for example, doesn’t have any of its own Git repositories; all contributions from the Eclipse project come from subprojects).

Confusing? Sure.

Number of Git repositories: 188

Many projects have more than one Git repository. There’s a total of 188 Git repositories contribution commits to Luna.

Number of commits: 39,391

This number speaks for itself. For perspective, that’s an average of 108 commits/day.

Number of authors: 687

This is the only fuzzy number in this list. It’s actually the number of distinct author email addresses (as specified in the author field in each Git commit). Some authors may use multiple email addresses, so the actual number of authors is probably smaller than this; but probably not much smaller.

Number of committers: 339

Of those authors email addresses, 339 of them map to committers. For completeness, this is the number of committers authoring commits to their own projects. It does not include contributions to projects by committers on other projects. So, of the 687-339=348 remaining contributors, some of them are committers on other Eclipse projects.

Lines added: 54,760,022
Lines removed: 44,302,716

I’m not sure how valuable either of these numbers is in isolation. Combined, it looks like we have net new 10,457,306 lines of code.

I’m pretty confident in the query behind these numbers, but they’re not “official” (whatever that means). I’ll likely refine the query over the next few weeks. And, of course, these numbers a current as of today. I’ll publish some more up-to-date numbers when the final release candidate is ready for download.

If you have any questions, refinements, or want to see some different numbers, let me know.

Posted in Community | 1 Comment

More names for Eclipse

I regularly receive requests for quotes from purchasing agents for Eclipse software. In almost every case, they’re looking for an Eclipse-based IDE, but don’t quite know what to call it.

Today’s gems are:

  • Eclipse CDT Juno
  • Eclipse Eclipse 352
  • Eclipse Eclipse JSEE Juno
  • Eclipse software Version: Indigo Release
  • Eclipse Java EE IDE for Web Developers

Based on the quantities requested for each of the above, we can count a couple of hundred new users to the Eclipse family.

I find it curious that resellers and purchasing agents can take the time to hunt through our website to find my email address, but apparently don’t bother to look for the names of actual software available from our site. They are presumably responding to a request to obtain software from development managers who also don’t really know what they’re asking for or understand the nature of open source software.

In most cases, I only get to connect with the purchasing agent with no direct connection to the people who end up using the software. I reply with a friendly note explaining the nature of open source software, tell them about the Eclipse Software User Agreement, and give them a link to the downloads. I can only hope that the information is passed on.

Posted in Other | Leave a comment