Those are great observations, Nick. Merging projects is often hard even if the developers are willing to do it, though. The projects could be already running in production and major changes could be disruptive to the point of making the merged project not viable.
Attempting to merge projects through a conversation between the two parties sounds reasonable, but I suspect that many times the two parties will prefer to at least start independently. Perhaps the incubator can do the job of bridging the conversation and making sure that the differences are sorted out before graduation and assess if a merge is possible during the process. -Flavio > On 19 Mar 2016, at 11:23, Nick Burch <n...@apache.org> wrote: > > On Fri, 18 Mar 2016, Greg Trasuk wrote: >> I don’t think it’s the Incubator’s job to choose which competing projects >> should join the foundation. All we’re here to do is to make sure that a >> community knows how to act like an Apache community, and that the artifacts >> are licensed properly. > > This is only my view, and I know that some key incubator folks think it's too > prescriptive, but I have seen it work > > TL;DR - Alternate ideas and approaches Good, Confusion or Corporatism Bad > > Where we have two different communities, working in the same space, but in > different languages or different approaches, then that's fine. The ASF > doesn't pick "winners", it picks "runners". So, having a Batch implementation > of the Foo protocol in C, and having a proposed podling for a Streaming > implementation of the Foo protocol in Java is fine. > > Where we have two different companies doing rival implementations who refuse > to co-operate, that's an issue. Two companies who are competitors, who both > read the "Foo protocol" spec / Foo paper, and who found rival projects to > implement Foo in Java, is a problem. They don't have a technical distinction, > just a refusal to co-operate and a refusal to take off $DAYJOB hats and a > refusal to work for the best interests of the community. That's an issue for > the incubator and the ASF > > If we have a similar proposed project coming in, I would expect the proposed > project to have a chat with the existing one to see if a merger is possible. > If they're in the same langauge, and take similar approaches, then a merger > could deliver a better community with more features, which would be better > for everyone. > > However, if they two communities had a chat, and decided they really were > different + could explain that, then in my book that's fine. Document and > explain those, so potential new community members can pick the "right" one > for them. Maybe collaborate on some common code / tests / etc, don't > bad-mouth each other, and help new people pick the appropriate one for them, > then that's fine. > > AcmeCorp and Contoso both want to bring a Java project for doing Foo, and > won't co-operate because they're competitors = red flag > > AcmeCorp found a Ruby project for Foo, grow it, bring it to the ASF, then a > formerly Contoso backed Java project for Foo comes, fine. > > AcmeCorp did a "Foo for 1-3 machines that's easy to get started with" and > want to bring that, while Contoso have been working on a Foo that's a bit > tough to setup for small clusters, but scales brilliantly past 3 racks, > that's fine. The can share some Foo compliance tests, and new community > members can consider their deployment sizes and pick the "right" one to join > for them > > > Only my view, though at least some others share it, I hope that helps at > least a little? > > Nick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
