incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blossom <jblos...@gmail.com>
Subject Re: Incubation status
Date Sat, 07 Dec 2013 22:18:57 GMT
Good points, Bruno, I think that you summed it up very well. I'd only add
that in theory the broader Apache community should act as a draw for the
project, but the social infrastructure for Apache doesn't seem to amplify
that value for Wave. A more flexible approach might help to get a core
group of people more jazzed about making a core capability take off. I can
see where at some point folding back into Apache might be a reasonable
option, and I was hopeful that the Apache framework would help to
accelerate team-building, and the core Apache people we've dealt with are
great, but somehow the combination of culture and collaboration tools
hasn't hit the mark for Wave.

Thanks, John

On Thu, Dec 5, 2013 at 10:09 AM, Bruno Gonzalez (aka stenyak) <
stenyak@stenyak.com> wrote:

> Hi all, sorry to reply this late, but here's my point of view.
>
>
> Legal point of view:
> From my understanding, being at Apache, and following its strict
> policies, should in theory attract serious companies to invest money
> into the project, being reassured that the legal risks are minimal.
> Unfortunately, not much of the sort seems to have happened yet. I
> personally think that, on the contrary, it has in part contributed to
> wasting precious time. What I mean is that, I'd much rather have a
> 50%-legally-sound and alive project, than a 99%-legally-sound but almost
> dead project.
> If the project had 10 people devoting their spare time, parallelizing
> efforts in several planes (one of them the licensing issues), then maybe
> it wouldn't be such a burden to keep up with those policies. But it
> breaks my kernel to see the most valuable contributors having to deal
> with random icon licensing stuff.
> In this regard, my vote would be: in favour of leaving Apache.
>
> Social point of view:
> The "Apache" name surely is known by many people. At least in the
> developer community. This could more easily attract them to the project.
> But given the total amount of project we have really working on the
> project, I'm not sure whether the 'Apache' name is actually better than
> simply having the code at github with actual p2p VCS capabilities.
> For that, my vote would be neutral at best, and leaning towards leaving
> Apache.
>
>
> Technical point of view:
> A big point for staying at Apache is that we have a big infrastructure
> already in place: issue tracker, code repository, wiki, mailing list,
> possibility to use virtual machines for free, etc.
> However, that's also the problem: being provided and maintained by a
> third party (from the point of view of our project), means there's no
> flexibility as to what VCS we want to use (a read-only mirror at github
> is missing the whole point about git), what communication medium to
> officially use (the dogfooding argument), etc.
> This is what I've had the closest (though scarce) experience with, and
> in my case, I feel it has slowed me down, having to divert potential
> coding time into non-important stuff. I don't know how much time, but
> surely > 0.
> For that, I'd vote in favour of leaving apache.
>
>
>
> All in all, and unless things can be done in a different way while still
> staying at Apache, my opinion is that we would prolly be better off
> outside Apache at this point (in the future maybe it'd be better to go
> back, but I don't see how things could get worse by leaving Apache now).
>
>
> On 11/28/13 11:02, Christian Grobmeier wrote:
> > I believe it makes sense to discuss if the incubator is the right place.
> > Incubation has a specific goal: forming a team which can do releases
> > and is - in a way - active.
> >
> > I see there is little activity at all. The only person i have seen
> > working on the codebase recently was Ali.
> > He also was the release manager of package which had trouble to
> > receive the necessary votes from its own team.
>
>

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