How it becomes toxic most of the time? Sociopaths will always have an edge to be on top of self centric pyramidal organisations. And those who starts nice people tend to get corrupted by the system which favor attempts to breed, threat and decive the small surface area in the center of the concentric power construction. Exceptional beings can certainly be pointed to show this is not the absolute fatality. Probably far rarer than sociopaths ready to harass them though.
Honestly, pretty sociopathic behavior right here.
You’re not exposing any new ideas. You’re just attacking.
There is no need to pretend for novelty in such a critic, indeed. Just because we don't reinvent it on the fly doesn't make the use of arithmetic worthless.
And they weren't free until 2020: https://docs.github.com/en/get-started/learning-about-github...
https://en.wiktionary.org/wiki/bruh for those who also wonder.
To the risk it might seem surprising, I actually completely agree that trust is essential to software creation and and use.
Actually I would more broadly frame it as, no trust, no viable sustainable society, no technical/cultural artifact.
But trust and societies can be realized without individualism as underlying chief paradigm.
That doesn't mean total negation of individual though. One alternative, among others yet different approches, can be state as a metaphor of individual like a cell in a social body. Thus the term metastasis, as when a cell starts to degenerate in self centric behavior at the expense of the health of the body as a whole. On the other hand, no cell, no body.
If I remember correctly, it was also one of the few places sticking to the now-standard passing of the parameters via path rather than the '?' URL query part.
It might not seem like much now, but then the ease and simple beauty of having just github.com/user/repo - not only for web access but also cloning - was definitely some freshness factor.
1. not use query params for key entities in the URL
2. to stick user identifiers at the root path! totally unheard of to occupy such an important path at that point!
Taken together, this was entirely novel. Next to nobody did this. Twitter was the one other notable example, and that's literally all I can think of.
The URL bar was so different back then. It wasn't search by default. The average tech savviness of internet users was higher. People cared about URLs despite the fact most websites had garbage cgi-bin query string slop. Lots of folks had personal domain names. People typed URLs and shared them a lot - so this was a big deal, because they were memorable, unlike the other slop URLs at the time.
To give more character - HN's urls would have been considered exceptionally nice back then. The average URL was way worse and was littered with hundreds of query parameters.
A great deal of websites put your session token in the query params. PHP had first class ways of spending "sessions" to all urls. Essentially a cookie. It was disgusting.
GitHub revolutionized urls as a product. Even today, not many companies followed suit.
They're still the gold standard.
2nd level would be yourname.com.
3rd level would be yourname.site.com, like LiveJournal and Blogspot had a long time ago.
4th level would be site.com/yourname, like Myspace had a long time ago, and Facebook had after that, and Github had after that.
Once you sink all the way down to the obscure depths of 4th level, there's not much difference between site.com/yourname and site.com/whatever/yourname
Very few companies do this. Github and Twitter are some of the only ones. And they were certainly incredibly novel at the time.
Back in the 90's and 2000s, URLs looked disgusting. Remember this [1] nonsense?
[1] https://www.php.net/manual/en/session.idpassing.php (see "example 1")
That may be, but the user I responded to said "top level". Anyways, what looks disgusting about:
yourname.livejournal.com
yourname.blogspot.com
myspace.com/yourname
?
This was all before github, so objectively not novel by then.
The Fediverse makes it much easier to broadcast updates in a truly decentralized fashion. Maybe this can be the discovery layer instead of requiring a centralized social network in GitHub?
Git itself has many of the primitives needed, but issue tracking and CI/CD seem the main pieces still lacking. Seems likely that issues can be solved satisfactorily both natively in git, or in the fediverse. I bet that agents can pass branches/patches amongst themselves just fine, maybe native git (pulling from each others’ remotes on a crontab, or sharing patches by listserv) is actually completely viable now.
I also wonder if agents will cause a shift from forking and contributing back upstream, to more like horizontal gene transfer where people or tight teams broadcast their repos and other projects borrow/steal whatever may be useful. You see this with the Claws where maintainers are simply swamped with contributions and no way to verify whether they are correct/positive. (Things like “first time install on a Mac mini breaks at step 7, due to some iMessage issue” are fiendishly difficult to automate”)
To me one of the clear things that GitHub gave us was a structure around a person rather than a project. To me it felt liberating to quickly create a repository attached to my name than it was to go through the (what felt to me) very serious process of coming up with a project name and reserving it on sourceforge just to get a cvs or svn repository (along with website, mailing lists, issue tracking(?), etc, etc...). It felt like the mental load of "oh this is just a quick thing" was a lot easier with github.
> It gave projects issue trackers, pull requests, release pages, wikis, organization pages, API access, webhooks, and later CI.
Although it didn't give us this all at once. I still remember when we created a new user account in order to simulate an organisation, before they existed. I distinctly recall discussing with friends if we wanted to set up a bug tracker software for our project with the assumption that "GitHub will probably release one in a few months anyway". In the end we just kept a text file committed in the repository. Issues were announced a few months later.