links for 2006-09-30

• Linux News: Developer: RadRails Speeds Web App Development
  Great story on long running dynamic language support in Eclipse.
  (tags: eclipse ruby radrails)

links for 2006-09-29

• SDA India : JP Morgan Gets Hooked to Eclipse RCP
  Overview of article from Eclipse.org
  (tags: eclipse india rcp JPMorgan)
• TheOpenForce.com: Gartner Mastermind panel
  Zack blogs about a panel that Mike Milinkovich was on.
  (tags: Eclipse panel milinkovich gartner)
• SAP Achieves Java EE 5 Certification
  Great news from SAP
  (tags: eclipse sap strategic member)

Build versus collaborate

David Berlind hits the nail on the head drawing attention to Bezos session at the MIT Emerging Technology conference this week. The bottom line is that Bezos says organizations are spending 70% of their time doing "technology heavy lifting" when they should be spending 70% of their time differentiating themselves. I would argue in many organizations that number is actually much higher, maybe even as high at 95% of resources are spent reinventing the wheel and only 5% on differentiation. I can even think of one that spends more than 100% of it's resources trying to be just like everyone else, but I digress.

Bezos explains this behavior as organizations thinking their infrastructure or platform is part of their "secret sauce", but quickly get overwhelmed trying to keep current and trying to achieve homogeneity.

But these days, in many situations, it doesn't simply boil down to "build versus buy" (or in Bezos example, "outsource"). In fact, I'm seeing "build versus buy" decisions less and less and "build versus collaborate" more and more. Collaboration gives the benefits of "build" (you can more easily customize to support your secret sauce) and "buy" (you start with a solid non-differentiating-yet-necessary set of infrastructure to build upon).

Spend (at least) 70% of your resources on differentiation. And then depending on your business model you need to determine how to align the rest of your resources amongst collaborating and buying.

- Don

Slicing and dicing Eclipse Download Stats

All Eclipse Committers have full access to count every single download of every single file from Eclipse.org and our many generous mirrors. Each time someone clicks through to a download, we store a record in a MySQL Database that tracks the file, time and a lookup of the country code of the request.

That's the good news.

The bad news is we have a *lot* of files. And we have a *lot* of downloads. I'm talking hundreds of terrabytes. So mining the database can be a bit of a daunting task.

Back in August I was in need of some core download stats. Not milestone downloads or downloads by project, but simply - how many production SDK downloads happen from eclipse.org and mirrors. So this is not counting downloads from member sites, nor is it counting the many IDE's built on top of the Eclipse Platform, nor is it counting the many organizations that download it once and share 40,000 copies internally. Nor is it counting the downloads from torrents.

Between Jan 1 and July 31 this year, there were over 3.7 million downloads of the production release of Eclipse 3.1 and 3.2 SDK. That's almost 630,000 downloads a month or 21,000 downloads a day of a 120MB file. No wonder Denis loves our mirrors so much!

No one country dominates the downloads. The United States has 19% of the downloads and China is close behind at 14%. Germany and Japan are tied at 9%. Then it's France, Brazil, India, Korea and Canada at 5 through 3%. Then no other single country has more than 3% of the downloads. I was surprised that we had over a dozen confirmed downloads from the Vatican City, and in fact one of the first 3.2 downloads was recorded from the Vatican City. I guess his holiness(sic) is a big Eclipse fan.

Platforms, on the other hand, do show dominance. 86% of downloads were for the Windows platform. 11% Linux and 3% MacOS. Less than 1% was for "other" platforms which included HPUX and Solaris. We do know from various studies that Eclipse applications are deployed on Linux at a higher rate (much closer to 20%), but Win32 dominance on the desktop seems pretty clear. We also know if we count milestone release downloads that the Linux number jumps up to 13% of downloads. Still not overwhelming, but it shows more Linux use at the leading edge of development. Hopefully the Eclipse Linux Distro Project will have a strong impact on these numbers over time.

- Don

Factors Contributing to the Success of Open Source (Part 3 of 3)

In Part 1 I described the background and in Part 2 I explored the results of a recent study regarding factors contributing to the success of open source projects.

We saw that a number of factors showed a strong correlation to the success of open source including type of project, experience of the developers, number of developers and target audience of the project.

Interestingly, when only the subset of projects in "production" is considered -- virtually all the correlations disappear. In other words, when and if a project makes it to production, there is virtually no correlation between the factors and success. The only factor that has any correlation is the type of project (applications versus tools), and the correlation only with number of releases, there is none to number of downloads.

So once an open source project manages to go into production, it's success is not related to the developers, language, license or type. Once in production, success seems to be linked to factors not related to the semantics of the project and probably related to things like quality, relevance and value.

- Don

Factors Contributing to the Success of Open Source (Part 2 of 3)

In Part 1, I laid out the background for a recent study at Carleton University that determined which factors contribute to the success of Open Source projects.

The six factors were:
1 - Number of developers
2 - Experience of developers
3 - Target audience
4 - Language popularity
5 - Project type
6 - License type

The two factors that had no statistically significant correlation were license type and programming language used. In my opinion, the lack of correlation for programming language makes a lot of sense. It proves that end users of applications and tools really don't care what is under the hood, as long as the product is good at what it does. Language does matter for frameworks and infrastructure types of projects, but the more popular a language is, the more competition the project will have and therefore the benefits of having a larger possible user base will be muted.

I am a bit surprised that licensing does not have more of an impact, I realize that end users probably do not care, but I would have expected a lot of developer based projects to tend towards less restrctive licenses. We will see later this week in part 3 that this factor actually comes back into play during the second part of the study.

All four of the remaining factors had a statistically significant correlation between the factor and likelyhood of success of the project. In order of strength:
1 - Project type (end user app, versus tools versus frameworks and infrastructure).
2 - Developer Experience
3 - Number of developers
4 - Target audience.

