incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alfredo Abambres <alfredoabamb...@gmail.com>
Subject Re: Wave and Incubation
Date Tue, 17 Mar 2015 11:03:26 GMT
How can you retire something that is already dead? (*not kidding*)

How many years more will the "Apache Wave" community keep lurking around
instead of accepting the inevitable. Remove the elephant of the room, so
new things can arise, elsewhere.

Let Apache Wave burn once it for all... Let Wave move on to greener,
out-of-control, chaotic new pastures - from there, someone will probably
figure it out a possible future to Wave or part of it.

*Thanks to all Apache contributors and Apache org for hosting and
maintaining Wave all over these years* but is now clear that "this" isn't
working. The existence of Apache Wave is creating a psychological barrier
(prison) to *all current active contributors* (even if themselves don't
want to admit it). Free them up... PLEASEEEEE.

Happy new year guys (and gals) :-)

http://alfredo.abambres.com

*"Moving, always moving, and living inside movement". Rainer Maria Rilke*

On Tue, Mar 17, 2015 at 7:46 AM, Pablo Ojanguren <pablojan@gmail.com> wrote:

> +1 to build a community is to help new developers start using the code, so
> better documentation is needed. Also to make clear the options and benefits
> for using Wave protocol.
>
> Answering Thomas, the client-server communication of my forked Wave is
> exactly the original, no changes in the protocol are made.
>
>    - Client is exactly the current Wave's code, without GWT user interface
>    parts, and with a Java/Android websocket/http client replacing the
> original
>    JavaScript one.
>    - Server remains equals.
>
>
> The Wave platform including the general JavaScript API:
> https://github.com/P2Pvalue/incubator-wave
>
>
> Experimental port of the Wave Client to Android:
> https://github.com/Zorbel/swell-android
>
>
> 2015-03-17 2:56 GMT+00:00 Francesco Rossi <fra@schermaontc.com>:
>
> > Again as a new member of this list I surely act on a limited knowledge of
> > prior situations.
> > Still, I personally would not opt out of Apache.
> > Several reasons:
> >
> >  * building a community around Wave it's something you can take on both
> >    on Apache or on Github, and nothing would actually forbid us to
> >    create a GitHub forks like many other have done
> >  * Apache is an advantage in terms of credibility: if you're just
> >    another gitHub project are you really sure you'd get more dev.
> >    traction?
> >  * I think the problem is rather in the dev. of the code rather than
> >    the platform it relies on (although I understand QA and proceedings
> >    on Apache are way more strict)
> >
> > My personal experience so far: we are interviewing and hiring coders, as
> > well as getting feedback form friends that have been in the dev. world
> for
> > long. Essentially the feedback and the biggest reason of scare to them
> has
> > not been the code per se but the lack of clear documentation about it.
> > This feeling of uncertainty has scared many. Still Wave fascinates many
> > others for the possibilities in this project.
> >
> > So i'm wondering: could it be that part of the problem is actually
> related
> > to opening up a little more to the community, via a better way to access
> > the information related to Wave itself?
> >
> > thank you
> >
> >
> >
> > On 3/16/2015 7:13 AM, Upayavira wrote:
> >
> >> To have demonstrated the community's knowledge of how to make Apache
> >> compatible releases, and to have shown a stable and sustainable
> >> community.
> >>
> >> These are the most important, regarding Wave.
> >>
> >> As a community, we've sat back and waited - we've not really put any
> >> effort into attracting new talent. When people with big bright ideas
> >> come along, they seem likely to implement them elsewhere because the
> >> Wave codebase is too complicated.
> >>
> >> Now, the most important first step is getting a release out. However,
> >> because I've seen the release be attempted a lot of times, even if a
> >> release was made, I'd have sizeable expectations about how regularly
> >> they are going to be done. That is, it isn't about getting a release
> >> out, it is about knowing how to do it, about demonstrating that, and
> >> about having a community that is pulling behind the task of producing
> >> software worthy of release.
> >>
> >> Given the size of the community around the WiaB product, it seems best
> >> to move to an alternative hosting setup without the strictures that
> >> Apache does place on a project. These strictures make life harder for a
> >> developer in order to make life easier for a user. However, right now,
> >> Wave needs to be focusing on developers, not users.
> >>
> >> As to Apache as a place to keep protocols, whilst Apache has held some
> >> protocols, it isn't a standards organisation. Where it has done so, it
> >> is only by virtue of maintaining the reference implementation of the
> >> standard. There will be other places that could be done in a way that
> >> allows multiple implementations.
> >>
> >> Upayavira
> >>
> >> On Mon, Mar 16, 2015, at 10:24 AM, Yuri Z wrote:
> >>
> >>> What are the technical requirements for graduation?
> >>>
> >>> On Mon, Mar 16, 2015 at 11:39 AM Vicente J. Ruiz Jurado
> >>> <vjrj@ourproject.org>
> >>> wrote:
> >>>
> >>>  El 16/03/15 a las 08:35, Christian Grobmeier escribió:
> >>>>
> >>>>> I would like to highlight that retirement does not mean end of life.
> >>>>>   There is a chance thing will get easier once on GitHub. Don't
> >>>>> forget, Apache is not only a great community, it's also a set of
> >>>>> rules, frameworks, restrictions and so on. It's do-able for a bigger
> >>>>> community. But the Wave community hardly is able to allocate time
to
> >>>>> do that final step with the release. No offense, I know for myself
> >>>>> how hard it is to allocate time.
> >>>>>
> >>>>> In a GitHub environment, Wave would have done that release already
> >>>>> (or most likely).
> >>>>>
> >>>>> I agree, that protocols may have a good place at Apache. But just
> >>>>> because retirement is not successful this time does not mean it's
> >>>>> not successful another time. If Wave can build up a community, it
> >>>>> can always come back to incubation.
> >>>>>
> >>>>> However my feeling says, you need to make access easier to Wave.
This
> >>>>> means also the full power of pull requests, which we only offer
> >>>>> partially.
> >>>>>
> >>>> Hi there:
> >>>>
> >>>> At this moment, I see Apache Wave mainly as a protocol, so IMHO Apache
> >>>> is a good place for something like this.
> >>>> So I vote to stay and to avoid the "forking nightmare" of a protocol.
> >>>>
> >>>> If not, we should find another organization, different than "github".
> >>>>
> >>>> Meanwhile, I'm close to release a new version of kune with a totally
> new
> >>>> user interface:
> >>>> http://kune.cc
> >>>> https://github.com/comunes/kune/
> >>>> I think that kune is a good example of how Wave can be integrated in
> 3rd
> >>>> party software. I try to maintain minimal differences with the Apache
> >>>> Wave code and Wave for us is just some more maven dependencies.
> >>>>
> >>>> The main goals of Apache Wave and kune are different. I'm trying since
> >>>> 2002 to build collaborative spaces for any kind of project/area (not
> >>>> just FLOSS projects), like a "social multipurpose github":
> >>>>
> >>>> https://en.wikipedia.org/wiki/Ourproject.org
> >>>>
> >>>> I started to develop kune in 2007 and using the same
> >>>> technology/frameworks than Wave, when Google released wave, I just
> >>>> replaced our non-concurrent editor with Wave. So I'm playing with Wave
> >>>> code, since the first FedOne release.
> >>>>
> >>>> For some stats of code, etc:
> >>>>
> >>>> https://www.openhub.net/p/apache_wave
> >>>> https://www.openhub.net/p/kune
> >>>>
> >>>> kune.cc is in production since four years ago hosting 20.000
> documents,
> >>>> 90% are waves.
> >>>>
> >>>> When some developer/contributor arrives to kune, I'll always try to
> >>>> suggest to start contributing to wave, but til now, people prefer to
> >>>> talk than to walk (or code).
> >>>>
> >>>> Sorry for the "ad block", but I think that clarifies my point.
> >>>>
> >>>> Greetings,
> >>>>
> >>>> Vicente
> >>>>
> >>>>
> >>>>
> >>>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message