Massimiliano Falcinelli’s Post

🚨 DMCA Takedowns on GitHub - Know Both Sides Imagine opening your GitHub repo one day and seeing this: "Repository unavailable due to DMCA takedown." Your work, gone from public view overnight. Here's what every developer must know: 1. Your repo goes dark instantly - no warning, no prior discussion. 2. The complaint is stored PUBLICLY. Forever. GitHub publishes every DMCA notice at github.com/github/dmca - your name, your repo, the complaint. Permanently visible to anyone, even after reinstatement. 3. It can damage your reputation - future employers or clients may find that record when they search your name. But here's the other side of the coin 👇 If someone filed against you legitimately - it means your code may have violated someone's copyright. Ignorance is not a legal defense. ✅ Never copy proprietary code, even partially ✅ Always add an open-source license (MIT, Apache, GPL) to your repos ✅ Write original code - Stack Overflow snippets are fine, whole codebases are not ✅ If targeted wrongly, document your originality and file a counter-notice The DMCA system protects real creators - but it can also be misused. Whether you're the complainant or the accused, respect for intellectual property is non-negotiable in the dev world. 💬 Has this ever happened to you? Share your experience below! #𝗚𝗶𝘁𝗛𝘂𝗯 #𝗗𝗠𝗖𝗔 #𝗢𝗽𝗲𝗻𝗦𝗼𝘂𝗿𝗰𝗲 #𝗖𝗼𝗱𝗶𝗻𝗴𝗘𝘁𝗵𝗶𝗰𝘀 #𝗧𝗲𝗰𝗵𝗟𝗮𝘄

Anthropic accidentally took down thousands of GitHub repos yesterday while trying to remove its own leaked source code. Here is what happened. A developer discovered that Claude Code's source code had been accidentally shipped in a recent release. It spread on GitHub fast. Anthropic issued a DMCA takedown to pull it down. But the takedown was too broad. The targeted repo was part of a fork network tied to Anthropic's own public repo, so the blast radius hit thousands of unrelated repositories. Anthropic's head of Claude Code stepped in, called it an accident, and retracted the bulk of the notices. They narrowed it down to one repo and 96 actual forks. Two separate mistakes, one right after another. They accidentally shipped proprietary source code. Then accidentally nuked thousands of GitHub repos trying to clean it up. At scale, even small errors have outsized consequences. https://lnkd.in/dTqKFAgK

GitHub just archived 2 9's in a while. 89.91% uptime. 95 incidents in the last 90 days that's roughly one incident per day. For reference, "three 9's" (99.9%) means 8.7 hours of downtime per year. GitHub's at 876 hours of theoretical downtime at this rate. So what's likely going on under the hood? Actions & CI load Half the internet is using GitHub Actions as default so the scale has grown significantly now i get why some co. still prefer jenkins Lot of Dependencies Git LFS, Packages, Copilot, Codespaces, Pages, Actions these are loosely coupled but share infra. One wobble and the status page lights up. MySQL at this scale GitHub famously runs on a heavily customized MySQL stack. Keeping that healthy while the product scale grows is very difficult in itself That just shows the role of oncall engineers are very crucial one and there are still things which is hard to automate There might be other reasons into play here aswell but these are my thoughts #DevOps #SRE #GitHub #BackendEngineering #SoftwareEngineering

If you're new to open source and don't know where to start, this is the repo I came across when I was in the same spot. first-contributions walks you through the whole workflow by actually doing it fork, clone, branch, commit, pull request. No complex code, just the real process hands-on. I found it, followed the steps, and made my first contribution. 👉 https://lnkd.in/d2FtTHJY #OpenSource #GitHub #FirstContribution #Git #TechCommunity

You've removed direct publishing credentials and moved to a GitHub hosted trusted publishing pipeline. What will attackers try next? Turns out GitHub Actions is more vulnerable than you might think. https://lnkd.in/ewhgKsYW

I Always Thought GitHub Stars Meant Something. Now I am not so sure. This article explores how GitHub stars, often seen as a signal of quality or popularity, may not always reflect genuine community trust. It highlights how stars can be influenced or even manipulated, encouraging a more critical approach when evaluating repositories. https://lnkd.in/g372vhrc

