Much ado about scripting, Linux & Eclipse: card subject to change


Eclipse Modloling

As it's Friday and I'm not feeling creative, here's a lolcat (thanks to ICHC!) you can fill in yourself. I'll even give you a topic.

The Tigerstripe project proposal is now posted at Eclipse, ready for community feedback.

Is this a good thing? A bad thing? A corporate version of the existing Modeling Project? Should it be debranded and contributed to Modeling? Should it stay branded and exist on its own? Can the Eclipse Foundation really support a project coming with its own branding, if that branding isn't owned by Eclipse? (Consider the rebranding issues with Mylar/Mylyn & Maya/Maynstall.)

And as with Subversive/Subclipse and PDT/phpeclipse, is it really the best approach to have two projects competing for resources when they could instead be sharing them?

Frankly, I don't know enough about Tigerstripe to form an opinion yet. Read it yourself. Post your comments or lolz below.

Woof, meow, and get out of the way.


Doug Schaefer said...

Great point on the project name. The policy is for the name of projects to be trademarks of Eclipse. I wonder if there is an exception clause.

Some say competition is great, but if it is possible to merge two open source projects staffed by volunteers doing the same thing, that would be best. The SVN plug-in wars have shown me that that's not always practical and we end up having to live with the inefficiencies. Great blog entry!

Unknown said...

I agree with Doug - good post. From my point of view soon we will see more and more overlapped projects, so need to think what to do with this.

From my point of view current situation caused by two factors - quick extension of covered areas and growth of commercial companies interest in participation in open-source. Sure that concurrence in open-source can help to detect really prospective projects and filter out some weak on early stages. But when few concurrent projects are mature, then concurrency can become a form of religious war, sometimes harder then in commercial field.

In order to understand all of these problems just imagine yourself as decision maker. You have new project idea and want to implement it. You have a commercial sponsor, which want to invest, but want to have quick results and commercial extension on top of open-source. You see that there is already started open-source project (this example not about Subclipse, it's just an abstract) which is from your point of view not really good and efforts for its fixing is close to making project from scratch. You are going to invest into project, but original authors want to keep leadership simply because they were first. Situation becomes really bad if you see that you have different vision with existing project authors. What to do in this case? Start own project? But it looks like not community-friendly and doing this you understand that start new flame in community and someone will say that you don’t want to cooperate and behave correctly. At the same time if concurrent project has also commercial sponsor, it means that they will not discard or change their approach, simply because they have commercial customers for commercial extensions, which work on top their open-source project. As the result two commercial companies will invest in different directions of same thing instead of merging efforts.

From my point of view the solution can be if respective authorities (Eclipse Foundation for example) should push projects to co-operation and it should be strict requirement for anyone - no exceptions, no concurrent projects (at least under umbrella of this authority). At the same time project sponsorship should become more visible for community. All conflict situations with project sponsorship and leadership should be handled by independent and respected authority. Otherwise we will stay in dark times of wild concurrency.