it's only been 3 years. other eclipse bugs that I reported are are still open after 9 years. https://bugs.eclipse.org/bugs/show_bug.cgi?id=76646 https://bugs.eclipse.org/bugs/show_bug.cgi?id=114003 Sad to say, but Eclipse smells a kind of dead.
Of course, those of us who work in the Eclipse community know that isn't true, but it certain isn't as alive as it was in the early years. Even from my experience on the CDT, we have a small handful of dedicated and productive committers, but we do have lots of bugs that don't get addressed.
Building an IDE, especially one that supports so many environments, requires a lot more contributors that we currently have. It's an age old problem that I've struggled with for all my years involved in Eclipse and many of those as a project lead. How do you grow your contributor community?
And there are some good answers that generally revolve around lowering the barrier to entry: having active mailing lists, good documentation, committers that help bring in new people. And these things definitely help when you have a contributor interested in contributing.
But let's back up a step, assuming you do those things, how do you get potential contributors interested in contributing? You have to make your project something they care about, something that they will feel rewarded contribute to. For the people who contribute to Eclipse now, that's certainly a strong motivator. And, of course, it's important to get companies to see the value in it too, and that's of course another strong motivator, you're boss tells you to contribute :).
To that end, I think we need to figure out ways to make the Eclipse IDE exciting again, to be so alive that it's hard to miss that fact as our commenter did. I think there are a couple of ways to do that. First, make it technologically interesting and modern. Make it a good learning experience that contributors can take with them so they not only get the value of having a great IDE but the value of adding knowledge to their tool chest.
Of course it's a chicken and egg problem, we can't do these things without new contributors, but we should start talking about and planning out features and rearchitecture they'd like to see. And, yes, e4 was supposed to be that, and maybe I'm getting this wrong, but e4 was more focused on adopters than users. And it's really the users who I'd like to see get more involved. There's so many more of them. And they're the ones who really have a vested interested in making a great IDE.
The second idea that I've started pursuing is to have Eclipse release more often. We've decided this for the CDT. Yearly releases are way too far apart, especially when you want to inject innovation into our product. If you release more often, contributors get the reward of seeing their contributions in action sooner. And again, it's that reward that we want to give them. At any rate, you can follow the thread here. It's good to see like minded people in our community leadership think the same way.
We know first hand that Eclipse is not dead. But it could sure use some love.
I have been a big proponent of doing shorter releases. 3 months is ideal, you get to concentrate on a smaller set of changes and functionality. A year long development cycle people tend to push things until the end. Compact it and make the releases more often and there is a rhythm that can start to develop. Projects already do monthly milestones, why not 2 week milestones with a 3 month development cycle.
ReplyDeleteInteresting post. Maybe even worst than bugzillas that get no answer are general complaints about Eclipse/Projects that never were raised as issues. That's why this Website, as painfull as it is, provides very interesting feedback http://www.ihateeclipse.com/
ReplyDeleteWe may have to think about a better way for end-user to raise such "feelings" (maybe an amazon-like rating system which would allow to very quickly rate from 0 to 5 stars a feature or a project).
@Alex Wow, never seen that site before. But what a great way to get honest feedback.
ReplyDelete@Dave We're going to try 6 months for CDT. Depends on the size of work going on I guess. For something as big as Eclipse, we need to make sure we have solid ramp downs.
Any non-trivial project will have to set priorities, which means not putting energy into bugs with a low priority. Which in turn can lead to a project looking dead when only looking at those bugs. So that's normal I guess. I've had both positive and negative experiences in regard to Eclipse bug reporting, mostly positive though.
ReplyDeleteHowever, one thing that is increasingly worrying me, and testing my resolve to go ahead with basing an application on Eclipse RCP/AP is the fact that the platform itself, while surely not dead, is accumulating smell. Contributing to the platform itself seems rather boring. For many it's a means to an end - people which build applications based on Eclipse. I find myself in this group - I'd love to take a stab at checking out and coding on the platform code, but I need that time for my project - I just want to use the platform. I can imagine a lot of people being in that position. Looking at the bugs that are still open on the plan for the now-released 4.3 version (http://wiki.eclipse.org/Platform_UI/Plan/4.3), I can see why my error log fills up during the day. I don't currently see (though I am definitely not up-to-date on this) new people coming in to code on the platform. And with the above, I don't see that happening. What I (as somehow with only a shallow graps of the Eclipse foundations' workings) wonder is: why aren't the resources, the member companies, used to hire people to be paid to work on the platform (not an Eclipse platform, but the core platform), to fix (amongst other things) the bugs that are too unattractive for voluntary contributors to fix, but need fixing anyway. Like I said, I don't know much about how the foundation works, but the current way to bring Eclipse forward is ... lacking IMHO. I do know however, that I would be willing to support such an effort financially - I don' have the time to code on the platform itself, but I'd pay to enable someone else do to it, may that be through (recurring) donations, I dunno ... surely someone else must be bothered by this and looking for a solution, or is my view on this entirely detached from reality?
+1 for donations to do unexciting fixings...
DeleteThat would give make Eclipse a boost and a more serious demeanor.
A user survey would be a great way to get the community engaged -- ask them when they like, what they dislike and what they'd like to see.
ReplyDeleteBut the survey would only be valuable if some commitment was made to act upon the collected feedback.
Perhaps projects could commit to resolving the top 1 or two issues per release, then repeat the survey the following year. May not seem like much, but if the community sees that their top items are being addressed, they will feel empowered.
@straightfrommars You raise a very point, and this is something many of us have talked about for a very long time, i.e., some sort of way of funding a core team of developers. And the Foundation is very aware of our thoughts and don't disagree. But I'll let them comment further.
ReplyDeleteAs a company that builds on the awesome framework that Eclipse provides ... if you need it and it is broken then the onus is on you to fix it and make it happen.
ReplyDeleteAs far as I'm concerned the "platform" has matured to a point where we don't need to see it changing every day. Some people may see this as a rotten smell, but I see this as a stable point in a software product's lifecycle. That isn't to say that there aren't bugs to be fixed or features to be added, but the motivation behind that work has to come from people who are using the platform.
You get out of it what you put into it. I have very little patience for people who want to leverage a significant technical body without addressing shortcomings that they find in it for their particular use cases.
Thomas
Hey Thomas! :)
DeleteI guess my feeling is that Eclipse has matured like Cobol has, in a state where it's not very exciting. And yeah, that's probably a huge exaggeration. But to consider it stable while it's competition continues to evolve to meet the expectations of the new generation of developers who game and used to mobile experiences pretty much puts a nail in it's coffin.
The frameworks are great, but the user experience is not. And we need to re-energize to fix that.
I really like the vision of Kohsuke Kawaguchi (jenkins lead developper) on this topic:
ReplyDeletehttp://de.slideshare.net/kohsuke/building-developer-community
Hi, I posted that comment.
ReplyDeleteFirst of all, I am glad I got your attention. I think this is the best I could have hoped for making that comment.
I know Eclipse is not really dead. This was a more general rant about Eclipse losing momentum, personally I am stuck with an old version of CDT at work because last I tried to use it to build a fairly complicated project (about a year ago maybe things are better now) - there were a lot of indexer problems (getting bogus errors because the new indexer has bugs), and because I need to use an old version of CDT, I keep an old version of Eclipse to go with it (3.6 iirc).
Another sense of staleness is that Eclipse comes with CVS out of the box, but not SVN when it was popular and not Git now that it is popular.
I know there are plugins, but why should a user need to do a research about which plugin will be the right plugin to use the most popular and wildly used version control?
Another problem is lack of built in support for Maven. as much as I hate Maven - it's a very popular tool in a massive number of Java projects.
There are also some deeper problems like the fact that Eclipse project layout is flat - a decision that is probably too late to fix now as there is a massive code-base that assumes that is the case.
Another is the long problem of Eclipse bitching about files changing in the file system. for the life of me I can't understand why Eclipse need to stop everything it's doing and throw an Exception which will be translated to a dialog box the user sees and ask him to refresh the project. this is just a poor product decision in my opinion.
I have been using Eclipse version 2 (I remember switching to it from JBuilder 4), so I definitely got a long perspective of it.
in the old days, each new release came with great improvements and I was always happy to try it out.
at some point, this stopped being the case.
the longer release cycles are definitely a problem here, but I think also lack of exciting new improvements.
in a way I understand the resistance to support any external tool and just say that's what plugins are for, but I am betting anything that if Eclipse officially supported Git that will make a much bigger difference and create a much better adoption of the version than any minor improvements to quick assist.
> there were a lot of indexer problems (getting bogus errors because the new indexer has bugs)
DeleteI assume you're talking about Codan (Code Analysis). You can disable that in Preferences > C/C++ > Code Analysis > Syntax and Semantic errors. The old indexer had bugs too but didn't show them as obviously. I'd prefer this analysis to be disabled by default but some don't agree.
For nested projects, you should add your vote to https://bugs.eclipse.org/bugs/show_bug.cgi?id=245412
Delete> is that Eclipse comes with CVS out of the box, but not SVN when it was popular and not Git now that it is popular.
ReplyDeleteVarious Eclipse packages (including "Standard") come with Git, see here: http://www.eclipse.org/downloads/
> Another problem is lack of built in support for Maven. as much as I hate Maven - it's a very popular tool in a massive number of Java projects.
See link above, Maven integration is included in the "Eclipse IDE for Java Developers" package.
> There are also some deeper problems like the fact that Eclipse project layout is flat - a decision that is probably too late to fix now as there is a massive code-base that assumes that is the case.
Nested projects are supported, see here for a screenshot showing that: http://wiki.eclipse.org/EGit/New_and_Noteworthy/2.2#Resource_filter_and_nested_project_support
> Another is the long problem of Eclipse bitching about files changing in the file system. for the life of me I can't understand why Eclipse need to stop everything it's doing and throw an Exception which will be translated to a dialog box the user sees and ask him to refresh the project. this is just a poor product decision in my opinion.
Go to preferences > General > Workspace and select the "Refresh ..." options there. IMO these should be on by default, but the platform is kind of conservative about defaults (sadly).
Robin, thanks for the comments.
ReplyDeleteIf nested projects are supported, why can't I create a new project inside an existing one?
also, last item here:
http://wiki.eclipse.org/Top_Ten_Architectural_Problems_in_all_of_Eclipse
About Git, good to know. that's a reason to upgrade. sadly I am stuck with 3.6 for CDT as I said.
About Maven:
funny, I just downloaded the standard version - which historically was the version I always got because it had all the basic java stuff and not the EE related which I didn't care about) and it does not have it.
strangely the java developer edition is smaller, Yet has it. good to hear mainstream tools are getting into the standard package. it sure did take a long time for this to happen.
I recently discovered the auto refresh option, I agree that it should be the default. this have been one of the longest usability issues with Eclispe and it's not clear to me what took so long and why it's not the default.
@Omry:
Delete> If nested projects are supported, why can't I create a new project inside an existing one?
Works here with Eclipse 4.3 and the wizard for a general project. You have to deselect "Use default location" and then choose the folder where the .project file should be (so if you want to create project "foo", it should be /path/to/foo, not just /path/to).
Okay, got it to work.
DeleteThis is a step in the right direction, but there are a few problems with this I see at first glance:
1. display wise projects still seems flat, which defeats the purpose of nested projects.
2. you can't create a project inside a without having to deselect the default location option, and then browse through the file system. if this feature was a first party citizen, you would be able to right click on a project, and use the new project wizard to create a project in it without going through all those hoops.
was this implemented purely to support Maven nested projects, it looks like this is an infrastructure feature that is actively being hidden from the UI.
ReplyDeleteHere are my 2 cents.
Having shorter release cycle seem to be a great idea! Still the version schedule that you posted here (http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09238.html) is giving me a bit of wonder - it seems to me that nobody will be interested in developing SR-2 for the previous version in February. So I really hope the whole Eclipse project could switch to shorter release cycle.
@straightfrommars - I completely agree with you. It was really strange to read the heads of the Eclipse project complaining on the platform team losing people. It does not feel worthwhile to work on side-projects of platform if you see that the core project is kinda abandoned..
What I think myself, is that Eclipse as an IDE is really losing it's momentum, which makes me sad. For example, since C# appeared in 2000, there's still no Eclipse project for it, only two plugins that were long time dead, last time I checked. And on the other hand people are willing to create SharpDevelop/MonoDevelop from scratch! Why is it more convenient for people to start things from scratch and spend time on re-inventing things that Eclipse could provide at instant? I'd appreciate if the MonoDevelop was built on the Eclipse platform, so I could use all the vast functionality of it, but instead I have to use MonoDevelop (which is really amateurish as an IDE) just because there's no alternative.
Regarding CDT itself, I think the main problem is the lack of documentation. Really! Some time ago I was thinking on writing a debugger integration for the CDT. It would have saved me a lot of nerves if I was able to debug embedded code from Eclipse instead of using the provided debugger UI (hardly usable at all), so I was willing to spend time on this. But I never managed to do this as I could not figure out where should I start! CDT has a lot of crypto-abbreviated technologies related to interfacing with debuggers, but it is never clear which and how to use. And I'm not the only one, if you check the mailing list, there are recent questions on the same matter - how to integrate a debugger?
I believe that making this matter clear an straightforward would increase the popularity of the CDT tenfolds! As I'm working with embedded platforms, it always makes me wonder why the manufacturers decide to create own debugger applications from scratch instead of using the great functionality of Eclipse/CDT as an IDE? Maybe if it would be clear on how to integrate with CDT debugging functionality, there would be less re-invented wheels and more popularity for Eclipse/CDT?
Eclipse was in a vacuum for some time, well isolated from competition like the high-and-mighty Visual Studio or the cute-and-tiny CodeBlocks. And then NetBeans started to show some progress and promise, but nowadays it seems that the JetBrains folks are doing the best user-experience wise.
ReplyDeleteAnd to illustrate that, people starting with Eclipse 4.3 (Kepler) as of 2013 on Windows 7, Java 7 and all the improvements on localization and internationalization behind them, it still seems to be lacking an option to distinguish AltGr from Ctrl+Alt, and the proposed solution is to switch to a different keyboard layout, or delete the offending [and useful] key bindings.
Hello Doug. It's an interesting post you have here.
ReplyDeleteI wanna divide my reply in two parts.
First, like many others here, I do agree that Eclipse is losing a lot of momentum, even regressing in some aspects (more on than later). But I don't agree with your vision of what Eclipse should look forward to be. I've been following your Twitter and blog posts for quite some time, and I see this recurring pattern: the desire to make Eclipse more exciting, but exciting not necessarily in a functional and technical sense, but more in a visual way: by means of making it more "cool" or "hip". You often draw comparisons to the all the new "sexy" and cool games, mobile apps, and "Web 2.0" websites and technologies we see out there.
Again, I respectuflly disagree with this vision. Eclipse is a tool a for developers, as its goal should be first and foremost to be as productive, easy and functional to use as it can be. Cool and interesting, but in matter of *substance*, not style. (PS: I'm quite the gamer, but it doesn't change my opinion. Eclipse is not a game.)
Now, second, regarding the main subject: Is Eclipse, as an IDE, losing momentum? It sure feels that way! And not just because it is a large and accomplished project that achieved a lot already... if it was just that case it would be okay to lose momentum in a sense, but it seems that the quality of Eclipse has actually been regressing (and a lot of opportunities have been missed). Let me be more concrete about what I mean here.
ReplyDeleteI am an user of the Eclipse IDE in two ways. Both as a user of the JDT IDE, to developer Java, but also I am user/consumer of the Eclipse IDE API, as I develop plug-ins for Eclipse. (I worked on Eclipse RCP apps, but more significantly I head the developer of an Eclipse based IDE for the D programming language: DDT)
As a user of JDT, and the Eclipse IDE in general, let me tell about my experiences. I've always loved Eclipse, but when I started trying out the 4.x series, I felt a bit disappointed. The new themes looked horrible, to be honest. Not just in a subjective sense, but there was several visual/rendering bugs as well. This was the 4.1 release if I recall correctly. I decided to stick with 3.x as long it was the main Eclipse release. Then 4.2 came, and Eclipse 4 became the main version. I decided to switch finally. After several months of use I noticed it was way buggier than the 3.x series. A few JDT bugs, but most where Platform bugs (views getting lost, icon/action sets getting lost or misplaced to wrong places, view setting not getting saved/persistend, workbench broken with views/editors getting partial focus - they would receive the normal keystrokes, but command shortcuts would be sent to a different view/editor! This last one drove me nuts, as it happened quite frequently, and after the workbench was broken like this I had to restart Eclipse to fix it).
The frequency and severity of these bugs, for very common tasks, left me with a bad taste in my mouth. This was compounded by the fact that this was the 4.2 release, ie, there had been two previous releases of the 4.x series already! I know that Eclipse 4 involved a major rewrite of Platform internals, but two releases should have been more than enough to wring out nearly all of these major issues.
This (combined with news like IBM not investing as much in Eclipse as it used to) gave me the impression that the technical excellence of the core components of Eclipse was not as good as before.
Other news do not looked favorably on this either, such as the recent one about ADT moving over to IDEA... Guys that should have been a major wake up call!
=I had to split the previous comment as well=
ReplyDeleteAs a user of the Platform and IDE API to develop new plugins, I also think a few opportunities are being missed. I was in love with Eclipse since the early days of 3.x, and by then, it was on of the best options to develop IDEs for other languages. I was involved with this area since 2008, which was when I first started working with Eclipse to develop an IDE for the D language. But this area appears to have stagnated ever since, despite the fact that a lot of improvements and technology could be developed. Whereas a fair amount of innovation has happened for developers of RCP applications, what new developments have occured that make it easier or more powerful to write new IDEs in Eclipse?
None really, with the exception of Xtext, and the DLTK (Dynamic Language Toolkit) project. There was also another project similar in scope to DLTK, IMP, but it pretty much seems to have died. Xtext has been quite interesting and looks fairly mature, but I would argue that it is not that adequate for more complex, general purpose programming languages.
DLTK is actually a great idea for a project, and very useful. And indeed target for programming languages. The way it's done, at least with most of it's codebase, is that it copies a lot (really, a lot) of JDT code, and adapts it to be usable to other languages. Code such as JDT's project model, indexing functionality, compiler/interpreters setup, source editor, and lots UI boilerplate code. So for example, DLTK IDE projects usually have a project layout and view similar to JDT: with source folders, hierarchical packages, source modules, model elements nested within, etc.. The D IDE I work on is actually based on DLTK as well, even though D is not a dynamic language at all. It just happens that a lot of DLTK functionality is useful for non-dynamic languages as well.
The problem here is that DLTK is quite rough on the edges, both in terms of functional limitations, API limitations, bugs, and brittle documentation. That's not surprising, it is a massive undertaking, and it doesn't have that much manpower allocated to it, from what I understand. It has been improving steadily, which is good at least, but at a slow rate.
Now, the point to take from the comment above, is that there is a huge missed opportunity here. You see, I understand that it's not reasonable to expect a faster rate of progress with a project like DLTK, since it's mostly developed by people from one or two smaller companies with their own specific commercial interests, goals, and resource limitations. The thing is, why couldn't the JDT team work toghether with DLTK? Why couldn't all (or some) of those components of JDT be adapted for more general IDE use, by the JDT team itself? It's likely a major undertaking still, but it certainly would have been more effective than having a third party team adapt JDT for general purpose use, in hindsight (and the gains could have come much sooner). There are also a lot of problems with code duplication here. How bad these will be in practice, will depend, I guess, on how often the affect JDT code based changes in the future.
As a participant in the D community, I've also been taking a look at developments of D IDEs in other platforms. There are two quite significant D IDE projects based on Visual Studio and MonoDevelop. People have toyed a bit with Netbeans and IntelliJ IDEA, but nothing signicant has come of it so far. I was quite surprised with the MonoDevelop one though: both the base platform, and the D IDE for it are quite full featured. And this is for a platform (MonoDevelop) that is a quite recent newcomer in the scene.
Guys, the way I see, Eclipse feels like Subversion. It's fairly good and useful, and it's much better than CVS (which could be say, Visual Studio or CodeBlocks or something). But one day, a team with superior technical excellence could well create the equivalent of Git for an IDE platform, and it will just blow away Eclipse completely, in a heartbeat... :/
Great points Bruno and I can't agree more. Making Eclipse cool was really an effort to get people looking at Eclipse again. But you are right, what we're missing most is making the Eclipse IDE a great product with high quality and with all the features users expect from a great IDE.
DeleteLanguage support is a big problem there. Even our JavaScript support through JSDT is severely lacking. That's why I'm now hoping to rally the troops around the IDE so we can take a look across the whole IDE and make sure we're at the same quality and feature levels for all languages we support. I'll put a post together on that shortly.
BTW, this is such a great comment, would you mind if I made an new post from it as well? I'd like to get more visibility to it. This is the kind of thing I'd love to see everyone in the Eclipse IDE community be thinking about.
No, I wouldn't mind at all, quite the contrary. My hope was to give more visibility to these issues as well.
DeleteBug (GMF/GEF)
ReplyDeleteI reported some time ago bug in GMF / GEF, and talking to the leaders, not getting any favorable result ...