curious: why use own hosting rather than github?

[yanchenko.igor at gmail.com]

Just wanted to add my 2 cents into discussion.  The beauty of open
source that anyone who has enough resources can create a fork and
maintain it, and send patches to upstream, eventually the repository
which has more contributors will become upstream itself. Those who
want to prove that github will help project can create a fork there,
and synchronize changes with upstream. If you succeed and you would
have more contributors than original project, the fork will become new
upstream,  everyone will benefit from that, If not than it will prove
that github doesn't provide any benefits.

Cheers.


On Fri, May 22, 2020 at 5:38 PM Brian Exelbierd <bex at pobox.com> wrote:
>
>
>
> On Fri, May 22, 2020, at 11:17 AM, Ondřej Synáček wrote:
> > But still, “meteorite” users would probably have to sign up for
> > account to post a Gitlab issue. If we’re debating this one, it’s the
> > friction of signing up for mailing list vs. signing up for Gitlab
> > account.
> > I think signing up for mailing list is easier and less frictionless.
>
> From my perspective it is actually the friction of a Issue Tracker/PR-based workflow versus an email/patch-mail workflow.  Depending on your background and what you do today, one is more natural than the other.
>
> Through my own lens and based on my observations (necessarily biased I am sure), the presence of an Issue tracker is becoming expected and a PR-based workflow is the default.  Many people are unfamiliar with patch-mail workflows, especially those joining open source in newer projects.
>
> Not having PRs is, from my perspective, sad and painful, but maybe OK if we have good onboarding documentation.
>
> Not having an issue tracker feels like we are losing stuff and working harder, given that this is a low-frequency of participation (by hours/week) project.
>
> A hybrid approach is what I would encourage:
>
> * An issue tracker that emails the list on new issues
> * A suggestion that issues on list be opened in the issue tracker
> * A requirement that all patches also have a tracking issue so they don't get lost
> * and, ideally a mirror repo where PRs can be submitted, even if the source of "truth" remains the same.
>
> YMMV.
>
> regards,
>
> bex