curious: why use own hosting rather than github?

[Brian Exelbierd]

On Fri, May 22, 2020, at 6:11 PM, yanchenko.igor at gmail.com wrote:
> 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.

Sort of.  I suspect that many users get their software from a distribution, not from the upstream itself.  Therefore the source used by the distributions, which will tend to be the "official" and in the absence of that "oldest" will generally prevail.

This doesn't mean forks can't be successful, it is just that, again, in my experience, Open Source has organized around them being the option of last resort, not of experimentation.

regards,

bex

> 
> 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
>