Another great post by Bjorn on life at Eclipse in the new world and a great follow up by Michael Scharf on his thoughts on major changes needed to get there. These two posts made me think about what I'd like to see as a way to take Eclipse forward into the future.
Bjorn draws up a nice, clean looking "architecture" on how the cycle of value feeds the Eclipse ecosystem. Committer -> Project -> Product -> Profit -> Committer... Unfortunately there's a week point in this cycle which I fear will blow the whole thing up, and that's the assumption that vendors making profit on Eclipse-based products will be compelled to fund Committers working on open source projects feeding those products. I've seen too many vendors in this position not do that.
It's frustrating to see so many products based on the CDT and less than half of them contribute back to improve the CDT. Maybe the existing committers have done so good a job that they don't have to. Or maybe they're not big enough to devote developers to the cause in a significant fashion to justify the cost. What ever the case, we all know how hard it to bring in new contributors. You need to "Create the Need" for them to come. It certainly isn't out of good will, especially in these times.
Assuming the cycle fails all together, how do we ensure Eclipse projects remain healthy with new contributions? Michael brings up a solution that I've wanted to see for a while. He brings it up from an architectural perspective, which is what he does :), but I bring it up from a political perspective. The members should fund a team of core developers to ensure critical Eclipse projects continue to grow. These developers would be vendor neutral other than to follow the wishes of the members. The Foundation can help co-ordinate this but it's really on the Eclipse membership to make it happen.
The best example of this I know is with the Linux Foundation where they state that one of their goals is "Protecting and Supporting Linux Development". Now Linus doesn't work for the Foundation, but the members do fund his work there to ensure he can continue to work full-time and independently on the kernel. I'm not sure how well this is working in practice, especially with people other than Linus. But it's worthy of a look.
Interestingly enough, a lot of the members of the Linux Foundation are also members of the Eclipse Foundation. But, would such a policy work at Eclipse?
Tuesday, April 07, 2009
Subscribe to:
Post Comments (Atom)
13 comments:
Interesting thoughts indeed. But how realistic is it? For example, do you think WindRiver would reconsider their recent decision to downgrade their eclipse.org membership from strategic to solution member, if their membership fees were spent on developers employed by the Eclipse Foundation?
Also, which "critical Eclipse projects" are you thinking of concretely?
I can't say what Wind River would do if this were an option. I'm not even sure why we downgraded our membership to begin with. I wasn't privy to those discussions.
But if you have 100 members and charge them $10K each/year, that's $1M to play with, ~5 devs, and the cost isn't that high for the members. Is it realistic? I have no idea.
And I would fund developers, not projects. Which projects these developers become involved with would depend on the wishes of the membership, giving them value in return.
The idea of the Eclipse Foundation directly employing developers is raised fairly frequently. I think, that given the money to do so, this could be made to work. This is particularly useful for addressing the "less attractive, but very necessary" tasks. For instance, improving the build infrastructure or working on reducing the bug levels in the platform. The board would have to be in charge of identifying these areas so that the member companies feel that they have a say in how their money is used.
Of course, that doesn't really solve the underlying larger issue of how to fund the Foundation in the first place. The drop in membership shows that we are not showing compelling value to being a member. The more you raise the membership dues, the more members you will loose. The problems is that members aren't loosing that much by dropping their membership. They can still continue shipping products based on Eclipse.
Perhaps it is time to consider a pay-to-play model. If a large company wants to ship Eclipse-based products, perhaps they should be required to be a member. We could still allow unconstrained use for individuals, small companies, etc. I know, that's so not OSS, but Eclipse is not your typical OSS foundation.
Maybe eclipse needs a Eclipse.com branch, like Mozilla has a Mozilla.com and Mozilla.org branches. One is a for profit company the other the umbrella company that over sees everything.
Konstantin, the EPL pretty much makes pay-to-ship-a-product a non-starter. Funded developers would have to be done on a value-received model, i.e., if company A helps fund the developer pool, then company A helps select the bugs/features that get fixed/implemented.
Here is my response: The Eclipse Freeloader Award
Interesting idea. This proposal might address some cross project issues that one company doesn't want to fund 100% but might want to fund 10%. However, I don't see it as that different from the status quo. Today, strategic developers are supposed to provide eight developers as a condition of membership. These resource contributions aren't enforced. However, it means that this company can decide the bugs and features their developers will tackle. I think the fundamental issue is that many companies find the current technical direction and code we make available "good enough" that they can ship products based on it. Economics is all about incentives and we need to find some more compelling ones :-)
> Konstantin, the EPL pretty much
> makes pay-to-ship-a-product a
> non-starter.
I know that it would take a license change and therefore the situation would have to get far worse that it is today for something like this to be considered.
The new license couldn't be applied to any of the existing EPL-licensed code or any code derived to it, but that wouldn't be necessary. All it would take is for the board to approve a new license and key part of platform to be re-written under that license. It doesn't matter that 99% of the system is licensed under EPL if 1% of the system that you need to run Eclipse is licensed under EPL v2 and it is too complicated to be easily replaced. ;)
> Funded developers would have to
> be done on a value-received
> model, i.e., if company A helps
> fund the developer pool, then
> company A helps select the
> bugs/features that get
> fixed/implemented.
That might work to some extent, but doesn't really address the freeloader problem. Chances are are pretty good that the funded developers would be doing something that the freeloaders would benefit from. Having a vote over how funded developer resources are allocated is a fairly small incentive to not drop membership during a budget crunch.
I think that the problem with the cycle is that problems in software products, ranging from inconveniencing behaviour to outright crash and burn situations, are too widely accepted.
As a result, if some piece of 'free software' does a good enough job ... then companies building products on top of that software will just accept the problems and move on.
There are always exceptions to this rule, but one only has to look a the sudden slowdown in the CDT managed builder efforts to see that once something worked "well enough" companies stopped investing, even though every end user could tell you that the experience is far from pleasant.
It is generally individuals who are themselves too troubled by the state of a particular functionality who act as the catalyst for significant participation in open source projects.
Thomas
www.cranksoftware.com
The current Eclipse budget, especially now, simply can't sustain a pool of developers. I've suggested that strategic developers optionally make available one of their eight people toward a pool of people who would be directed by a committee of those who contribute with a focus on "the common good," e.g., things like build infrastructure. Obviously that hasn't happened.
@Thomas: Actually as far as managed build is concerned, it is so bad that few of the big IDE vendors use it seriously in their product.
And yes, it's going to take the efforts of a band of part timers to do anything about it and only because it's driving them nuts, yours truly included.
It is a great example of a feature that none of the contributing vendors want to take on directly, but something that an independent crew might think is important enough to get done. Maybe...
@Ed: I'd like someone to do a serious audit on whether the Strategic Members actually have 8 devs working on Eclipse. Another dirty secret at Eclipse.
At any rate, the idea is make this above what the Foundation needs for it's work. In fact we might want this crew to be a different org. The mozilla.com versus mozilla.org situation is similar to that.
@Ed: I must be that dam EMF taking up all the resources! :)
Post a Comment