It’s a shame that Mr. Rubenstein feels he must twist words and context to create the illusion of controversy, leaving those he purports to quote to clean up the mess (“Branching and merging: the heart of version control”). Please allow me to clarify the statement attributed to me, which in its original form would have been about Subversion’s destiny (and nothing more): The Subversion developers have no plans to transform it into a DVCS tool. The market still needs centralized VC, and Subversion is the best offering in that space. And if, some day, DVCS emerges as The Only Way To Do It, then there would still be no need for Subversion to adopt that model because several great DVCS tools already exist.

C. Michael Pilato
Principal Software Engineer
CollabNet

How Eclipse mentoring works
I believe that you’ve captured the spirit of mentoring at Eclipse (“Mentors lead the way in open source”). But I have some minor clarifications: At Eclipse, project mentors come exclusively from the Architecture Council (AC). The AC contains representatives from the top-level projects at Eclipse and from our Strategic Members (one representative each). Most of the AC reps are invited to join after years of experience in open source in general and Eclipse in particular.

Also, a project requires mentors throughout its incubation period. Incubation starts when the project is created, and ends with graduation. To graduate, a project is required to demonstrate an understanding of open and transparent development, mature code and stable APIs. Only when the project leaves graduation are the mentors excused of their duties. The project’s corresponding Project Management Committee (with help from me) pays attention to the comings and goings in all the projects throughout the project’s life. Graduated projects tend to require generally less supervision (and become the source of new AC members).

Wayne Beaton
Director of Open Source Projects
Eclipse Foundation

Too confusing for the big guys
With regard to out-of-date software in use (“Zeichick’s Take: Java, Java everywhere”), the company I work at has these:

SQL Server 2000; all critical business data (customers, orders, shipping info) are in there, and I hate it (difficult to work with LINQ, Entity Framework, no IntelliSense)
Visual Basic 3 (can you believe it?), which is still actively used to maintain our flagship product used by many users worldwide
Oracle 8i
Java EE 5
PHP
.NET (C#, VB.NET, etc.)
Flex
Windows XP, Vista, 7, 2003, 2008
Various flavors of Linux

It’s a truly confusing array of technologies, considering that there are less than 50 developers in my company and the only reason it has so many different technologies (some of which are way out of date) is that it doesn’t want to upgrade old apps written by people who left the company long ago.

My take is that in a stable company that has little staff turnover, there is far greater willingness to upgrade because the people know the existing codebase very well, so they can (and want to) move to newer and better platforms. For companies that have a large rate of staff turnover (like the one I currently work for), it cannot afford to upgrade.

Bill
United States