GitHub’s motto VERY EARLY ON was “social coding”. They kept that motto for a long time.
- photos :: instagram
- videos :: tiktok, youtube
- posts :: HN, reddit, dev.to, substack, mailing lists (yes, people still use those)
- events :: messengers (telegram, whatsapp, etc), email.I.e. what Facebook used to be, before the "great social network unbundling".
https://web.archive.org/web/20080906001759/http://github.com...
https://web.archive.org/web/20080905195808/http://logicalawe...
> "social coding"
Social coding is not Github's primary function and it's hasn't been promoted in earnest, this way because it's secondary at best. Ostensibly, it's hosted git. That's the naming, the function, and most developers think of it as such. The vast majority of users are either corporate developers who work for some company and can't care less about the "social" aspects of it or insular developers with projects that never see the light of day.
Notably, this paper only sourced public repositories, where many people use it as an element of their work portfolio. This doesn't speak to "all of github".
hub /həb/
noun
1.
the central part of a wheel, rotating on or with the axle, and from which the spokes radiate.
Look at the article:
> We find that the unannounced removal of daily activity streak counters from the user interface (from user profile pages) was followed by significant changes in behavior.
> Long-running streaks of activity were abandoned and became less common.
> Weekend activity decreased and days in which developers made a single contribution became less common.
> Focusing on a set of software developers that were publicly pursuing a goal to make contributions for 100 days in a row, we find that some of these developers abandon this quest following the removal of the public streak counter.
Look at this bullshit. People doing work just to maintain their streaks. People making literally one contribution just to keep it up. That's fucked up and needs to be fixed. Nobody deserves this operant conditioning stuff.
The name is irrelevant. The vast majority use it for hosting. What someone wants or doesn't want has already been decided in the market.
Git is absolutely trivial to use in a fully decentralized fashion. GitHub and GitLabs success shows how much people don't want to run their own servers.
financial hubs don't _host_ financial institutions and their assets?
I have even seen a number of creepy screenshots from horny single men on LinkedIn sending unsolicited messages to women they think are attractive, trying to use it as a dating website.
Just focus on fixing your nightmare OS and maybe stop building nonsense everywhere...
If someone just wants to host and build code there are many alternatives (like Sourcehut). The only reason GitHub is so dominant is because of its already huge following and exploration / networking which relies on said following.
[1] https://news.itsfoss.com/gitlab-inactive-projects-policy/
Personally I am planning to move to GitHub soon. The CI limit is very small for an active project testing across a few different Python versions, I am reaching it just with a couple pushes per day.
Serious downsides to being the product include: * No means of production - whatever profit you hoped to have can simply be taken away from you. * No control over your likeness, IP * Limited legal protections * Finding yourself being sold in ways you find unethical.
I'd reconsider your planned move, unless I guess you really just don't care about your project longevity...
I don't know what you mean by "taken away from you" or "control over likeness" or even "legal protections". Code is intangible, it can be multiple places. If you're referring to Copilot, my code can already be taken whether I use GitHub as my base of operations or not...
You throw around big words that apply to other industries, but what specifically do you think I lose with software?
Tools are not made all equal, and there's this fallacy that just because it is a tool it is probably OK and as easy to use as abuse.
To borrow from the medical industry - yes, opiate drugs are absolutely useful _in specific cases of extreme acute pain_, but that doesn't make them good tools for dealing with a headache.
A tool can be bad, even if it can be used well, likewise a tool can be good even if it can be used for bad.
"Code is intangible, it can be multiple places" - you should study law, especially wrt existing legal precedents. If this were true, things like software patents would not be a problem, and I would evaluate how much you really can lay claim to your code, especially now Microsoft has played their hand here...
In a world where digital media and electronics remain an important part of every industry, and large rich tech companies exist, these are absolutely concerns, this is not some idle ideological patter. Your IP matters, (F)OSS has IP as well, that's part of why any of this matters.
Choose your blade wisely lest it cut you.
"SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such."
https://news.ycombinator.com/item?id=23038520
(And therefore, perhaps, ill-advised to recommend it as such)
A pull request, literally, need only be moving code from one repo to another.
The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means.
That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics.
E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them.
Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
Isn't that what discussion board is for? I agree that this particular topic is not life-and-death important, but still worth discussing, IMHO. If you think otherwise, just walk away, you do not owe anybody anything.
It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling.
(Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things.
Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.
If anyone is skeptical about the email workflow, here's a write-up from another skeptic:
Where did this quote come from? You just made it up?
You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?
The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
No, it doesn't, and it's dishonest try to make that move—just as it is dishonest to manufacture quotes that are designed to provide the opportunity for making the move.
"Github but just without the gamification elements" does not appear anywhere outside of your own comments and is, in fact, much stronger than what was claimed in the original comment you responded to; the person to whom you responded and to whom you were being needlessly confrontational pointed to SourceHut as an option for people who dislike gamification and are looking for a provider that is just "a place to host and build code". There was no claim about the suitability of SourceHut for anyone who doesn't meet that description, let alone anyone who requires/seeks/prefers(/whatever) "Github, but without gamification elements".
Please stop manufacturing quotes, and please stop defending their use by pleading that the "quotation paraphrases". That word sequence alone is a dense contradiction. Making up false quotes is especially troublesome when they are freely mixed into discussions where a person has otherwise already previously made use of genuine quotes (such as the way you did when quoting the creator's remarks that "SourceHut is not GitHub/GitLab/Gitea[...]"). To do so is pernicious, and the entire practice is against HN's rules.
I still think you're reading a lot into this thread that is not there, and ratcheting this up to the level of accusations of dishonesty is a pretty interesting/illuminating choice. However, I don't actually have a dog in the fight; consider all points ceded.
> I still think you're reading a lot into this thread that is not there
To reiterate the background for this discussion: a participant in this thread went a step further than what you're saying here and literally* wrote things in that weren't really there.
* literally literally, not the other kind
How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.
Part of using Github is that it's from Microsoft therefore on the 'approved' list.
Everyone should be forced to read the Linux mailing lists to see how git is meant to be used.
It certainly seems like a waste of their development time. I looks at these badges for a moment and think "neat" but nothing else. And profiles I just ignore, especially the ones people Myspace-ify...
To finish my badge collection, I need:
* Merged a pull request without a review - 100% toxic.
* Answer 32 discussions - this is a strong incentive to enable GitHub Discussions on a project, which is the wrong move
* Create a repository and get 4096 stars - diverting focus from the projects I maintain (although I'm a core contributor to a project which meets this requirement, I didn't create it)
* Coauthor 38 more commits on merged pull requests - this'll happen over time. Not a 'bad' thing, but not something I want to take time to achieve.
Genuinely curious, as I've gotten help from maintainers using Discussions.
Last month we had ~25 code contributors and ~2.32 million users. About 100,000 users per code contributor.
As a user-facing app, rather than 'open source infrastructure', we receive a very large number of support queries from end-users. A significant number of these will be users who are entirely non-technical, or don't speak English at all (looking at my last support efforts, ~20% were non-English + resolved via screenshots, videos + Google Translate).
I'd much rather have our community triage via one of: Forum, Discord, Reddit, StackExchange, Google Play, Mailing List, Twitter, or Facebook Messenger and leave GitHub for code/documentation-level discussions.
Opening up GitHub discussions adds another level of distraction to GitHub notifications, and provides little benefit in return given the existing established support channels.
By staying quiet, we're incentivising the following:
https://stackoverflow.com/questions/72662385/how-to-merge-a-...
2) Even if it was kosher, how exactly is this improving Open Source?
2. What does farming weird achievement have to do with freedom?
It seems there are people who do feel that way. I wonder if the folks who set up the badge system are all of the first type, and didn't realize that some people would be thrown completely off the rails by it.
There's a case where this is not just ok, but healthy (especially on smaller teams) - if you're comfortable doing trunk-based development then you can use a PR to "snapshot" a set of changes and either invite commentary or just have a link to share as an FYI around the change, without the awkwardness of linking to an unnamed commit sequence.
This exactly proves the central point of the article - gamification affects software developers.
I recall merging my OWN pr into my own new repo. I was surprised with a badge. No harm in that.
The idea is to increase the number of programmers, decrease the median pay rate of the average programmer, and recapture the excess capital lost from the past 60 years of nerd-shaming that led us to consume more code and tech than we produce.
the only people whining about code not being fun and pushing gamification are the very people who shouldnt be doing it.
Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time.
Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.
In contrast, Nix trivially gives awesome tools for patching in fixes at varying degrees of locality, making it very easy to maintain a long term fork or just apply unmerged fixes in the short term.
Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
No, it’s not ok. I did that of cause, but it’s not ok, it’s bad. Especially when you promised something to people using your code. Not much effort is required to drop a one line notice - find the internal strength to do it please.
THIS SOFTWARE IS PROVIDED „AS IS“ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
“Never” is a very strong word. What is your recommendation based upon, exactly?
This is my code. It costs me nothing to tell people my future plans with the code. It costs me nothing to tell people that my plans are most probably off. But it will gain people something - they would be able to plan for the future better.
“Politeness costs nothing and gains everything” - is a better theorem (than yours one). I would rather tell it as: politeness usually costs nothing and gains at least something, but that’s just an engineer correcting a salesman’s statement.
But your plans can change.
Maybe you change your priorities, maybe you discover that a feature is harder to implement than what you tought and you must reduce its scope.
Or maybe you realize it was a bad idea after all and decide to implement a different feature.
If you have promise the original feature, instead of happy users for the improvement, some of them will be angry because of what you "took from them".
That's why I think the real politeness is to never promise nothing concrete until you are actually ready to ship it.
2. But. Even in a socialist country there is always a bunch of people who love their job more than a paycheck. Let’s call them “real professionals”. They just love to get things done.
3. When a real professional comes to a capitalist country he sees that there is a huge demand for their services and no real competition. Cause a lot of capable people virtually disappear whenever they damn well please unless they are paid _extremely generously_ for their work. For example:
4. Our customer was complaining that they have too many problems with our software. I was sent to look into that. When I arrived their CTO demonstratively unscrewed the plate with the name of our company from the door of the room I was assigned to. Shrug. Working. Issue #1, issue #2, … issue #23. Sound customers hear while connecting through our switch goes up, then down, then up, then down… Investigation revealed that one department under the CTO bought their voice files from one vendor, the other department under the CTO bought their files from another vendor. One bunch was twice as loud as another.
Now, neither vendor was going to do anything about that unless they are paid extremely well for the additional job. Neither department was going to do anything about their files unless they are paid extremely well for their work (actually they were demanding each other blood, but you can consider it just a kind of currency). I scratched my head. It is definitely not our job, we just connect a source to a destination. But. Actually our software can see which department a voice file comes from. I am going to give you an option: based on a voice file source you will be able to adjust the volume by a configured amount. And this configuration can be changed in real time, so basically you will have a volume knob you can adjust while software runs.
It took 15 minutes to code and a week of QA, which does not count since it is always a week of QA. Anyway in a week issue #23 was gone. Next.
In four months the CTO told me that in 15 years in the tech industry he never saw a company as aggressive as ours. The definition “aggressive” gave me a pause. Nothing we did seemed “aggressive” to me. We humbly listened to the problems and did our best to help, without sorting “our problem” or “not our problem”. It’s kind of opposite to “aggressive”, no?
5. A customer from that F..<something> list of big companies that is often thrown around but I could not remember it exactly told me once that when something happens, they pray (as in pray to God) that it was our company fault. Or, if not - that we were able to find a workaround.
—-
So of cause, go ahead - disappear unless you are paid extremely well for your work. Even if that work is dropping a line warning people that your plans have changed. Such a widespread attitude gets me paid extremely well. Kinda ironic, no?
Still, if you want to force me to do absolutely anything on a project I maintain myself and for fun, feel free to pay me extremely well. My employer does so and gets my work, the price doubles for anything done on my free time.
Lol. I have a “living experience” both in socialism and in dismantling it, which is an extremely painful experience in itself. My points 1 and 2 are from hands-on observation.
And my naming something a good thing is not the same as me forcing you to do that good thing. Yes, a named a politeness a good thing, but this declaration while obviously true can’t force you to be polite. Confusing these two things is a logical slippage. Frankly, I never observed such a slippage in good professionals.
That's it, and I can refer HR departments that enjoy reading github profiles to that pile of code with various levels of quality.
Nothing else and I post all my own code as GPL unless forced otherwise by existing licenses.
I do not work for others for free.
apt-get source xxxx
put patch in debian/patches
dch --increase
dpkg-buildpackage.
Copy the patch and rebuild next time a new version comes out.
Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches
we live .io era these days (sadly)
There is/was .ai for a bit but its less generic.
--
[0] - https://www.infoq.com/news/2019/08/npm-bans-package-ads/
I'm very much not a fan of ambient authorization.
Should we limit the # of likes/stars one gets per period of time? Scarcity?
> which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)
Reviewing code and triaging issues is real work.
What’s even worse is the notion that my employer requires me to use a social networking site for my day to day operations.
I use stars as bookmarks. I never even notice or pay attention to profile achievements. I am actually rarely even on a profile page. I am almost always in a repository either looking at code, issues, discussions, or reviewing.
Clearly if I was serious about marketing/promoting my library then asking people to star the repo would be high on the list of asks. Sadly I am not that person.