Good. Yeah it doesn't do much for the community, but I got scolded in the past for squeezing in commits to open source repositories that aren't work related during work hours.
I know, I know, I shouldn't be doing that in the first place, but it still sometimes happens, and just being able to keep the profile private is easier than waiting with committing until after work hours.
Not everything I do on GitHub should be broadcasted to my entire workplace
That may be true in principle, but you’re simply not getting paid for contributing to open source projects unless your employment contract says exactly that.
Im not opposed to idling, brains need that. But I don’t think it’s fair to use your company time to work for something else, no matter how good the cause - I wouldn’t want my engineers to help out at a homeless shelter either, even though I’m generally in favor of that.
If your company is paying you to work on Product X and Product X depends on Open Source Library Y, Open Source Library Y's bugs are Product X's bugs. Open Source Library Y's features are often productivity enhancements that make Product X better. Your company is paying you to work around Open Source Library Y's defects and use Open Source Library Y's productivity enhancements, no matter what. Sometimes the fastest way to work around Library Y's defects is to fix them yourself and sometimes the best way to get more productivity out of tools like Library Y is to contribute Library Y features yourself.
Because your company may see Open Source Library Y as free as in beer they may not value the vendor relationship with Open Source Library Y. The "cultural" Maintenance Agreement with Open Source "vendors" is that good open source users contribute back to open source those bug fixes they need for workarounds and those features they request for productivity benefits. Compared to the costs of Maintenance Agreements with many large, classic closed source vendors, the cost of a few hours labor on dependencies to products is often quite cheap relatively speaking especially with the "free as in beer" platform/networking effect that other "good" companies following cultural Maintenance Agreement norms contribute as well.
The only real missing ingredient is that because that Maintenance Agreement is cultural more than it is written down in a way that Corporate Lawyers can read it and Actuaries and CPAs can understand it to be an asset and/or liability that impacts the books, it just becomes invisible guilt: either the guilt that you aren't doing your part as a developer with respect to that culturally assumed Maintenance Agreement OR the guilt that you are doing your part but that your company may find out and claim you are wasting their time. But seriously, that vendor relationship even though most of the "assets" are "free as in beer" should be on the books and have its own billing codes for the culturally encouraged "liabilities" of Maintenance Agreements to spend a few hours of developer time here or there for the "greater good", but also the specific good of "making Product X better" because that is an asset directly related to the performance and success of "Product X".
I think it is still related and relevant, though I did forget to address it, sorry.
Expanding out further from where I left off:
The "compact" of that cultural Maintenance Agreement further relies on network effects that make it powerful (and cheap as free as in beer as an asset): it isn't assumed that everyone can fix/build every bit of open source, it relies on community effects. It relies on a lot of individuals scratching their own itches becoming a collective force greater than the sum of its parts.
Absolutely, Accounting for that is even harder. It's not a "quid pro quo" that you can directly bill to a specific product. That's even harder for companies to deal with. But plenty of companies have much more complex classic liabilities than that: Marketing efforts, R&D, etc. Again, the "wastefulness" in budgeting for "Open Source Maintenance" both specific and general is a super cheap deal compared to classic R&D budgeting. It's a huge savings compared to classic third party software vendors on a combined "asset portfolio" basic. Companies can budget for it. They can and likely should assume some of that "wastage" on "maintenance costs" as natural overhead of building software. (That's what the cultural narrative of Open Source encourages: that everyone should chip in and assume at least some baseline of community effort, from every user [personal, corporate, whatever].)
Bringing things back even more full circle: my company tries to have somewhat regular Community Service Days to give back to the communities the company exists in (and professionally serves day to day). It budgets labor hours towards those efforts (and also promotional budgets for things like t-shirts to pat itself on the back), people sign up to meet those budgets, and things like "helping a homeless shelter" are direct uses of that budgeted time that the company is paying for. My company isn't alone in this practice, and expanding it to charitable "Match" contributions there are a lot of companies paying regular money and/or labor to "general good" charities.
Admittedly, part of those budgets every year come from charitable organization "vendor requests" asking for specific numbers of hours (in many cases) and from Accounting knowing that working with any 501(c)3 makes those hours spent a write-off liability come tax time. That's again where the "cultural" part of Open Source "obligations" meets the practical side that there aren't enough 501(c)3 charitable organization "vendors" to "invoice" companies and also help make the time/labor spent on such "invoices" to be even cheaper than usual labor costs thanks to tax write-offs.
> I know, I know, I shouldn't be doing that in the first place
You almost certainly should, and if you’re scolded for it you probably work for parasites. You’re not wrong to hide that activity from them but I hope you’ll find a role where contributing back is valued not chastised.
I still don’t see the problem. Either they’re sitting around with nothing to do, and therefor the contributions are a clear positive, or they’re neglecting the work they’re supposed to be doing and the contributions are beside the point.
I think this can cause legal issues: ianal, but generally work done during company time with company equipment belongs to the company, and I’d guess a litigious company could cause problems for open source projects contributed to in this fashion.
As long as the projects being contributed to are using well understood licenses, the projects themselves are fine. If the employer wants ownership of any of the work, the ownership they’ll get is rights to claim they were contributors. Still mostly good!
What about the other way - if the commit is "damaging" in nature specially on a competitors repo.
For example the recent NPM commit that wiped user data. If its done on company time using company laptop, will the company be liable ?
If you build a software and because of a bug it breaks something, that is fine. If you deliberately change a library to make any software running it crash and you know it is used among other things by software that control nuclear plants or elevators, my guess is it will probably considered a crime in most juridictions. This regardless of the fact said software makers should test their changes.
You're very likely right and I made a mistake. In strict legal terms anything you do can be sued if the law deems it damaging it some way or another, and the answer to this->parent's question is highly dependent on legal contexts.
I was taking a naive view from a theoretical point.
> One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).
So, take this for what it is because I'm just some random guy on HN, but my company required us to make our Github primary email our work email to receive alerts. I wasn't comfortable doing on my personal account, and was told to make a second one. We followed up with our Github rep regarding this clause, and they told us that because the account would be primarily used for Enterprise (even though it's a free account), it's not something they consider a violation of their policy. Allegedly this happens with quite a lot of their customers.
Genuine question, I don't actually know the details: how does the contemporary notion of avatars and usernames to distinguish identity or alter-ego interact with the notion of what a legal entity is? If I practice security hygiene across multiple identities online and only do certain things using certain representations/usernames... how would it work out in practice if I tried to argue that each representation was a distinct and separate entity of agency?
Hmm. Thinking about this I now realize that identity fraud would probably be a lot harder to pin down if things leaned in the direction I'm describing, so perhaps not.
The single account requirement is problematic until Github makes it possible to grant personal access tokens which don't give access to all of your repos, including across multiple organizations.
Not a lawyer, but I interpret Ben writing code at work as a different legal entity than Ben writing code at home in regards to code ownership under CA law.
The accounts aren’t but the orgs typically are and I think that passes muster. Ultimately they just don’t want people astroturfing or otherwise deceptively maintaining multiple accounts on behalf of paying customers.
I'm also happy to see this feature, just a month ago I was looking for it and was disappointed I can't hide my activity.
I was sick with COVID, but about one week in, I had an afternoon where I didn't feel completely sick, so I wanted to tinker with some code for an hour. I couldn't commit because I was paranoid that my boss/coworkers would freak out that I coded an hour while I was sick.
Same is true if your coworkers follow you, and you start starring or contributing to repos about interview questions, whiteboard questions, etc. There is a 98% chance nobody would notice or care, but I don't want unnecessary drama because I enjoy using GitHub in my free time.
I like the most of it, but I've noticed that if you enable this feature, your profile page will stop showing the Top/Pined Repository list while visitors can still see those repositories on the Repositories tab.
Maybe just keep the Top/Pined repository list since they only show public repositories anyway?
Great! one thing that made me move away from github and actually self host gitea was how invasive their social features were without being able to opt out
A question: Who has multiple github profiles and why, or why not?
Do you separate work commits from personal/oss/hobby commits?
Do you have different github accounts per employer you've had?
If so... why?
If not... why?
I personally use only 1 profile, but it has occurred to me that this is perhaps unwise and mixing work and pleasure together is a good way to create a diluted and messy situation regarding IP and who owns copyright on something. Not that I delude myself that separate profiles would solve it, only that separate profiles would mitigate a lot of the risk and make it a lot clearer when I'm acting on behalf of my employer vs just as a lay person.
One of the first things I do upon joining a new company is use the new company email address to register a github account, assuming there isn't an enterprise Github and it's allowed as part of policy. ( I also register a new HN account, it just keeps things cleaner although I want to be clear this is still a personal account and doesn't represent work. )
Work and home emails / github / phones / everything are separate, I wouldn't want to ever mix them.
Yes, that means losing some history when changing employers, but that's part of the deal. You work for your employer and while they are tolerant (to various degrees) of engaging with open source, in return they get to retain ownership of that email address and their brand.
In a new company I have a new "hat" on, and while I can see and interact with my previous issues, I'm no longer that person with a new hat on and can only indirectly interact with my other self as if a different person.
I keep work and personal accounts separate as well. I do a fair amount of open source work and maybe one day I will find a way to generate some passive income. If that day ever comes, I want there to be a clear separation between work done for my employer and work done for myself. It is important to maintain a clear separation between the two.
Same here. Last thing I want when I move to a new job, especially if moving to a competitor, is have people ask me to fix bugs/answer their questions about my old code, which would be creating a conflict of interest.
I'm on the same boat as you. I occasionally wonder about this when I see people using their working email addresses to commit code, but I personally think that's a hassle I don't want to go through. I get the benefits of those who do it, but I'm ok with exposing my personal email address to other peers (or everybody since most of my work is open source anyways). Maybe, if I ever feel judged by what I do during my working hours or viceversa (something I doubt will ever occur at my current company Meroxa), then it's when I would probably think of setting a different account.
I have multiple github profiles, because GitHub did not allow me to keep commits to certain public repositories from being broadcast to my public activity feed on my profile. I did not want to broadcast certain commits to the world just yet, so I made a new account for that purpose. Now that I can set my whole profile to private, I can try to merge the accounts.
I don’t think I’ve ever looked at anybody’s profile on github, and I can’t imagine that anybody has ever looked at mine (including me). It would just be a list of commits to source control, right?
Can anybody who uses this feature explain what github profiles are for?
I don’t know that I’d go so far as to explicitly hide that information, mostly because it is so mundane as to have no value to anybody.
I always look at a profile when I see projects or code that I like and most of the time I was happy for doing so because I discover lots more projects that I like and that's inspiring and adds plenty of value to my own work. And many of the times I get to use those projects. I can't imagine what coding would look like without following all those people and getting these updates on the work they do. The value I get from visiting other people's profiles and studying their work is immense.
We're open source (https://robusta.dev) and very involved in the kubernetes ecosystem so GitHub history is extremely relevant when we look at candidates.
We'll hire people with no GitHub activity too, but when it's available it's great
This goes the other way too. I’m job hunting now and have been looking at companies’ open source projects and activity of their leadership for red flags. I wish I had done that with the company I just left. If I had looked at any of the PRs the founder reviewed I would have realized he is not somebody I want to work with.
When I get pull requests or issues opened on my projects I often click on the person making the request. You can usually tell a lot about someone from their GitHub history - is it a new account? Do they have student projects there? What flavour of projects are pinned? Research? Database stuff? Niche hobby projects?
If someone has an old GitHub account but very little activity, I assume they work at a leech company which uses opensource but doesn’t contribute back. I’m less likely to care about the needs of users like that. That said, professional software engineers will usually be more responsive in issue threads when they run into bugs. I’m much more likely to fix a bug if you can give me a good repro!
> ...I’m less likely to care about the needs of users like that...
I kindly suggest you not lump in users/employees with the behaviors of their employers. Any company that i might work for might indeed be "leeches" as you noted, but that does not mean the user/associate/employee is one also. It might also be the case that said employee actually only works for such an employer as a necessity...you know for earning a living, but not really share the morals/ethics of the employer. Some employers require proprietary controls on their source code, hence preventing employees from using publicly availablr repos on github. Now, if i were to get "graded" on my low activity on github for personal projects, then i get your point...but to automatically lump in both employee and employer into one actor's ethics, seems not right.
If you use opensource code but don’t contribute back, you not an equal member of the opensource community.
You’re getting financial benefit from my donated effort. I don’t mind - I wouldn’t opensource my work if this bothered me enough. But GitHub issues opened by leeches have a certain entitled tang to them - “Hey could you donate more of your time so I can make more profit? I won’t pay you. Maybe you should be thanking me for finding problems in your work and pointing them out to you. Get to it!”
The reason you don’t contribute doesn’t matter. You’re profiting from my volunteer work and asking me to volunteer more so you can profit more.
Justify leeching to yourself how you like. But you won’t get respect from me until you contribute back.
And, yes, if you work at an immoral company, that is also absolutely on your hands.
Do you only object to the entitled tone of certain feature requests people have written, or do you see all issues created on your project without a corresponding code change as entitled? If it’s the latter, you can disable Issues on your project, leaving only Pull Requests as an option.
If you disable Issues, I suggest also briefly explaining why you did that in the README to ensure you don’t get do-nothing Pull Requests asking how you’d like bug reports submitted.
The opposite - I prefer it when an issue is opened before the PR is written. That way I have a chance to respond / give feedback on the approach.
I can respond with things like: "Oh, that problem? Yeah there's already code to work around it - here's what you need to do." Or: "You want that feature? I can see why thats valuable to you. I'm sorry but I'm never going to accept a PR from a stranger adding that. I don't need that feature for my workflow, and its complex, so the payoff isn't there for me to maintain the code. Fork my code, or implement that feature in an external library."
I'd much rather turn down a feature request in an issue tracker than turn down work in a PR, after someone has done all the work already for something I'm not going to merge. That feels bad for everyone.
If you write a good issue and take part in the discussion, that signals that you aren't taking my work for granted. Work with me to make a good repro case, and I'll work with you to fix the bug you're running in to.
I would personally be vary of judging people on what they put on their GitHub accounts, because a lot of the real work people do is often locked away in private repositories (or on other platforms).
I can use myself as an anecdotal example. I use GitHub mainly to store guides and neat tricks for myself, and to sometimes share some excellent code. All my current professional work lives in Azure DevOps, locked away so that you would never know so if I didn’t tell you. I have a NPM package that should be private but is public because we share it with some contractors and nonsense occurred (loooong story that is basically answered by “above my pay grade”). If you found it and looked at my GitHub profile, then you might use it, and you’d experience some breaking changes that you typically wouldn’t with good OSS NPM packages every time we make some major updates to it. Because we don’t really factor external user into our processes.
I use it to check what people I follow (friends, cool persons etc) doing every day. But checking each profile to see recent updates is difficult. I created kinda GitHub updates feed using their API.
https://github-feed.tandav.me
I wish the official GitHub newsfeed to show contribution updates instead of likes. Or even customize what to see in feed.
in the new feed i see every release update from 800+ repositories i starred
would be nice if there was a way to exclude releases from the feed, because it actually discourages me from reading the things i care about (like what my friends star and updates to repositories i'm watching)
I thought by "Profiles" it was going to be a Resume-like feature (aka how Stack Overflow does it), but it's not... which makes me think - why hasn't GitHub done something like this, as it seems like an obvious thing to do?
... I guess we could set a de facto standard and create a "resume" repository. Though, it would be better if it were a standard feature and searchable too.
If your github username is "foo4711", create a "foo4711" repository and add a "README.md". Add some content, push it. Now visit your profile at https://github.com/foo4711 and the rendered README should be visible right at the top of your profile. You can use this to tell more about yourself, your projects etc...
Finally! I hope they will introduce more granular privacy features down the line, but this is a great first step. I am now tempted to merge my secondary account into my private one, but with this being a beta I'm not quite sure if it's safe to assume the feature will stick around yet...
Interestingly, while the changelog says "Private profiles are in public beta" this is neither a 'feature preview' (in the top right profile dropdown) nor does /settings/profile indicate it's in beta.
I just get 500 on the homepage, and my profile also 500s when logged out. Most other things still seem to work, including https://github.com/settings/profile where I could turn it off.
On the one hand I actually want the credit for all the open source I've done. On the other I don't want my boss to see if I'm contributing to some open source repo when we have a looming deadline. I would appreciate fine grained control
* Hide activity newer than a certain date. The reason this would be super useful is that it's okay / good for me to contribute to OS during work hours but I don't want the question of "Is now the best time to be doing this?"
That could work but I actually really like having just one account. I hate having to constantly switch notion accounts, gmail accounts, gcal... It's already annoying enough.
More privacy is always good but why it's important to hide what I am staring and what kind of GitHub repositories I like? It's anti transparent and against what's github is and has been for a while not just for hosting the code but for sharing the development experience. It feels more like we can ship this feature so let's do it.
IMO hiding the stars is the most useful feature here because I never understood why stars are public in the first place.
People just use stars in completely different ways such that the information that someone starred something ends up being basically pointless. E.g. people star stuff just because they want to look at them later and having a public link to these profiles isn't really reflecting their relationship with them. I know multiple users (myself included) who were pretty surprised when they first learned that this is all visible.
Of course instead of hiding the stars it might be better to add a private similar feature instead...
Anyway the whole "sharing the development experience" features in GitHub are IMO mostly weird. I'm using GitHub to develop open source software, not because I'm looking for another social network.
> I never understood why stars are public in the first place.
We star because we like the code, the idea, the execution and the maybe the impact of the project. And it's encouragement. You star a project you pushing it forward. This is the human experience. We are not machines worshiping code. We care about what others think and this is why github is different.
> Of course instead of hiding the stars it might be better to add a private similar feature instead.
Agreed. Hiding means giving more space to anonymous users do we want that?
> I'm using GitHub to develop open source software.
Same. And i am not coding for myself i also need other to be part of what i am building and that's supposed to be part of the mission. Increase interactively. Instead this feature does the opposite.
> We star because we like the code, the idea, the execution and the maybe the impact of the project. And it's encouragement. You star a project you pushing it forward. This is the human experience. We are not machines worshiping code. We care about what others think and this is why github is different.
I doubt that. The social features act like a strong gamification feature that keep people hooked. Those chasing this gratification won't go opt into these privacy settings, but those who want the privacy settings might stay in github instead of going elsewhere.
Choice is generally good in my opinion. Considering what the majority of Github is as a community I would very much doubt that the majority is going to be making their profiles private. Making it private makes no sense if you collaborate and contribute with open source projects (or host your own), and it doesn't help with having a public profile that you can potentially show off to companies you want to be hired by.
So who is this feature for? Those who have no interest in the social aspects of Github and want to use it privately. I'm sure that's going to be a minority.
If I could (without hassle) I'd use a different identity per commit. I don't see any value in consistent identity here. Maaaybe if I was using it for a resume.
> Those who have no interest in the social aspects of Github and want to use it privately
Or people who don't want to use GitHub in the first place (esp. because of its less than appealing position on privacy), but they don't have a choice because it's the Facebook of the tech world and seemingly everyone else insists on it in order to get anything done.
GitHub is using enterprise features as a revenue driver, especially appsec tooling. There is a large cohort of users who will need a GitHub profile for using GitHub, but the social aspects would be a net negative.
I personally love this feature and have been waiting forever for it. Default to privacy over social features.
I think this is a great idea. Some people may choose not to use the social aspects of github and prefer using it only as a personal source code repository.
You could do it when enable hiding private contribution. This features actually enable anonymous users. I don't think it has anything to do with using the code privately.
I never use github's social features. They aren't useful to me compared to their features like source code hosting, issues / pull requests, wiki, and version release.
Yeah I'd go a step further and say that any social features are anti-features for me. I really don't need people seeing my activity. Going to make my profile private immediately, and I'm really happy they did this.
In this instance we don't think it will hurt the social coding experience of open source and in fact might encourage folks who would otherwise be put off. But we are testing this particular feature and will keep iterating on it depending how things go and what the feedback is.
One thing I would personally really like is a bit more control around the creation of Public vs Private repositories in my enterprise (Cloud) account.
Namely, I'd like to be able to stop myself (the org owner) from inadvertently creating a public repo, or at least make it much more difficult to make that mistake.
I can do this for other users in my account (of which I have none), but not for myself as the org owner. I live in fear of clicking the wrong pixel one day and pushing private customer code to a "not meant to be public" repo.
> FWIW we have a quite a bit of history of allowing people to protect their privacy
Don't overstate it. Out of all the big social networks, GitHub's handling of user privacy is the worst by far. It took 1 1/2 decades to give a switch to toggle off the default behavior of "provide a public index of my activity across the site to anyone, even though I never asked for this (and was never asked if it was okay, either)". To really spell it out, what this means is that for its entire existence, GitHub has offered even worse privacy controls for what a user chooses to share about themselves than Facebook. For the longest time—until now—the only way to get around this was to regularly delete and then recreate your account (which is still an imperfect solution, not to mention labor intensive) or to disengage completely. Given the way that GitHub has positioned itself, it being even harder to avoid than Facebook has had a hugely deleterious effect on privacy for those who actually care about it.
It also sucks when terrible people abuse public profiles to harass and intimidate people. Privacy should always be an option for those who want or need it, otherwise we indirectly force marginalized people out of these spaces entirely.
As someone who's been subject to harassment based on info on the github profiles, this couldn't have come soon enough. Prior to this my only other option was deleting my account but if I did that the name would have been instantly re-registered by the harassers and used to impersonate me for harassment purposes.
GitHub is first and foremost a development platform, not a social network. People should always have the option of opting out of "social network" features.
Yes. Enable hiding the user activity but keep the user active. Imagine someone spamming some repository with issues and still can't be known or detected because it's anonymous now.
Martin from GitHub here. The "leaderboards" are actually what you see as "Most Helpful" tables in GitHub Discussions (see https://github.com/github/feedback/discussions for an example). We should probably change the language on that settings screen - thanks!
i'd like to ask a question about the "Include private contributions on my profile" feature
if i'm a member of private org does it count my contributions too? and if i'm no longer a member of the org are my contributions still counted to my profile?
Yes, and I think yes but I would need to test it to be sure. I do know the contributions disappear if you only have public contributions enabled and then turn a repo private but if you have private enabled then as long as the contributions still map to your ID it should show up. Does it not work that way for you?
the first one i can confirm, but the second one i actually do not remember
the scenario is the following: somebody invites me to their org to do some work on their private repo, then after the work is done they remove me from the org
what i expect in this case is that my contributions are still counted as long as the repository is on GitHub, even when i'm no longer a member of the org
it's a very minor feature but a very nice one for contractors like me who want to show some progress!
Your attention may be being inadvertently drawn towards the "checked" box in their screenshot ("Include private contributions on my profile"), where it is the unchecked box which is actually the new feature they're announcing.
I know, I know, I shouldn't be doing that in the first place, but it still sometimes happens, and just being able to keep the profile private is easier than waiting with committing until after work hours.
Not everything I do on GitHub should be broadcasted to my entire workplace