I'm a sucker for when it comes to pretty graphs and charts. Visualization can help really show some trend lines. Of course, I also take stats with a grain of salt, as they can say whatever you want them to say. They do though give some insight into trends that are happening.
I recently rediscovered the MarkMail.org email list indexing service. Particularly it is indexing the various eclipse.org developer mailing lists. Looking at eclipse as a whole the volume of communication has increase substantially over the years. (Side note...the cool thing about MarkMail is that it's powered by XQuery and an XML Database.)
However, the overall stats do not tell the entire story. Eclipse in the early years was very small and as the number of projects and email lists grew, the volume of messages would grow as well. What is more interesting is to mine the data further and see the particular trends of the top 3 or 4 mailing lists as shown by mark mail.
Eclipse Dev:
What is interesting here is the trend line. The stats clearly show that communication between the various users of the eclipse-dev mailing list has significantly dropped off compared to the early years. The question to ask here is why.
Eclipse CDT Dev:
Unlike the Eclipse-Dev the CDT Dev mailing list is very active and has shown a steady increase in activity since it's inception. MarkMail does have a gap of data missing, but the trend line shows at least some healthy communication.
Eclipse WTP Dev:
Like the Eclipse-Dev communication the main WTP-Dev mailing list has dropped off as time has gone on. The question again to ask is why.
Ian Skerrett recently asked in a comment in one of my blog postings "What has changed in eclipse...that puts us at a cross roads?" I didn't have an answer then, but one thing I think is putting us at a cross roads is the decreased communication in some of the projects. Open communication of problems, development plans, ideas, and disagreements helps keep the project vibrant. It helps to show an active involved developer community. CDT seems to be doing well. Others appear not to be doing as well. One could argue the project maturity aspect, but then what keeps CDT so active?
Again stats should not be the only measurement used. They can help put another piece of the puzzle together though. So as Sherlock Holmes would say, "The game is afoot!"
MarkMail and the Eclipse Mailing Lists
About Me
- David Carver
- My technical interests include XML, agile development, open source projects, and improving business to business standards development. At Eclipse.org I serve on the Architecture Council, and I'm a committer on the WTP Source Editing project focusing on XPath 2.0, XSLT, XML, and DTD development. I also help with the WTP Incubator VEX, XQuery, and RelaxNG development. View my linkedin profile.

Intellectual Cramps by David Carver is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Based on a work at intellectualcramps.blogspot.com.
Archives
-
▼
2009
(198)
-
►
November
(15)
- How to Diversify
- Project Diversification Sucks
- Say What?!?!!!
- Testing Cramps
- eXist 1.4, Love It...Hate it...Love it!
- Individuals 149, IBM 132
- Functional Testing Builds
- PsychoPath 1.1M3 a Java 5 (1.5) or greater XPath 2...
- Do Eclipse Projects need to roll out Patches faste...
- Performance Tuning an Athena/Hudson build
- Eclipse XSL Tools gets SAXON Debugging Support
- SWARM for the Community
- XPath 2: Collections and PsychoPath
- Eclipse Documentation on the Wiki
- Making it Easy for Contributors to Contribute
-
►
October
(14)
- VEX (Visual Editor for XML) gets some life
- Bad Habit in Design: Concentrating on the 20%
- IDs Need to be Published
- Eclipse DemoCamp - Columbus, OH
- Model the Data not the Form
- API Design is easy...Good API Design is HARD
- XQDT now at Eclipse
- The Problem of Exporting Everything
- User Defined Schema Types and PsychoPath
- XSL Aware Outline Part II
- XSL Aware Outline
- Yellow Does Not Equal Green/Blue
- Vendor Lock In
- Small Bits and Pieces
-
►
September
(11)
- Common Eclipse Build Failures and Causes
- XSL Tools 1.0.2 Released
- XSLT Processor Extensions Part III
- Builds: We make them complicated - Follow Up
- XSLT Processor Extensions Part II
- XSLT Processor Extensions
- Builds: We make them complicated.
- Standards, Documentation, Single Sourcing, and Con...
- A Hudson Transition
- Messy Syntax??
- XML Security Tools 0.5
-
▼
April
(16)
- Unit Testing and Continuous Integration Summary
- Eclipse Development Process: Technical Practice - ...
- PsychoPath XPath 2.0 Update
- Eclipse Development Process: Technical Practice - ...
- MarkMail and the Eclipse Mailing Lists
- XML Update
- Surviving and Thriving
- Eclipse Development Process: Addressing Bugs
- Is Quality Dead for eclipse code?
- Tweaking the Eclipse Development Process
- Sometimes Things Just Work
- Unit Testing plugin.xml Files
- Successful Open Source/Standard Projects
- Cutting the Cable TV Ties
- Quality
- Kicking Over Rocks
-
►
November
(15)
Categories
- agile (64)
- agora (1)
- ant (2)
- bliteotw (2)
- bugday (2)
- build (25)
- cms (1)
- css (1)
- dita (12)
- docbook (25)
- docman (1)
- documentation (16)
- dr horrible (1)
- dvcs (2)
- e4 (1)
- eclipse (351)
- eclipsecon (1)
- encryption (1)
- galileo (1)
- home theater (1)
- java (1)
- joomla (3)
- linux (2)
- mantis (5)
- mono (1)
- mylyn (6)
- netflix (1)
- open source (10)
- osgi (3)
- pde (4)
- pdt (1)
- performance (3)
- php (5)
- refactoring (22)
- referring (1)
- relaxng (3)
- release engineering (21)
- reviews (1)
- schematron (1)
- scrum (6)
- security (3)
- silverlight (1)
- soccer (1)
- standards (32)
- standards. (2)
- summer of code (2)
- testing (37)
- testing. (1)
- ubuntu (2)
- web services (3)
- wiki (1)
- wsdl (1)
- wsi (1)
- xforms (2)
- xml (222)
- xpath (23)
- xquery (14)
- xsd (1)
- xsl (50)
- xslt (44)
- xtext (3)
- year end review (1)
- zombies (1)
The Eclipse project is pretty easy to explain...a quick peek on Dash shows that the decline in conversation roughly follows the decline in activity.
Looking at e4-dev (where the new stuff is happening) shows a very active list, with some months over 200 posts. So I would say that there is a very healthy conversation going on about the future of the platform. It's just not where you might think it is ;-)
The other factor to remember is that for many Eclipse projects, the real conversations don't happen on the lists. They happen in Bugzilla. There are tons of bugs that apply to WTP and Platform which have many many posts on them.
I've personally never been partial to Eclipse's tri-channel approach (lists, bugs, newsgroup), but that approach long predates the existence of the Foundation. In any event, it is up to the committers on the project to find the right channels for their community.
I think your data with respect to the eclipse project is incomplete. In the early days of the eclipse project, we used eclipse-dev for build messages. This changed in early 2004 and we moved to the platform-releng-dev mailing list. Thus a decline in activity there, and an increase in activity on platform-releng-dev.
http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/mail144.html
Also, the graph for eclipse-dev doesn't take into account the data for new mailing lists that spawned out of the eclipse projects, such as equinox-dev, p2-dev, pde-dev, etc.
http://eclipse.markmail.org/search/?q=#query:list%3Aorg.eclipse.equinox-dev+page:1+state:facets
I think using eclipse-dev as a representative of the activity in the eclipse projet isn't an accurate representation...
The CDT mailing list thrives because there are so many vendors involved. It's our only way of communicating.
Projects like Eclipse, and even some of the e4 components (who's list is much less active now than it was a couple of months ago), have few or even single vendor where communication happens in the hallways.
I think Kim is right as far as the build messages on eclipse-dev. I used to hate that. But remembering back then there wasn't much traffic there other than build messages. Mind you she is also write about the p2-dev list which is as active as the CDT one, and for the same reason, lots of players.
I once blogged about an "openness" metric that was proporational to the number of messages on the mailing list. People scoffed at it then, but you're evidence shows the same...
@Mike, Kim, and Doug: I agree with everything that is said. Which is why I also stated that stats on anything have to be combined with other statistics. I could probably find the e4 mailing list to start comparing stats.
I've found similar trends with long established projects at Apache. Just take a look at the Xalan-Dev mailing list. Lots of activity until 2005 and then very little after that. It's about the last time any real serious development happened on that project.
Cool tool, but like any stats engine, you need to explain context.
Check out the heavy-hitters for dash-dev@: Bjorn's stats are inflated due to all the portal-generated mail sent on his behalf (as I'm sure are the stats for Modeling newsgroups which get spammed weekly w/ build notifications). Interestingly, Ward's still in the top 4, despite his 2-year gap in email traffic (Jul 2006 - Oct 2008).
Looking at just the mailing lists as an indicator of project health is a very one-sided measurement. Gotta check out CVS/SVN commits, wiki doc publication, IRC chatlogs, newsgroups, download stats, ...
A lot of WTP's communication happens in and around the weekly meetings, or for the two of us, on IRC.
Think about how those stats would spike if everything we exchanged was through the mailing list...
@nick: I agree...this is only one very small view point. Which is why I stated take stats with a grain of salt. You need a lot of different stats from different sources to provide a complete picture.
@nitin: Yes, I think there should be more communication in the mailing list or in places where that communication is kept as a public log. IRC is good because there are public logs about what is being said. The weekly meetings are okay, but there is so much more that can be done outside of the weekly meetings.
To everybody, again, take these stats with a grain of salt. They only provide a very narrow view, but the tool itself is a worthwhile tool, as it can help give an additional piece to the puzzle of eclipse usage. I would love to see a MarkMail analysis on the Eclipse newsgroups. To see what the volume is like for the number of users and questions that get asked there.