I am sorry you took that a miss of respect...and that you took it
personally..
I do not criticize any people. And I respect the work you and your team
has gived to lepido coccon or any other projects...
I just criticize the behavior of this company (it seems yours) on that
point (and only this one)... and companies are free to be criticized no?
> Tell us where is the mistake: keeping a project asleep forever, giving
> the false hope it may one day come back to life, or be honest,
> explaining that we have no resources to dedicate and that lack of
> interest and/or resources from other parties that expressed initially
> their interest lead to the archival of the project?
Telling the truth is good but won't avoid disapointment expressions...
That's precisly the honor your company will have : to face people like
me which are disapointed...
> The mistake, if it's one, may have been to not realize at the start of
> the project the huge difference there is between opensource projects
> related to development frameworks (such as Cocoon) and opensource
> projects related to tools (like Lepido). Now one learns from every
> mistakes he makes. We did, and hopefully what follows shows it.
that's exactly what I am speaking about, nothing else!!!
I personnaly know that point (opensource server softs are different than
opensource client tools for a lot of points) since I started on open
source, certainly later than you!!!
That's what eclipse (and some other projects) has changed: giving good
open source for TOOLING.
Did IBM gived up eclipse??? eclipse isn't for java what wtp is for the
web and what lepido is for coccon???
All companies in the world can make mistakes (including IBM or
Microsoft) so please don't take it for your person nore your work and
don't take it as a lesson, I'm not saying: I wouldn't have done this
mistake.
Anyway that's not my problem and I will not loose my time on forums for
that (sorry, that's was also due to my disapointement...).
> When someone uses a framework, he has to know how the framework
> functions, and his code is close to the framework in that it uses its
> concepts and classes. What that means is that transitioning from using a
> framework to contribute to a framework is "just one click away": open
> the source code of the framework classes you use in your own
> application, and start hacking, and then contribute your modifications
> back to the community.
>
> When someone uses a tool, he just has to know the "user manual" of that
> tool, i.e. where to click or what to type to activate the tool's
> features. When something in the tool doesn't work as you expect, or if
> you'd like to add a new feature, the technological gap between what you
> use the tool for and the tool's code is incredibly large (i.e. knowing
> Cocoon doesn't give you Eclipse plugin development skills).
>
> Additionally, we realized that the "return on investment" of
> contributing to tools is very different from contributing to frameworks.
> Contributing to a framework is often related to an actual project need.
> Instant ROI because you can deliver your project better or quicker.
>
> The ROI is very different with tools: it comes both from the increased
> productivity it gives you, and the potential new contributors and
> business coming from and enlarged user base of the framework, because it
> is more accessible to new users. Now in our case, the increased
> producivity may not exist: I type sitemaps way faster as source code
> than with a GUI.
>
> Now the concept of "tools" and "framework" itself has to be considered
> relatively to your actual projects: if they are about building webapps
> with Cocoon, Eclipse plugins are tools. But if your projects consists in
> building e.g. reporting tools, then something like BIRT is definitely a
> framework. This relative definition of the concept shows up in the
> contributors on the different projects: contributors to Apache are on
> the server side of things whereas companies contributing to Eclipse are
> tool vendors.
Anyware had no idea about that before???
I believe anyware knew that before and took the challenge.
So I think if "mistake" is not the good word "failure" may correspond
better...
But I respect all of your acts and I'm not here to give you lessons I'm
just sharing the disapointment of that failure that is not the first in
the opensource world...
> What is needed isn't "would like" or "we may" but "we do".
How much developer do you need to preserve lepido?
We also have short resources (we are two plus two students on TS) but we
can examine helping soon if it can save lepido.
> And as far as our reputation is concerned, I think that what we've done
> for more than 5 years now in Cocoon made it strong. And having one
> project failing, learning from it and explaining what we learned like I
> did above won't damage it.
I'm happy for the success of opensource in the economic world including
anyware's one...sorry for "me the first"..I'm not a forum addict
anyway...and the few I know about it make me believe anyware is a good
company...
Sylvain Wallez a écrit :
Stephane wrote:
Ok I will wait for anyware descision then....
I hope they will not kill lepido...
I don't understand how a such company can take a such descision
(making an eclipse subproject) without knowing if they have resources
to assume this project... Do they have any strategy? any
plannification?...
Do you know what open source is and how it works?
This should'nt be a good point for anyware reputation (and as far as I
understand they intitiate lepido precisly for their reputation on
cocoon technologies...: They will have exactly the contrary if they
kill lepido!!! (cocoon community forums will handle communicating this
terrible mistake! me the first!!!)
Tell us where is the mistake: keeping a project asleep forever, giving
the false hope it may one day come back to life, or be honest,
explaining that we have no resources to dedicate and that lack of
interest and/or resources from other parties that expressed initially
their interest lead to the archival of the project?
The mistake, if it's one, may have been to not realize at the start of
the project the huge difference there is between opensource projects
related to development frameworks (such as Cocoon) and opensource
projects related to tools (like Lepido). Now one learns from every
mistakes he makes. We did, and hopefully what follows shows it.
When someone uses a framework, he has to know how the framework
functions, and his code is close to the framework in that it uses its
concepts and classes. What that means is that transitioning from using a
framework to contribute to a framework is "just one click away": open
the source code of the framework classes you use in your own
application, and start hacking, and then contribute your modifications
back to the community.
When someone uses a tool, he just has to know the "user manual" of that
tool, i.e. where to click or what to type to activate the tool's
features. When something in the tool doesn't work as you expect, or if
you'd like to add a new feature, the technological gap between what you
use the tool for and the tool's code is incredibly large (i.e. knowing
Cocoon doesn't give you Eclipse plugin development skills).
Additionally, we realized that the "return on investment" of
contributing to tools is very different from contributing to frameworks.
Contributing to a framework is often related to an actual project need.
Instant ROI because you can deliver your project better or quicker.
The ROI is very different with tools: it comes both from the increased
productivity it gives you, and the potential new contributors and
business coming from and enlarged user base of the framework, because it
is more accessible to new users. Now in our case, the increased
producivity may not exist: I type sitemaps way faster as source code
than with a GUI.
Now the concept of "tools" and "framework" itself has to be considered
relatively to your actual projects: if they are about building webapps
with Cocoon, Eclipse plugins are tools. But if your projects consists in
building e.g. reporting tools, then something like BIRT is definitely a
framework. This relative definition of the concept shows up in the
contributors on the different projects: contributors to Apache are on
the server side of things whereas companies contributing to Eclipse are
tool vendors.
Finally, I'd like to comment "me the first!!!": who are you to
criticize? Have you spent time, energy and sweat to build something
great for the benefit of the whole community? If you use Cocoon, do you
know how many hours of my and other's people time are running under your
fingers? And since you talked about my employer, how much money this
represents?
So please be at least respectful with people that provide you with free
tools that you use in your job.
Currently my company would like to become an GMT contributor but If we
develop we may examine contributing to lepido...
What is needed isn't "would like" or "we may" but "we do".
So please anyware guys think about the community and your reputation
and keep lepido alive!
The "community" as you say is not about a single company or group of
people giving to others. It's not about seeders on one side and leechers
on the other side, but about everyone participating, according to their
skills and available time. You should read the discussions that are
going on currently about "open development" (see [1] and [2] among
others), as a reaction to the term "open source" being watered down by
companies that use it as a marketing tool.
Sylvain
[1] http://feather.planetapache.org/?p=46
[2] http://kasparov.skife.org/blog/2006/03/07/#open-development