Several years ago, while I was still working for a bank and writing Java code in Eclipse, I found myself wanting split-screen editing in Eclipse. I found the relevant improvement request: Bug 8009 in the Eclipse issue tracker, and added myself as a CC.
For over three years now, I’ve been getting updates on patches to partially fix the problem, plugins people have developed to work around it, and watching many other people being added as CCs. There have been over a hundred comments on the bug, many of them from people wondering how such basic functionality can go unimplemented for so long.
The reason for this is simple. The feature is hard to implement, and noone in the Eclipse community thinks it is important enough to spend their free time implementing it, testing it, and getting into the main release. I don’t blame them. I’d rather spend my spare time doing something else too.
To the 180+ fans of this bug-
If you still have not given up on Eclipse out of frustration for the lack of split editing, there is still hope!
I am working on fixing this bug as part of Google Summer of Code.
The first, VERY early prototype of a split editor is available for download. Check out either the blog or the wiki for a link and instructions.
And this is benefit #35 of open source software: features can be requested and left unimplemented for a very long time. Once someone is interested in implementing it, all the patches, plugins and requests from interested people are archived ready for the implementer to pick up.
You can some of the same benefits in commercial projects by having a public issue tracker. Of course, it’s not possible for anyone to actually resolve the problem or implement the feature, but you do get the benefits of having all discussion about a particular issue archived in a single location. If customers have the source code of your software, they can provide patches that might partially solve the problem.
This benefit is what we see at Atlassian with our public issue tracker. It definitely far outweighs the drawbacks of people being able to see a list of problems in your software and how long you have left a particular feature unimplemented. In fact, we tend to think that is a good thing too — customers should be able to see the defects and missing features before they purchase the software, not after.