External Package Usage

[bketelsen]

My initial thought was that we would prohibit bringing in dependencies to external packages. It's probably obvious why we'd prefer that as library authors.

Opened this issue to discuss the pros & cons of allowing external packages, and ways to mitigate maintenance risks if we choose to allow them.

[markbates]

I think it's fine to write some of the packages, however, I think it would be a better idea to find already great packages out there and try to get the maintainers to move them here. It's a win-win for everyone.

1. we don't have to write every package
2. great existing packages, and their maintainers, get exposure
3. the weight of maintaining the packages gets lifted off the original maintainer, who would be giving the commit bit for the new repo, and shared amongst many more people.
4. all of the experience of writing that package isn't lost.

[asdine]

I think it also depends on what we want to provide to users. Do we want to:

• increase productivity on common high level topics like gRPC (by providing cool middlewares), PostgreSQL (by defining methods to quickly identify common errors, ease testing), etc.
• or work on lower level stuff by defining interfaces, types, etc. that other library maintainers would implement or use ?

[object88]

My general view is that using stdlib is preferable, but if there is an excellent library that stands alone and scratches the itch, then not every wheel needs to be reinvented. That was a ... terrible mixed metaphor; I'm sorry.

@markbates idea above about moving packages here might also work; it might also depend on how commonly used that package is. I would rather point to an external reference than have two "masters" of a package. Or is the idea to deprecate the original once it's migrated here?

[markbates]

Deprecate. Absolutely.

[ScottMansfield]

If the person you ask says "no" and the license allows it, would you consider just copying it into go-commons and then working on it from there?

[bketelsen]

that's a tough question. Unfriendly forking is unfriendly. Do you have a specific lib in mind or is this more of a rhetorical question?

[ScottMansfield]

I don't have a particular library in mind at the moment, but I suspect some people may see it as losing their identity and handing control to another set of people if you ask them to move their project here.

[markbates]

It's true, I don't think everyone that gets asked will say yes. If they do, they'll be added as a maintainer on the new repo, so they're still part of it. But if someone says no, then I would say don't fork it and go and either find something else, or write a new thing. I don't think we should fork a project that someone doesn't want us to.

[ScottMansfield]

Here's the more interesting question: Why not? Would it benefit more people to have it forked? What if there was a way to group things together outside of github.com/go-commons/commons for the sake of people looking to import projects that solve important foundational problems?

[metalmatze]

I know it's unfriendly, but open sourcing with a specific license always includes the possibility of someone forking even against your will. It's just something you have to live with. In the end it probably depends on the exact case.