GitHub just flipped a default that most users will never find. As of April 24, every Copilot Free, Pro, and Pro+ user is opted into model training. Your accepted suggestions, code inputs, file names, repo structure — all of it feeding GitHub's next model. The opt-out is buried in privacy settings. Not available on mobile. And here's what GitHub's own policy page makes easy to miss: the exclusion only applies if your account is tied to a paid org plan. Individual developers working on side projects, open-source, or anything outside a Business or Enterprise account — fully in. The practical consequence: a developer building something on a personal Pro account, even if they work for a company, is opted in by default. Most won't check. Most won't know to check. GitHub framed this as necessary to improve model performance. Microsoft, which owns GitHub, benefits directly from that improvement. Enterprise customers are exempt. The people with the least leverage — individual devs, indie hackers, small teams — are the product. That's not a privacy debate. That's a consent architecture designed to extract from the bottom up. If you're on Free, Pro, or Pro+: go to GitHub Copilot settings now and turn off "Allow GitHub to use my data for AI model training." Takes 30 seconds. Not available on mobile — you need a browser. #GitHub #Copilot #AIAgents

Do you really need a green GitHub profile? Recently, I saw a post by someone who exposed a person on GitHub with 10,000+ contributions in a year. That person was only updating their README with spaces to show more contributions. On LinkedIn, this has become such a trend/rumor that even a non-tech guy who doesn't even know how to code (Vibe Coder) and comes from a BBA background (not even MBA) told me to make my GitHub greener. But to be really honest, a green GitHub profile does matter only if it looks legitimate and you are actually contributing meaningfully to the code. I sometimes take 3-4 days or more to fix a bug in the code. During those days, I am working hard, but my GitHub is not green on those days. It doesn't mean that I was not working. Even the top SDEs at top companies don't have green GitHub profiles. It doesn't mean that they are not working. Remember: A green GitHub doesn't reflect your hard work. So, from now on, whenever you view someone's GitHub profile, make sure to review the commits carefully and don't commit to GitHub just for the green squares.

your github streak is lying to you. 365 green squares means nothing if you've never shipped a real PR. finding real open source issues is brutal. "good first issue" is a graveyard. repos are dead. the good ones get claimed in 30 seconds. so i shipped a feature on GitHubMaxxing this morning: input your username, get matched with real issues on real projects that need your help. if you've been wanting to level up your github but don't know where to start, this is it. https://lnkd.in/gXFpvKgD

I honestly thought platforms of GitHub's scale would have solved the core scaling riddles by now. Turns out, even they are battling fundamental architectural demons. The article dives into GitHub's recent availability woes. We're talking cascading failures, tight coupling, and an inability to shed load effectively. Imagine your critical CI/CD pipelines suddenly grinding to a halt because an authentication database choked. That's the kind of disruption they're talking about. This isn't just another post-mortem. It's a stark reminder that rapid growth amplifies every architectural shortcut. I realized that what we often chalk up to "bad luck" in our own systems is often a predictable outcome of underlying structural choices. GitHub's candidness about "tight coupling" and "insufficient isolation" really hit home. In the digital financial services, I've seen how a seemingly minor dependency, like a third-party fraud detection API, can ripple through an entire transaction flow if not properly isolated and rate-limited. We often talk about microservices as the panacea, but if they're still tightly coupled at the data or authentication layer, you haven't solved the problem; you've just distributed it. Their challenge with effective "backpressure mechanisms" and load shedding, especially as AI-driven tooling piles on, highlights that just throwing more compute at it isn't enough. You need smart circuit breakers and adaptive traffic management, not just reactive scaling. The article also points out the disparity between official status pages and real-world developer experience, which resonates deeply with anyone who's ever debugged a "green" system. How do you proactively build resilience against these kinds of systemic failures when your system is growing at warp speed? What's your secret sauce for true architectural isolation? https://lnkd.in/e3EmWfjz #SystemArchitecture #Scalability #ReliabilityEngineering #DevOps