Better participation. A lot more people know how to use GitHub's tools. It'll likely increase the amount of development, participation, pull requests, etc that ASF projects get. Does it matter that GitHub themselves is not open source?
It matters a lot actually; a lot of free-software/open source software are licensed that way because the projects themselves are ideologically predisposed.
While that does not hold true for certain (even large) projects like Linux, it certainly holds true for Apache (historically) and GNU.
To put it another way; if you found out GNU coreutils were hosted on Window machines using IIS web servers then you would probably consider that the people making the software (or, certainly those hosting it) are ideologically at odds with the project and are hypocritical.
So, I mean, you get to choose, if you go the Linux way and say "we are open source for pragmatic reasons" then there's no doublethink. If you say "we believe that all software should be free" while simultaneously forcing your users to contribute using closed source software on a proprietary platform then then you're not practicing your ideology, and worse; you're forcing that non-practice on your developers and users.
Do you somehow consider copyleft style licenses "more ideological" than those which are not? That is probably more telling about your own views on licensing than it is on ideologies.
FreeBSD is not copyleft, and they work actively on eliminating GPL from their base. Debian mostly under the free software umbrella, but welcomes BSD code in their base.
Stallman is about as idelogical as you can get but has been known to argue for the MIT license in some cases. Just to mention a few examples.
Of course you can decide not to release your code under a free software license, but that rather defeats the purpose of running a free software project ;-)
Looking at it another way, more permissive licences grant more options to downstream users than copyleft licenses. It doesn't make sense to argue that you are offering only copyleft licenses to benefit those downstream users individually (and I know of nobody who makes that claim). Instead, the argument is that it is better for the group that everybody has equal restrictions and can't use proprietary code to gain an advantage over everyone else.
This is actually one of the reasons why if anyone asks me to assign copyright for my side projects over for work, I'm happy to do so: on the provision that all of my work is licensed under the GPL. It barely matters to me at that point who owns the copyright (though to protect yourself further you should ensure that no one person has copyright over the entire work).
IMHO, although the choice to write free software at all is often ideological, the choice of using a copyleft license or not is usually pragmatic -- at least among those who understand why copyleft licenses are written the way they are.
Mind you, we maintain private mirrors and have restrictions on some of the GitHub access/workflows (eg. ICLA on file, and 2FA required). We still need to track provenance, and must be able to operate independently, if it comes to that.
-- Greg Stein
-- Greg Stein
The fact that Github itself is not F/OSS matters even less as Github is the only user of Github's source code [1]; they're the copyright holder and unencumbered by any licensing restrictions.
[1] For GH's on-prem enterprise product this does not apply and has a much stronger case to be F/OSS since now GH is using copyright to restrict the freedom of others.
Does GNU audit every contributor to its libraries to ensure they only personally use open source hardware/software? If not, then I'd have a big issue the ideology stance of these organizations.
> So, I mean, you get to choose, if you go the Linux way and say "we are open source for pragmatic reasons" then there's no doublethink. If you say "we believe that all software should be free" while simultaneously forcing your users to contribute using closed source software on a proprietary platform then then you're not practicing your ideology, and worse; you're forcing that non-practice on your developers and users.
With that same rationale, it's also doublethink if every system that an ideologically-aligned FOSS isn't using FOSS based systems. And realistically, this is not how the market works and makes it extremely limiting to find contributors to maintain systems in longevity.
Kind of reminds me of the discussion around people going personally carbon-neutral. Are you going to realistically audit every interaction you have every day to ensure the level of carbon you are consuming? No, you look at the largest/most material areas that you can control and use alternatives there.
From a pragmatic standpoint, if (theoretically) running on Windows/IIS allowed the GNU coreutils project to save enough money to _actually further their goals_, I'd say they'd be foolish not to host that way.
When taking an ideological stance, there are practical considerations to consider. There will always be more and less effective ways to get one's point across.
I'm reminded, a bit, of this comic: https://thenib.com/mister-gotcha. Sometimes, you have to participate in the thing you're rallying against, because it's the most effective way to gain traction for your cause.
That's for Apache to decide, but consider:
Git itself was written, by Linus Torvalds, because Linux (the kernel) was using non-open source version control at the time called BitKeeper, and the non-open source nature of it was causing increasing problems in the Linux developer community, both ideological and eventually practical problems too, caused by the licensing preventing some devs from building tools.
When Git was written and the Linux kernel devs jumped to it en masse, it was like a breath of fresh air.
BitKeeper has credit for many of the ideas found in Git before Git. (Aside: credit also should go to Mercurial for ideas). One of the things that made Git better than BitKeeper was people were free to build more tools on it, which is entirely due to the open vs. closed source licensing, as well as a general attitude of welcome vs. unwelcome towards those tools.
GitHub is different because it already builds on Git, and works with tools that anyone can build on top of Git.
But some things which are really essential to thriving developer community are locked away in GitHub, so it's still limiting what people can build with it. (For example, can you innovate on how Issues are handled? Somewhat, but not in every way that is useful.)
In some ways GitHub is like any other walled garden. You can't fork it yourself.
Both was sprung in large parts from Linus' description of what requirements he had in order to consider using a version control system for Linux.
They were both released extremely close together, and I don't remember why I associate Mercurial ideas as being something Git learned from. Maybe I'm wrong about it.
I think Linus said at some point that if only performance would have been sufficient for the Linux kernel, there would have been no git (but don't quote me on that).
The very specific flash-point was Linus throwing an unjustified hissy-fit defending Larry McVoy of BitKeeper being difficult about Andrew Tridgel (Tridge of Samba fame) "reverse engineering" the data traffic of Bitkeeper for inter-operability (really just sniffing client packets with wireshark or something).
Whether the name "git" pertains to Tridge or Linus himself who in retrospect decided he acted like a spoiled brat is still not known :)
He connected to a BK port and typed "help". BK helpfully output a bunch of protocol help. He used that to implement something minor (I think for archival?) and McVoy wasn't having it.
It wasn't even "wireshark", but simply a telnet session indeed.
I was there, and I was told in private mail by the author of BitKeeper that I did not have permission to use it, because of my work on respository analysis software that looked like it would get too close for comfort.
That's without any reverse engineering. I never used BitKeeper, or connected to the server, or read the infamous "help" text.
It meant I couldn't participate in kernel development in the same way as most folks.
I wasn't the only one, and that's what I mean by practical problems, not just ideological.
I wanted to point out that it was not a very loose "pragmatic and/or ideological" argument back then, but there were very specific actions and respected actors involved.
You obviously, being directly involved, are aware of the specifics, but it might be easy for a casual reader to place it in a "Ah, the Free Software people were ruining a good free thing even back then" context, whereas pretty much the opposite happened.
[1] and you too, by implication, for which my apologies as well.
That's interesting. I read your comment as making out that it was _merely_ one person (Tridge) who had a problem with BitKeeper and BK didn't deserve the flak, but I read your later comment as making out that BK did deserve it.
But GitHub doesn't have this problem.
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.
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.
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.
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.
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?
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.
"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.)
That said, your point still stands.
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'm very glad to hear of the fallback mechanism.
And yes, lots of our communities have been asking for better GitHub support (read: access to its tools). So we made it happen for them.
-- Greg Stein