So it turns out that projects that are infrstructure/frameworks have the strongest correlation to successful open source projects. Tools less so and end user apps show the least correlation. I did find this a bit surprising given the popularity of some end user applications like Azureus. It does make sense that developers are more sophisticated about open source and
likely to use infrastructure/frameworks, but they would also be just as likely to use the end user applications and tools. One possibility is that there is a lot of competition for tools and applications with non open source incarnations. For example, look at the 100's of bit torrent applications that are also free (but not open source) that compete with Azureus. On the other hand, infrastructure and frameworks may have competition but it seems more likely to be commercial and restrictive in nature. Simply put - applications and tools do not scream to be extended and modified and therefore it doesn't really matter if they are open source so much as it matters that they are free. It does seem to matter that infrastructure is free and open source.

The strong correlation with experience of developers makes a lot of sense. If I were starting a new open source project, I would want to find people with experience to help. If I were starting anything, I would want to stack it with experience. But it is reassuring to see conclusively that Open Source is no different than other endevours - the playing field is level and experience is beneficial.

The number of developers correlation is a bit more suprising. I would have expected that after a certain "core" number of developers on a project there would start to be a negative impact. This was not demonstrated from the data. I know that all projects experience some level of churn during their existence, and I guess having a larger base improves the ability to adapt.

Projects that target the developer audience show a stronger correlation to success and less for sysadmin focused projects and even less for end user applications. I think this comes back to the same discussion as application type. It can't simply be because the developer audience is more accepting of open source because presumably they would also be likely to use end user applications. I think it boils down to the fact that it matters less that end user applications and tools are open source - as long as they're free/cheap. But for stuff that developers might use - stuff that needs to be extended, changed, distributed and adapted - being open source is critical.

One final note - there was actually another dimension to this study. The core data set was 350 random projects from sourceforge. Of the 350 random projects, 108 of them were classified as being in production. Do you think the correlations stay the same on this subset of 108 "production" projects?

On to Part 3.
- Don

Factors Contributing to the Success of Open Source (Part 1 of 3)

Rizwan Ur Rehman's thesis at Carleton University last year was titled "Factors that Contribute to Open Source Software Project Success". The results were interesting, and I've had a good look at the study and data. Over the next few days I'll blog about the results and some of the theories for the results. If you'd like a copy of the work, drop me an email. My email is my first name dot my last name and I work for Eclipse.org.

In this part I would like to describe the background and basis for the research.

The first challenge Rizwan faced was defining "success". To me, success would be a healthy ecosystem with lots of commercial and non-commercial activity. This would be pretty difficult to measure, not only to find publicly available data, but because it's not clear how to measure the "health" of an ecosystem. There is hopefully an opportunity for research in this area moving forward.

So, to define "success", Rizwan did what any good OS citizen would - he asked the OS developer community - what does it mean to be a successful open source project? The results were very clear - Downloads and Releases. Therefore, the measure of success for his research was the number of downloads and also the number of releases.

The next challenge was to determine what factors to study. I can think of dozens of factors that may or may not contribute to the success of an open source project, but Rizwan narrowed it down to six:

1 - Number of developers working on the project.

2 - Experience of the developers (in years) working on the project.

3 - If the OS Project is for end users (application software), for sys admins or for developers (developer tools/frameworks, etc). Basically - who is the target audience for the OS Software being created.

4 - If a "commonly used" programming language (sic) is used, where "common" is defined as C, C++, Java or PHP.

5 - Is the OS Project an Application, development or deployment tools, or frameworks and infrastructure.

6 - Type of OSS License used ("Very Restrictive" versus "Mildly Restrictive" versus "Non-restrictive"). Only OSI approved licenses were considered. (rest of this paragraph - sic) - GPL was considered "Very Restrictive". LGPL, EPL, MPL and otheres were considered "Mildly Restrictive" and Apache, BSD, MIT (etc) were consisdered "Non-restrictive".

The study focused on a completely random slection of 350 projects from SourceForge. At the time, there were 100,341 possible projects on SourceForge that could have been selected.

In Part 2 I will list the results from the first part of the research. Of the Six factors, there were four that showed a correlation to a successful project and two showed no correlation. Can you guess what they were? And bonus - can you put the four in order of strength?

Find out in part 2.
- Don

Eclipse Summit Europe - A distinctly Eclipse Event

Eclipse Summit Europe is a distinctly Eclipse event and a I'm looking foward to it. I say it's "distinctly Eclipse" for a number of reasons. First, take a look at the sponsors list - we initially hoped (and thought ambitious) to sign up 8 sponsors. We have 19 20. Second, is the implementation of the "Sponsors Network". Rather than have traditional commercial exhibitor hall, we are trying out (at the suggestion of the membership) a sponsors network. It is a bit of a risk and a bit of a novel idea, but I think the number of sponsors wanting to try it out speaks volumes. Basically the attendees will be interacting directly with the sponsors and working out time and space to meet and interact.

Then there are the Symposia. The symposia are all about collaboration and open discussion amongst all of the attendees. There will be a number of "Speaker - Audience" tracks, but the Symposia will be much more dynamic and interactive. The chairs of the Symposia are top-notch and we are actively looking for more participants. Details on how to join can be found here.

- Dn

Help us make EPIC a better place and Win an iPod

The feedback so far for EPIC has been outstanding. Keep it coming. See this Community Bulletin for more info!

- Don

Eclipse RCP Wins JDJ Editors Choice Award

Eclipse RCP has won an "Editors' Choice" award from JDJ. Yakov Fain says RCP "is just an awesome technology" and that it "has the potential to really change the way Java client applications are built".

I could not agree more.

- Don