Hacker News Reader

Comment by im3w1l | Hacker News Reader

They give up their autonomy in moderation - Github will now have the power to say "you are not allowed to contribute to Apache projects". This will lead to

a) Github will have leverage over the project.

b) They make themselves vulnerable to the outrage du jour. If an outrage mob forms against someone in the Apache Project, Github may kick them off their platform - they are known to have done so in the past. Apache will then have to decide what to do. The path of least resistance will be to just let them go.

People who anticipate such a course of events will have to live in constant fear of all their effort coming to waste and their community being pulled from them by an outsider. And people who anticipate such fear may never join in the first place.

View on HN

To all you who think this idea is unfounded or dramatic, remember that this is the entire point of FOSS. Whether this idea holds water is irrelevant, it's aligned to FOSS and it's strange that they don't appear to care or have valued other things over it.

It's likely that they care, but consider the provable improvement in contributions to open source and thus a demonstrable benefit to the community to be worth more than a theoretical possible eventuality that most would consider unlikely at best.

All projects that I have closely observed that went to GitHub for FOMO have NOT gotten more contributions afterwards. Among the real reasons are:

1) Every OSS project has its bureaucrats who contribute a modest amount of code but want to have an immodest amount of power. For these bureaucrats GitHub is like heaven: They appear productive, have power to silence discussions etc.

2) They work for someone or know someone who is associated with GitHub or in the Microsoft embracing strike force.

3) Legitimate reason: They want to show their employers a metric how much they contribute.

I'm pretty cynical about the current state of OSS. Major idealistic contributions are a thing of the past. It is all about attaching oneself to a project, get hired somewhere and then stop contributions.

Hmm based on this, the .org tld and the server providers can have control over the project too. Right? If so, we should use an open source distributed protocol.

For what it's worth, the conditions for termination from the Public Interest Registry (.org's registry) are slightly better than Github. PIR has a five-items list of possible reasons: https://pir.org/policies/org-idn-policies/takedown-policy/ while "GitHub reserves the right to refuse service to anyone for any reason at any time."

"Deems necessary, in its discretion ... to protect the integrity and stability of the registry" sounds extremely vague, though.

> Hmm based on this, the .org tld and the server providers can have control over the project too. Right?

No, pretty obviously not. For the domain, this has already been answered. For the servers, it's trivial to move your setup to a different hoster with no visible effects to the outside.

> If so, we should use an open source distributed protocol.

Like ... git and email? Yeah, we should.

Git and email isn't sufficient, surely you need a repository as well, a listserver in your implementation I guess?

A respository and a listserver are not protocols.

Also, with git you have a repository as soon as you start using it. If you mean something like a centralized repository server: No, you don't actually need that. You can serve a git repository from your workstation just fine for others to pull from. Or you can just move changes around via email.

Also, there are way more ways to use email than for mailing lists. You could also use it as a transport for machine-readable messages between git frontends or whatever.

In and case, I don't get what point you are trying to make.

It sounded like you were saying "instead of using GitHub (with git obviously), you can use just git and email". My comment was basically trying to say "without a repository how will people find you, how will they catch up on recent dev, how will they view past emails, etc., unless you have a central repository of some sort".

I'm not sure how "just give people direct access to my local git" fills that massive hole, so I assumed your mention of email included implicitly something like a listserve. Otherwise your suggestion seems entirely unworkable to me?

So one of us is missing something. Are you really proposing p2p git + email alone with no other infrastructure? Do you think that's at all optimal?

I'm not saying there is anything necessarily wrong with a centralized repository server or a mailing list, but I just wasn't talking about software, but about protocols, which can be used in that way or other ways.

Though it is maybe useful to distinguish "central repository that publishes the authoritative version" and "central repository that contributors push to", two functions that GitHub kindof purposefully confuses.

The former is what is useful for discovery and catching up, but doesn't need accounts/authentication (for the "public side" of things), it just needs a stable public identity and availability. The latter is technically completely unnecessary with git: There is absolutely no problem with merging a branch from a repository hosted on a completely different server than the authoritative repository. It's just a business decision of GitHub to build a closed system that requires you to enter into a contract with them in order to submit a merge request that is limited to branches hosted on their platform, to create an artificial network effect for their platform.

After all, the primary problem is not that people choose to host a project on GitHub. It's that they demand (or allow GitHub to make that demand with them as voluntary hostages) that you also host your branches on GitHub, or else you can't contribute. If I am a happy Bitbucket customer, or I happen to run my own git server, there is no way for me to submit a merge request to GitHub specifying a branch hosted whereever I happen to be hosting my git repositories.

But no, I was not suggesting any particular implementation, I was just pointing out that those two protocols do exist and can be used, in many ways, as a basis for decentralized Free Software development. And while p2p git certainly is not the solution to all problems, it can be a perfectly useful tool--and with some more tooling around it possibly moreso than what is practical today.

Even if it were true, this isn't the "entire point", or at least not to everyone. You're talking about communities that have diverse interests, and only a subset of those people are into avoiding all dependency on commercial software in the FSF or Debian sense.

"FOSS" includes Windows developers, Mac developers, iOS developers, Java developers, people working for bigtech corporations, and some bigtech firms themselves. (Some parts of these firms some of the time, anyway.)

it seems you confused commercial with non free software. Java may be a commercial product, but it is also free software and the FSF and Debian are happy with that. They do not reject commercial software quite the contrary.

That said, your point still stands.

That is simply not true. Please take your conspiracy theories elsewhere.

Apache maintains clones of all our GitHub org's repositories. GitHub has no leverage over our repositories. We have a fallback mechanism for contributors to push to our server, if they deny GitHub T&Cs.

Apache has the support of GitHub and Microsoft, from the CEOs of both, and through the organizations.

-- Greg Stein

I don't think it's a conspiracy theory, these things happen all the time.

I'm very glad to hear of the fallback mechanism.

Reply on news.ycombinator.com