Principle: A proposed contribution that competes with an existing FINOS project should consider potential routes to a merger

[ColinEberhardt]

Why? Giving members the choice between different projects that serve the same use case, or implement the same standards, is considered a good thing. An element of competition generally results in an ever-evolving and improving ecosystem of solutions. However, competition can also have a negative impact whereby effort is wasted due to multiple parties addressing the same problem. While we do not mandate that competing projects become merged, this option should be considered at the point of contribution.

[stephengoldbaum]

It seems like the TSC would have the best perspective to suggest routes.

[jonfreedman]

I think this is important, but also potentially controversial, naively I would expect most organisations to view contributing an existing project to FINOS as lower cost, higher reward than merging with an existing project to build something with a superset of the functionality of both because it will take more developer time and potentially remove the opportunity to do nice things like present at AWS re:Invent

[ColinEberhardt]

I think that a strong drive to create new things exists throughout the open source community, whether you are a sole developer creating something as a hobby, or a global bank. It feels a little Darwinian, with projects competing and the fittest surviving.

I don't think it is right for the TSC to stifle evolution by trying to pick the 'winner'. I think our job is to make sure that competition is constructing rather than destructive.

[jonfreedman]

I think promoting a merger is the right thing for the principle to include, I guess we're both saying it's unlikely to be chosen very often

[rikoe]

Am I right that the project would be accepted first though (as a separate project), and the consideration/work for a merger happening later?

[ColinEberhardt]

Yes, I think that would make sense.

We have to be quite careful about what we are trying to achieve here - we don't want to suppress competition or stifle innovation. Rather, we want to avoid having projects that are in direct competition. If we can encourage the competing projects to join forces, this is better for the community as a whole. However, it does still feel like a 'should' rather than a 'must' to me. All I'd really be looking for is for both sides to come forwards and discuss potential options and what would be of most benefit to the community.

[jonfreedman]

I think it would depend, there's not much point accepting a contribution in order to work towards merging into another project. I would want the conversation as part of the contribution process to be a must with a documented outcome, the actual merger I am less bothered about. I think the only reason to accept a project x that had agreed to work to merge with project y would be if the contributing member could articulate why they are unable to proceed without FINOS support - its not like GitHub isn't free to all, open source doesn't work without us etc.

[ColinEberhardt]

via our TSC lisr - "In this scenario I would be interested in knowing how much the proposer knows about the scope of the other project, and whether any discussions have happened between the projects to understand the overlap. To me “good” here is that they have done due diligence to understand how the projects relate to each other and formed some kind of opinion, in collaboration with the other project(s) on what potential future state might look like."

[jonfreedman]

I think this is a good, sensible approach - as the TSC we'll be best placed to steer this if not already complete and everyone involved will likely learn something useful from the discussions irrespective of the outcome.