Today marks the release of Eclipse Indigo, the combined set of 62 projects and 46 million lines of code. I've written up the details at InfoQ so I won't bother going into them again here.
What is worth taking away, though, is not just the fact that Eclipse is a successful Foundation (which it is), or the fact that Eclipse projects generally make great software (which they do), but the fact that co-ordination in open source projects is not only possible, but it's also predictable.
The Releases on Wikipedia lists Eclipse releases by the Eclipse Foundation, which was created back in 2004, but in fact the Eclipse project goes back to a public release in November 2001. Before then, Eclipse was the embryonic foundation of WebSphere Studio, an HTML editor for WebSphere's servlet engine (at the time, called just WebSphere) to complement Visual Age for Java's IDE.
Since VAJ wasn't sensibly able to handle non-Java files, WebSphere Studio grew out of a desire to have first plain HTML, then later mixed HTML, JSP and Servlet content. VAJ didn't have a large following at the time (though, like Visual Age for Smalltalk users, it did have its loyal userbase). At the time, products like Symantic Café and Borland's JBuilder had larger followings, in part due to VAJ's organisation at the logical (class/method) instead of physical (file), and in part due to other products being cheaper.
Eclipse today still has the “Java Browsing” perspective, modelled on VAJ's logical view of the world; it is telling that most Eclipse users automatically use the “Java” perspective, which provides a tree-view onto the physical representation and thus needs tools like Mylyn to reduce the clutter. Perhaps this predisposition comes from the fact that Windows and Linux file managers often only have a tree-based view of the world, whereas other operating systems like Nextstep and OSX have column views which can show more information in a more condensed way.
NetBeans was open-sourced in 2000, and IntelliJ was released in early 2001. Eclipse 1.0 was released in November 2001, making it the newcomer in the IDE scene. At the time, it was buggy (and had a tendency to not notice when files were changed outside of the IDE, requiring manual refreshes in order to open them) but none the less, its approach to modular extension was ahead of IntelliJ (which wouldn't be open-sourced until much later) and really kick-started the thoughts of modular software development. Eclipse 2.0 followed seven months later in June 2002.
Since then, the Eclipse project – and later, the simultaneous releases which congregate around it – have followed a yearly release pattern. Whilst 2.1 was released in March (in time for EclipseCon), all the other releases have been in June and have kept to a fixed schedule, including milestone builds and release candidates (often with an M5a or M6a for good measure). Eclipse releases have been clockwork:
- Eclipse 1.0 – 7 November 2001 (Win32/Linux32 Motif)
- Eclipse 2.0 – 27 June 2002 (Linux32 Motif + GTK, and Solaris/QNX/AIX)
- Eclipse 2.1 – 27 March 2003 (OSX first version)
- Eclipse 3.0 – 25 June 2004 (first OSGi version)
- Eclipse 3.1 – 27 June 2005
- Eclipse 3.2 – 29 June 2006 (Callisto)
- Eclipse 3.3 – 25 June 2007 (Europa)
- Eclipse 3.4 – 17 June 2008 (Ganymede)
- Eclipse 3.5 – 11 June 2009 (Galileo)
- Eclipse 3.6 – 8 June 2010 (Helios)
- Eclipse 3.7 – 22 June 2011 (Indigo)
Whilst we're not quite at the 10 year anniversary of Eclipse (which will be in November this year), the fact is that over the last ten years we have had one release per year, and that since Eclipse 3.0 – when the Eclipse runtime transitioned to OSGi – that release has been predictable in mid to late June, often known about a year in advance. We'll probably be having the same conversation on the 20th June 2012.
Incidentally, the switch to OSGi back in 2004 is worth calling out. A brilliant decision, often not understood or liked at the time, OSGi has come to be a bedrock of not just Eclipse but many other servers and systems in the years since. The wider use of the OSGi service model has been percolating ever since, leading to tools like E4 and a gradual drift away from the Eclipse registry. Not only that, it has made OSGi popular as a standalone technology, with developers moving on from just building Eclipse plugins to designing fully-fledged OSGi systems. At least one of the lasting legacies of the Eclipse platform has been the certification that OSGi is a trusted module system.
My involvement with Eclipse has spanned over the decade as well, with experiences in pre-release WebSphere software following through to testing for the OSX release in 2.1 and beyond. My oldest public bug report dates back to Eclipse 2.0 in November 2002, although that's just one of the 570 bugs I've filed over the past 7½ years, a rate of around 75/year – or to put it another way, three bugs every two weeks for the last 380 weeks.
Hopefully by reporting, and in some cases patching, I've been able to help make the Eclipse platform and ecosystem a better place. I certainly hope my blogging and articles on sites like InfoQ and EclipseZone have come in useful to others over the years. I know that there are those who think my bug reporting style (and ties) are brash; but none of it has been driven by “this bug is affecting me, fix it!” but rather “this could impact other people.”
In fact, for most of the last five years, I've not been working in Java or using Eclipse in a work environment; it's all been just a hobby. The only times I've been to EclipseCon were self funded; and the last two EclipseCons I've covered remotely.
The last ten years have had their ups and downs, both technologically and personally. But I'm sure that if I'm still around ten years hence, I'll be writing about my continued involvement in the Eclipse platform for the last two decades.