There's an article about technology innovation in bad economic conditions in today's NY Times:
It's No Time to Forget About Innovation
I believe this is something to remember...particularly for Eclipse committers...since in my view they are the innovators in the Eclipse community.
Sunday, November 02, 2008
Tuesday, October 14, 2008
ECF and Coffee in the Classroom
There was a very cool announcement on the ECF newsgroup recently about a collaboration framework that uses ECF called Coffee. See here for the announcement. The Coffee end user site is here, and the development site is here. It's exciting for me to see ECF being used by projects both inside and outside the Eclipse Foundation...and as as you can see from the announcement they are keen to both collaborate and contribute back to the open source community.
Enjoy the beverage!
Enjoy the beverage!
Friday, October 03, 2008
Planning for ECF 3.0
ECF is nearly finished moving from Technology to the new Runtime project, and we are doing planning for ECF 3.0/Galileo. See the new plan here.
Please make enhancement requests and/or start discussion about desired features in the dev mailing list...and let us know what features, changes, or bug fixes you want for ECF 3.0.
Please make enhancement requests and/or start discussion about desired features in the dev mailing list...and let us know what features, changes, or bug fixes you want for ECF 3.0.
Thursday, August 07, 2008
Some Disturbing Things from Microsoft
Open Source: A 'Growing Challenge' to Microsoft
There's an MS quote that is particularly disturbing to me
"The availability of protocol licenses may enable competitors to develop software products that better mimic the functionality of Microsoft's own products which could result in a reduction in sales of our products."
This is disturbing because it's pits protocol/service interoperability (a user need) against MS's sales (a MS shareholder need). Let's hope this doesn't result in MS pulling back from protocol openness.
There's an MS quote that is particularly disturbing to me
"The availability of protocol licenses may enable competitors to develop software products that better mimic the functionality of Microsoft's own products which could result in a reduction in sales of our products."
This is disturbing because it's pits protocol/service interoperability (a user need) against MS's sales (a MS shareholder need). Let's hope this doesn't result in MS pulling back from protocol openness.
Sunday, August 03, 2008
Monday, July 28, 2008
ECF 2.0.0 New Features video
It can't match Ed's pictures, but below is a pleasant scene, where most of the beauty is hidden beneath what is visible
But to the point: ECF has a new video showing some of the new things in ECF 2.0:
But to the point: ECF has a new video showing some of the new things in ECF 2.0:
- Screen shot sharing
- URL sharing
- Real-Time shared editing
- Discovery API, Service Discovery, Remote OSGI Services
- Async File Download
Thursday, July 03, 2008
Freed from email
There's an interesting article about use/abuse of email in the NY Times today:
I Freed Myself From E-Mail’s Grip
FWIW, I think ECF is doing it's part on this problem, by providing multiple ways for Eclipse users to easily, cheaply, and openly communicate and collaborate.
Also, for those interested, there is a longstanding proposal to add an XMPP server at Eclipse Foundation in order to help teams build and maintain community.
I Freed Myself From E-Mail’s Grip
FWIW, I think ECF is doing it's part on this problem, by providing multiple ways for Eclipse users to easily, cheaply, and openly communicate and collaborate.
Also, for those interested, there is a longstanding proposal to add an XMPP server at Eclipse Foundation in order to help teams build and maintain community.
Wednesday, June 25, 2008
ECF 2.0.0
With Ganymede the ECF project has it's 2.0.0 release. As for what's new....there were many little things, as well as many big but invisible things (i.e. APIs), but the things that really stand out for me are
I like to say: 'the community is the team' :)...so congratulations and thanks to the ECF community.
P.S. You can find/install ECF's features in the Ganymede Communications category.
- Real-time shared editing (with a quickly-becoming popular video)
- Discovery API: Simplified API and added jSLP provider
- Remote OSGi Services API: Added provider based upon r-OSGi
- P2: ECF's asynchronous file transfer API is used for P2's multi-protocol download, and so is part of the SDK.
- Community Growth: We added some great new committers to the project: Markus, Jan, Ted, Mustafa, Marcelo...as well as many more contributors.
- New and Noteworthy for details and more
I like to say: 'the community is the team' :)...so congratulations and thanks to the ECF community.
P.S. You can find/install ECF's features in the Ganymede Communications category.
Saturday, June 21, 2008
Adding Shared Editing To Your Favorite Text Editor
With ECF 2.0/Ganymede, ECF introduces Real-Time Shared Editing. By default, the ECF real-time shared editing capability has been added to the JDT Java Source Code editor and Eclipse's Default Text Editor.
I've begun documenting how those with other types of Eclipse-based text editors (e.g. C/C++, php, javascript, xml editors, etc) can add real-time shared editing to their editors...simply by adding a little bit of markup to plugin.xml. See here for explanation and example.
I've begun documenting how those with other types of Eclipse-based text editors (e.g. C/C++, php, javascript, xml editors, etc) can add real-time shared editing to their editors...simply by adding a little bit of markup to plugin.xml. See here for explanation and example.
Tuesday, June 17, 2008
Articles on ECF
There are now a couple of articles on Eclipse Communication Framework for version 2.0.0/Ganymede release:
InfoQ: http://www.infoq.com/news/2008/06/eclipse-ganymede-ecf
DZone Interview: http://java.dzone.com/news/the-ecf-project-an-interview-w
InfoQ: http://www.infoq.com/news/2008/06/eclipse-ganymede-ecf
DZone Interview: http://java.dzone.com/news/the-ecf-project-an-interview-w
Thursday, June 05, 2008
Eclipse and Volunteerism
In response to a recent news thread, Bjorn Freeman-Benson says
I want to examine briefly Bjorn's assertion that Eclipse is 'paid volunteer'.
In looking at the Dash commit count sorted by # of commits, the thing that jumps out at me is that for 2008 individuals, are right after IBM in terms of # of active committers (23.56%), commits (159,279), and lines of code (4,982,101).
There are/should be many qualifiers for these data: I'm sure many of the independents are paid to work on Eclipse...but conversely it's quite possible (and likely, I think) that some corporate-supported committers work more on Eclipse-related work...by their own choice...than their employers explicitly sanction. But in any event, I think the overwhelming message from the data is that the contribution from independents (many of whom are unpaid volunteers I would suppose) is large...and growing rapidly year-over-year.
All I'm saying is that 'Eclipse' is not necessarily 'paid volunteer'. But it does have a strong aspect of unpaid volunteerism, which as Bjorn (and Eric Rizzo) point out, should be encouraged and supported:
For some pointers to interesting thoughts about motivations, please see
When Self Interest Isn't Everything
Seems that while I was typing this out, Boris Bokowski has also made some similar points.
As Dan Ariely explains in "Predictably Irrational", there is a huge difference between real volunteer and paid volunteer (Eclipse is 'paid volunteer').
I want to examine briefly Bjorn's assertion that Eclipse is 'paid volunteer'.
In looking at the Dash commit count sorted by # of commits, the thing that jumps out at me is that for 2008 individuals, are right after IBM in terms of # of active committers (23.56%), commits (159,279), and lines of code (4,982,101).
There are/should be many qualifiers for these data: I'm sure many of the independents are paid to work on Eclipse...but conversely it's quite possible (and likely, I think) that some corporate-supported committers work more on Eclipse-related work...by their own choice...than their employers explicitly sanction. But in any event, I think the overwhelming message from the data is that the contribution from independents (many of whom are unpaid volunteers I would suppose) is large...and growing rapidly year-over-year.
All I'm saying is that 'Eclipse' is not necessarily 'paid volunteer'. But it does have a strong aspect of unpaid volunteerism, which as Bjorn (and Eric Rizzo) point out, should be encouraged and supported:
The place that Eclipse overall has not done a good job is making our projects attractive to unpaid, part-time volunteers. They're different. Their motivations are different. The Rizzo Ceiling is real for them.
For some pointers to interesting thoughts about motivations, please see
When Self Interest Isn't Everything
Seems that while I was typing this out, Boris Bokowski has also made some similar points.
Tuesday, February 26, 2008
projectDiversity.equals(productivity)
I have started reading the book described in this article
In Professor's Model, Diversity = Productivity
After reading some of his book, it seems that cognitive diversity (defined as group differences in perspective, heuristics, interpretation, and prediction) generally lead to improvement in overall productivity. There are other kinds of group differences, of course...e.g. what Page calls identity differences (e.g. racial, gender, and social group), and other sorts of differences, but Page identifies cognitive differences as key.
Increased productivity is dependent upon the problem/task at hand, of course. Group tasks/problems that hinge on questions of representation and interpretation get greater value from diverse perspectives, since such diversity allows more alternatives to be generated and considered.
My thought on reading this was that many sw design tasks are like this (i.e. hinge upon how the problem is represented) and so should be particularly good candidates to benefit from teams with high cognitive diversity...and the many perspectives that come with such groups.
Interestingly, Page also identifies a type of diversity that seems to result in lower group productivity...I'll talk about that after I've read a little more.
In Professor's Model, Diversity = Productivity
After reading some of his book, it seems that cognitive diversity (defined as group differences in perspective, heuristics, interpretation, and prediction) generally lead to improvement in overall productivity. There are other kinds of group differences, of course...e.g. what Page calls identity differences (e.g. racial, gender, and social group), and other sorts of differences, but Page identifies cognitive differences as key.
Increased productivity is dependent upon the problem/task at hand, of course. Group tasks/problems that hinge on questions of representation and interpretation get greater value from diverse perspectives, since such diversity allows more alternatives to be generated and considered.
My thought on reading this was that many sw design tasks are like this (i.e. hinge upon how the problem is represented) and so should be particularly good candidates to benefit from teams with high cognitive diversity...and the many perspectives that come with such groups.
Interestingly, Page also identifies a type of diversity that seems to result in lower group productivity...I'll talk about that after I've read a little more.
Sunday, February 10, 2008
When Self-Interest Isn't Everything
An interesting editorial by an economist in today's NY Times
When Self-Interest Isn't Everything
Is Hirschman's analysis (described in editorial) relevant for the open source 'movement'? How much of open source is/will be about self-interest?
When Self-Interest Isn't Everything
Is Hirschman's analysis (described in editorial) relevant for the open source 'movement'? How much of open source is/will be about self-interest?
Thursday, February 07, 2008
Discovery and Access for Remote OSGi Services
See here for some work combining the ECF discovery API with the ECF remote services API.
Interesting things about this:
Interesting things about this:
- ECF APIs have multiple providers...i.e. zeroconf/bonjour and SLP for discovery, r-OSGi, ECF generic, xmpp, javagroups, and multiple flavors of JMS for remote services. This allows middleware and UI written to these ECF APIs to run unmodified on any/all of these providers.
- The ECF remote services API can be used in either 'transparent' or 'non-transparent' manner...allowing programmers to decide whether network transparency for remote procedure call (RPC) is appropriate for their application...or not.
Tuesday, January 08, 2008
Project Diversity = Productivity?
In today's New York Times is this intriguing interview:
In Professor's Model, Diversity = Productivity
Given the past year's frequent postings regarding project diversity (e.g Bjorn, Doug, Committer Reps, and many of the always-beautiful postings by Ed Merks), this research seems relevant.
I haven't had a chance to read the original research yet, but this caught my eye in the interview:
In Professor's Model, Diversity = Productivity
Given the past year's frequent postings regarding project diversity (e.g Bjorn, Doug, Committer Reps, and many of the always-beautiful postings by Ed Merks), this research seems relevant.
I haven't had a chance to read the original research yet, but this caught my eye in the interview:
What the model showed was that diverse groups of problem solvers outperformed the groups of the best individuals at solving problems. The reason: the diverse groups got stuck less often than the smart individuals, who tended to think similarly.
The other thing we did was to show in mathematical terms how when making predictions, a group’s errors depend in equal parts on the ability of its members to predict and their diversity. This second theorem can be expressed as an equation: collective accuracy = average accuracy + diversity.
Subscribe to:
Posts (Atom)