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
<v...@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
