Subject: Re: Download libssh2 source via HTTPS?

Re: Download libssh2 source via HTTPS?

From: Alexander Lamaison <>
Date: Wed, 4 Mar 2015 20:24:37 +0000

On 4 March 2015 at 13:34, Peter Stuge <> wrote:
> Daniel Stenberg wrote:
>> Personally, I wouldn't mind switching over to hosting the source code repo
>> at github
>> All in the name of going where there's already a large amount of
>> users, it brings features and it encourages and simplifies collaboration
>> even further. Do it "like the kids do".
> Since when was being mainstream ever a good thing?
> GitHub Inc. is a privately held company in the USA. I don't see how it
> could be beneficial in any way for the project to give up its independence.
> As for barriers - have you read the ToS recently?
> The very first point is:
> A. Account Terms
> 1. You must be 13 years or older to use this Service.
> How about that for a barrier? If I was growing up on the internet
> today, I might want to contribute to libssh2 also before I'm 13.
> It is not common - but I think lowering the barrier is really important.
> 3. You must provide your name, a valid email address, and any other
> information requested in order to complete the signup process.
> That sounds like a significant barrier to me.
> "any other information requested" - and a completely arbitrary
> barrier at that.
> 7. One person or legal entity may not maintain more than one free
> account.
> That too sounds like a barrier to me.
> Please read those terms again. I think they are absurd.
> (But I know that they are absolutely required, because the service is
> operated by a US company.)

I understand why you disagree with some of these terms - I do too -
but it's taking it too far to say that we cannot rely on any US
company. That may give us 'independence', for what it's worth, but
also leaves us out in the cold, unable to take advantage of new
advances in collaboration and cloud services.

And the reality is that we don't have to lose that independence at
all. If we mirror our repo, we mitigate any possibility of being
denied access to our own source code. Not that that was a reasonable
likleyhood anyway, because, Git being Git, someone would have had an
recent clone.

As for your concerns about barriers, it's a stretch to take them
seriously. No-one has to sign up to GitHub with a name or valid email
to clone code. Nor to make a change, and email a patch to the mailing
list. So our theoretical 13-year-old is not prevented from
contributing exactly the way they do today. It is true that they
would not be able to create a GitHub account and fork our code and
submit pull requests, but they already can't do that, so they lose

There are two theoretical ways this could negatively affect anyone:

- Project committers would be subject to GitHub's T&Cs.
That would mean they would have to give their real name and email
address. In a security-focussed project I welcome that. I would be
uneasy if anyone with they keys to the codebase refused to identify
themselves. A number of crypto-based projects (e.g. Truecrypt [1])
have realised that anonymity and trust do not go hand in hand, and now
insist on real identities. That said, nothing would prevent anonymous
people _contributing_ to libssh2, they just couldn't be committers.
Also, comitters under 13 would not be allowed. I'm pretty sure we can
cross that bridge if we ever come to it.

- People filing issues would be subject to GitHub's T&Cs.
This is probably the only concern that exists in practice. Anonymous
issues would not be possible. Nor could they be from under-13s.
However, that does not prevent either of those categories of people
from emailing the mailing list to report a bug. Many people do it
this way anyway.
Oh, and apparently there's a workaround for this too [2].


>> And it makes the infrastructure less dependent on individual volunteers.
> If we had been having lots of problems with the infrastructure I agree
> that this would have been a good argument. But I don't think that we've
> had so many problems that we need a change.

Git has gone down from time to time. It usually comes back up before
a few hours but it's still annoying. Trac has never been great,
especially manually moderating the tickets, which has been a disaster.
We were allowing bug reports through in 6-month chunks. By then the
reporters have lost interest and conclude our project is dead.

This isn't anyone's fault - we're not sysadmins and we have other
things taking our time. But that's the point. Nowadays there are
companies willing to take this burden from developers. Do we really
want to keep doing this ourselves?

And all of this discussion is without mentioning the benefits of
GitHub for collaboration. It's great seeing someone fork your
project, and to be able to follow their progress and even discuss
their changes with them. This kind of engagement makes it more likely
changes are contributed back, any the quality of those contributions
is better.

You asked if being mainstream is a good thing? Not necessarily. But
that doesn't automatically make it bad.


Swish - Easy SFTP for Windows Explorer (
Received on 2015-03-04