incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Dashorst <>
Subject Re: Future of Etch
Date Mon, 06 Sep 2010 19:25:39 GMT
Hi Holger,

Thanks for your thoughtful response. The problem is not the technology
aspect but the community aspect. When etch joined the incubator the
project was an in-house cisco project with cisco paid developers.
Since then cisco dismantled the team and the members have gone to
greener pastures. What could have been a great (albeit small)
community was killed with that action: there were no non-cisco
developers working on the technology at that time. In my opinion, had
the project consisted of a diverse team, we would have been in better

When we asked you and Michael to join the etch team, we were hoping to
see discussions, commits, jira tickets filed, etc. The stuff that
makes a community alive and thrive.

>From a mentoring perspective, it is very hard to do anything when
nothing is happening. No commits means no code being contributed, no
code being contributed means no releases, and no discussions.
Attracting new committers is difficult, but if you only sit back and
do nothing, why would anybody join? How would anybody find out about
etch? An article from 2008? If you look at an open source project and
you see one commit in a year, 5 messages to all lists, would you
conclude that the project is healthy and thriving and a sound choice?

That said, if more folks are willing to make this *community* work,
I'm willing to re-evaluate the viability of etch in six months. But
we're going to need to see activity: releases, commits, discussions,
etc. All those things are necessary to create a healthy project ready
to graduate. However, sustained silence will inevitably result in an
end to the incubation effort.

As far as I'm concerned there are 2 options on the table:
 - continue incubation and re-evaluate after 6 months and strive to
become a viable community
 - stop incubation, and take the code elsewhere (github, google code,
or just in-house development)

It is up to the etch community and determine its future.


On Mon, Sep 6, 2010 at 6:13 PM, Holger Grandy
<> wrote:
> Hello Etch-*,
> regarding the current discussion: Etch is a viable technology.
> BMW uses Etch in products, and Etch has proven itself useful in productive
> environments. If you buy a Mini in the future, Etch will drive around with
> you. We are still using it, and - as I have already written in the past - we
> see good reasons for doing so. Etch provides a good communication model and
> a good architecture for efficient binary two-way RPC.
> As a benefit for the community, we have committed our C binding implementation
> with lots of code recently. Since this is company driven development, committing
> to the ASF was not a continous process. We worked on it for around half a year
> continously. If we would have used the ASF SVN repository during development, this
> "non-activity" discussion would not have happened now :) This would change in
> the future as we now are ASF committers.
> We have an interest in Etch being publicly available, under the hood of the
> Apache foundation. We want to see it in a continous development path.
> We do not want to see it retired. This project has its weaknesses,
> without a doubt, but remember in this discussion, there are people using Etch
> and there are people developing for Etch, and its not only us.
> Regards,
> Holger & Michael
> -----Original Message-----
> From: Manoj Ganesan []
> Sent: Freitag, 3. September 2010 16:33
> To:
> Subject: Re: Future of Etch
> Niclas,
> Being the mentor, you would remember the professional transition all the
> original Etch developers went through around a year back. That obviously
> hits the brakes on how fast the technology is adopted, and some time is
> warranted for the project to grow with the creators getting their
> professional lives back on track.
> The technology isn't something you can try out, and exclaim success in a few
> days. To see if Etch is a custom-fit for users, it is only reasonable to
> expect that it'll take some time and experimentation. Especially, with some
> similar technologies in existence for longer.
> It's not that the project is in oblivion. Holger and folks have been working
> extensively on the C binding and have been reporting success with the
> system. There are other questions/comments, albeit not too frequent,
> including one informing us of their success with using Etch (first version
> of NetKernel Protocol). The creators of the project use it at their
> workplace. I have been investigating Etch being the possible IPC protocol
> for our future architecture at my work.
> So there are people who are obviously using it. Why 'retire' it then?
> Doesn't the term itself discourage people from trying the technology out.
> Wouldn't it be better to retire it when it's deemed of being obsolete, or
> that it's giving Apache a bad name, or that no one is really using it?
> Neither of these seem true today.
> What do you think?
> Thanks,
> Manoj
> On Fri, Sep 3, 2010 at 1:20 AM, Youngjin Park (youngjpa) <
>> wrote:
>> I feel pain. I had full of interesting in Etch and I still have it. But, it
>> was very difficult to allocate my extra time to do this in a new team where
>> Apache Etch was not born and especially in a team having so many upcoming
>> projects in front of me. It was obviously interesting project, but it was
>> beyond my control in recent days in a new team and in a new place. Sorry
>> about hearing this.
>> Youngjin
>> -----Original Message-----
>> From: James Dixson []
>> Sent: Wednesday, September 01, 2010 10:31 PM
>> To:
>> Subject: Re: Future of Etch
>> If Apache does not like the rate of progress, then that is Apache's
>> prerogative. I do not like it, I do not want it to happen,  but I
>> personally have no energy or interest in jumping through any other hoops
>> to try and prevent it.
>> I find it unfortunate that if the project is forcibly retired that it
>> will require any other contributions to the project to be made somewhere
>> else.
>> Looking back over the last 2yrs I have found this whole incubation
>> experience to be a bit too *fussy*. Everything from the long drawn-out
>> discomfort about the "Etch" name to the continual pressure to wrangle
>> new committers, to this latest (and just a little bit patronizing) label
>> of "retirement". It is disappointing because such a label *is*
>> stigmatizing to the technology in a way that is completely not the
>> technology's "fault".
>> I do not blame any of the mentors, past or present. I blame ourselves
>> for thinking that Apache adoption of Etch would be a good thing for both
>> Etch and Apache. Instead the experience has been more like moving into a
>> gated community with an over-aggressive home-owners association who
>> wants us evicted because we are not mowing our grass twice a week.
>> I am sure you have heard this kind of criticism before (I certainly have
>> read things like this in the incubator forum). I feel I understand a lot
>> better what Apache affiliation is and will certainly think twice before
>> considering this again in the future. "Success" as Apache
>> defines it just seems more correlated with the extroverted tendencies of
>> the committers rather than the merits of technology.
>> Finally, despite it all of my belly-aching I do appreciate all of the
>> time and energy the mentors have provided. If I have offended, I do not
>> intend to, I only intend to express my frustration and disappointment
>> with the process.
>> The situation is what it is.
>> --
>> james
>> * Niclas Hedhman <> [2010-09-02 09:04:01 +0800]:
>> > Guys,
>> > we think that the non-activity of Etch is really "permanent" and will
>> > propose to the Incubator to make the project "Retired".
>> >
>> > As it is Reporting Month for Etch in September, I am suggesting that
>> > we send this message instead of fabricating a "weak" report.
>> >
>> > If you have any serious objections, now is the time to speak.
>> >
>> > As for the codebase; Anyone is free to take it and do what ever they
>> > want, within the limits of the Apache license, the SVN history will
>> > remain, but made read-only. If I new community is to emerge, they can
>> > request Etch to come out of retirement (not common).
>> >
>> > This is in no way reflecting negative on the individuals involved in
>> > Etch, as we are well aware of the challenges to bootstrap communities.
>> >
>> > Cheers
>> > --
>> > Niclas Hedhman, Software Developer
>> > - New Energy for Java
>> >
>> > I  live here;
>> > I  work here;
>> > I relax here;

Become a Wicket expert, learn from the best:
Apache Wicket 1.4 increases type safety for web applications
Get it now:

View raw message