The gold rush metaphor loves to highlight the shovel sellers, but the actually valuable commodity (gold) still needs a broker. I cannot see any other hardware vendor being better positioned than Apple for consumer facing AI.
It's cool to see such an impactful project choose sovereignty. I hope more projects follow their example.
If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "FFmpeg contributor" on their CV (or whatever).
Rejecting useless or white space-only PRs is quick and easy. It’s not as big of a problem as you’re suggesting.
I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.
> Rejecting useless or white space-only PRs is quick and easy.
No, it really is draining.
> I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.
It's frustrating when people make "contributions" that take more effort to review than they put in and then get mad when they don't get thanked for it. This attitude is exactly why dealing with drive by pull requests is not "quick and easy" - suddenly you need to do social and public relations stuff when all you want to do is code.
It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.
As a maintainer of a few open source projects, yes it happens a lot.
I want to believe some people just want to send small patches to projects when they notice something (I tend to do the same for projects I use) but my impression is a lot of them do it so that it shows up as "contributions" on the GitHub profile which they can then add to their resume (or get some other kind of street cred).
At least typos are actual fixes, far more often you get complete spam (people copy-pasting the contents of PRs and issues from 5 years ago, sending bizzare pull requests with hundred of commits as a merge commit, leaving cryptic comments on 5 year old commits). The spam reporting process on GitHub is kind of annoying to go through, but I trudge through it every time we get one of these PRs. There was one year of Hacktoberfest where some streamer told people that if they just spammed projects with 5 PRs they would get a free shirt and every open source project was DoSed by hundreds of garbage PRs made by accounts created the same day.
Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)
> Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)
I have to disagree, changes to development processes are the worst kind of drive by contributions. I don't want CI jobs contributed from someone who isn't going to maintain them.
I mean, I would prefer that it be done as part of a discussion with upstream but if you're talking about a GitHub Action it's not really that much effort to maintain in my experience.
But even if adding CI jobs is not the preference of upstream, I would prefer that the contributor runs codespell locally and fixes all of the issues rather than just sending one-line patches. And I can imagine much worse forms of drive-by contributions than CI jobs that you can easily disable in the future.
I fix documentation typos or broken links because they really annoy me. There are some egregious examples of people doing it for GitHub-as-a-social-network reasons, but I think some are like me and just want to fix the writing.
I always start with a small patch to test the waters of a project. That way i dont waste my time with a larger patch if the project is a PITA to contribute to.
I similarly contribute only minor language and writing corrections to Wikipedia, and usually anonymously (unless my phone has randomly pulled a blocked IP and I need to sign in). I don’t consider myself enough of an expert in any Wiki-worthy topic to do anything more, but I’ll make damn sure small mistakes get addressed.
I feel even less qualified to contribute corrections on GitHub mostly for the same reasons mentioned above. Staying anonymous prevents anyone from thinking I’m attempting to capitalize on low hanging fruit.
There’s also a couple of video tutorials that show how to make a pr, using node or nom on GitHub, and people just follow the tutorial verbatim, not thinking about what they’re actually doing.
This issue has only worsened with LLMs "assisting" contributors in submitting PRs that end up wasting maintainers' time.
Tools like OpenAI Codex, which can connect directly to repositories, are likely to amplify this problem even further.
That said, this is also the real measure of the actual value of LLMs and coding agents: the day we see top open-source projects having dozens of bugs effectively fixed per day by LLMs, we’ll know they’ve matured into a solid, reliable resource.
In my previous work we were strict about typos, whitespace and general consistency in reviews. And even fixed them later if they slipped through. I found it a bit ridicolous a times.
In my current company nobody cares. It can be seen in the whole code quality. Full of smaller and bigger bugs as well as horrible hacks. It can be seen whether coders look twice or more at their own stuff before putting it to review or not, just trying to avoid ridicolous comments. It's a whole attitude. I write good code in a messy source base is unlikely to work in practice.
That said, I have submitted cleanup commits to open source projects only in the same MR with a real code change I wanted to make and only in vincinity of that change.
FFmpeg seems to have dealt with that problem when they still were on github. This is the paragraph at the end of the readme:
> Contributing
> Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process and will be ignored.
An agentic LLM bot is likely to have no problems at creating a patch and mailing it but it's a major pain for most human developers. Furthermore they can ban source email addresses and vet potential contributors before letting them in the mailing list.
(I work on a project that uses an email workflow. "Should we switch to something else?" is a perennial topic.)
I think the main pain points are:
* unfamiliarity -- if you're not already set up then it's extra admin work. And the "obvious" approach (paste the patch into your usual email client and hit send) generally mangles the patch.
* developers are no longer largely using local plain text based email clients -- if you are already doing email that way then sending patches like that is a natural extension. If your email client is gmail, or worse still some Microsoft mail server, now you have to figure out how to send email in a way that's not html and doesn't get mangled by your mail server.
* how to set it up is not a single well documented path. Github has an incentive to do a decent tutorial/docs, and how to create an account and send a patch is the same for everyone. Using git send-email, there's a lot more variability: how to install it depends on your OS, and how to configure it to talk to your mail server depends on your mail server. In these days of two factor authentication and app specific passwords, it's no longer as easy as "put the server name and your account name and password into the config file".
This has got better in that now you can point people at e.g. https://git-send-email.io/ which has info on e.g. setting up gmail app specific passwords and what kind of authentication to use.
If you're a regular developer on a project, this is a one-time pain and thereafter sending patches is straightforward (assuming you're not totally allergic to the command line). But for one-off or first time contributions it can be a barrier.
If you are ignoring all of them. Filtering PRs to see which are worth having might take time in a large popular project. Even if it isn't much time, it is more than zero. You also have to deal with all the other comms associated: people submitting genuinely useful patches which accidentally get rejected querying (maybe politely, maybe not) and people who submitted less useful ones bitching about their rejection, both to the project and in public forums.
Another way to frame this is that even though the FFmpeg repository clearly indicates it's a mirror repository and has had a single open pull request titled "WARNING: PULL REQUESTS ON THIS REPOSITORY ARE IGNORED" [0] sitting in the pull requests page for 10 years, they've still had to close hundreds of pull requests.
That’s fair, but it would be trivial to use GitHub’s actions/API (and probably just an existing open source tool in either case) to automatically close them without anyone wasting their time.
I think you’re definitely right that being a massive project on GitHub that accepts PRs there would be a nightmare though.
To be honest, I have never understood the TODO "industry." Do people really have so many things to do, and is it really that difficult to keep track of them all? I do not know if it's just me but I feel completely alienated by these apps and articles.
House projects: Probably over 20 distinct chores over the course of a week, plus currently two maintenance things that I can't do myself and have to call people repeatedly because 90% of contractors just don't show up unless you remind them to.
Kids: most things can be handled immediately (e.g. sign a form), but there are always at least half-a-dozen things in the air that can't for one reason or another.
Other: Resubmitting medical bills to insurance (can only be done during business hours, I typically open my mail after business hours). Contacting bank about something. &c.
Here's a fraction of what I'm doing today, including one from each category (except calling a contractor because my wife is doing that):
- I have to contact my bank during business hours because they sent me the wrong form (discovered while I was filling it out this weekend).
- I need to call a coworker because one project is blocked on them regarding an issue that they haven't replied to my e-mail sent Thursday afternoon.
- I need to pickup my daughter from a day-camp on the way home from work. Before dark, I need to weed part of the front yard.
- Tonight the trash (but not the recycling) goes out to the curb for a pickup tomorrow morning.
Yes, I have met people who can keep track of these things in their head. I am not one of them.
You have too many things on the go at once. Do less at work, delegate all your chores to your wife, and send the kids to boriding school. Problem solved.
For someone with ADD, it can be extremely difficult to keep track of even 3-4 relatively simple items that need completed in a day. They will get distracted by something minor, and 8 hours later have completed 20 things in a highly productive manner, but 0 of the 3-4 important items they were supposed to do (and most likely, they will have forgotten those items existed entirely). For me what works is starting each day with a list of 3 items that need done that day, and to check that list about every 30 minutes all day long.
That's a fair point - but most of these threads focus on comparing systems rather than discussing whether they are necessary in the first place. I can see how folks with ADHD or similar challenges would benefit from a TODO app (or similar).
I'm more curious about a broader question: at what point does life complexity actually require a formal system versus just mental tracking? Tech people are, for the most part, the only people I encounter actively using and iterating on their TODO solutions, and I am skeptical that in general they lead more complex lives.
Maybe virtual tasks need better organization or reminders than physical tasks. I rarely forget to wash my dishes because the dishes are right there. I don't forget to go gather the eggs because I have to shut up the chickens every night and check their food and water, or living creatures could die. There are physical consequences and reminders of those things.
The need to update a piece of software doesn't give me any physical cues, and if I have a couple dozen tasks like that waiting on me, I'm never going to remember them all unless they're all popping into my head throughout the day. That pretty much is how I used to try to do it, and it wasn't good.
You’re not alone. Like many in this thread, I have kids and a house, etc. etc. Never needed anything like this. Maybe jotting down a note with pen and paper now and then, or at most, e-mail myself a reminder of something.
I have to wonder if some people use these systems to make themselves feel more important than they actually are.
My organization isn't a pure tech company so not much has changed. Management acknowledges AI's velocity but maintains a healthy skepticism of throwing "AI" into everything as a panacea. Writing the code has rarely been the hard part.
Claiming that we shouldn't accept bait and switch as normal is denying the fundamental reality of the "hypergrowth" SaaS business model. The beatings will _always_ continue until the bottom-line improves. Price transparency for the average retail user is irrelevant to B2B contracts which is where every SaaS churns their butter.
This makes me wonder if AI usage will end up part of job position listings, similar to remote days, if it is not already. How much AI agent will you be able to use/be subjected to? Are people looking for this already when job searching?
Some companies are definitely already looking for it - I think as part of my job search, I've run into probably atleast 4 or 5 companies that, on top of having it as a qualification, ask specific questions on the job application about what AI tools you use and how they've made you more productive
I'm by no means a super keen or heavy user, I've barely dabbled really, but if we were hiring at the moment I think I'd ask about it - it's suddenly a huge part of understanding how a person works and what they might be like to interact with. Up there with considering cover letter/email/CV writing style, and commit messages from any take-home or their public repos.
And now when candidates submit take home tests for me to review, half of them are barely functional AI slopfests.
A goddamn staff engineer candidate with 20 years experience submitted an auto generated, broken app, and then tried to pass it off as though it didn't work because our API was down. No, the AI hard coded the wrong URL and he didn't notice (the correct URL was specified in the email containing the test instructions)
I run several job boards, and though there hasn't yet been any postings requiring the candidate's using AI (also not all that likely in the particular field), I am noticing a definite increase in the number of lists with emoji preceding each bullet point, and the use of em dashes. Personally, if I were a job seeker, I'd find that off-putting just as much as if I were presented with the requirement to use AI in my job.
Sit on the other side of the hiring process and observe the impact of your hiring decisions enough times and you'll see why.
I don't care (that much) about your projects because they don't tell me if you'll drop into my team and kill it with your ego. I can't fully understand the context in which you developed those projects. I don't want to search around and see if it's just a clone of someone else's work you're trying to pass off as your own, or if the community you've mentioned in your CV really exists.
I'm more concerned if you'll be able to consistently make it to our stand-ups. I will take a mediocre but steady, agreeable, and trustworthy developer I don't ever have to think about over a "rockstar" who is making life hell for the team every time.
I’ve seen similar, and the engineer not only had thousands of GitHub stars and forked projects, but they were an excellent team player, natural leader, and terrific developer. What I did see, even then, was sentiment similar to yours, coming from managerial levels above them. Where does the insecurity start, and where does it end?
Can you work with your team? Can you get management what they need to do their job effectively? Can you get what other teams need from you effectively? Can you do the technical work?
All of them are part of the job. If you're great at working with your team but management hates working with you, that means you're only doing part of the job.
(And sometimes, that's management's fault too, don't get me wrong!)
I don’t know how to articulate properly it but the comment in the parent is a response does not address the specific essay. Maybe the writer had another, related essay in mind but nothing they respond to is present in the essay I just read
Agreed. There a lot of skills you only learn by being in a team environment that make you much more valuable in that environment than l33t coding skills.
> I will take a mediocre but steady, agreeable, and trustworthy developer I don't ever have to think about over a "rockstar" who is making life hell for the team every time.
It seems to me from experience interviewing that every hiring process wants the candidates to be both. Humility, agreeableness, trustworthyness does not get you a job.
By my estimation, it goes like this:
Being 70th percentile of leetcode test takers + all of those traits gets you a job.
Being 80th percentile of leetcode test takers + 2/3rd of those traits gets you a job.
Being 90th percentile of leetcode test takers + 1/3rd of those traits gets you a job.
The difference between being 70th and 90th percentile of leetcode test takers is practically nothing compared to what it takes to get up to 70th percentile. Within the hiring process, the whole point is to root out mediocre leetcode test takers, as they are seen and derided as "fakers" who can't code, regardless of their professional experience, shipped projects, number of code commits, or references from people who manage coders. The industry and hiring process hates "fakers". Other programmers hate "fakers". Especially the ones who are the "rockstar" developers hate "fakers" the most - everyone knows about that group of socially problematic (ie: borderline sociopathic) but powerful developers who will reject almost every candidate. This is seen as a good thing - a "bad hire" is seen as the worst possible outcome of any hiring process.
If we stopped running software engineering interviews like a game of werewolf, we might accidentally start valuing the type of people you would rather work with - and maybe it might actually make software a more pleasant place to be.
Very sad to see what is happening to the US. Sadder still to see it celebrated and defended by a large portion of the country. From over here in Europe, the apparent lack of accountability in the US right now is unbelievable. Where are the adults?
It is sad that opposition is not being acknowledged. There was a determined effort to restore Canada's tariffs to what they were that passed the Senate and was then blocked by an unusual maneuver from the speaker of the house which in turn got him excoriated by some Republicans in congress. Some of the biggest conservative power players and possibly the most famous and successful conservative lawyers are teaming up to challenge emergency executive tariff powers in court. Meanwhile US citizens retain high confidence in elections and Republicans nationwide are complaining in a panic that these moves will turn their precincts Democratic for decades.
But of course you are totally right. No adults anywhere. Keep thinking that Europe can count on others to pay for its defense while buying all the energy they need from Moscow. At least you have adults in the room, right?
It's true that Europe has its own problems. There are problems everywhere, at every level, from small towns to continents to the planet as a whole. This post is about the erratic actions of the current US administration. My comment is a small reflection about political trends in the US. What does Europe have to do with this?
It does not accomplish much when you try to redirect people with what-aboutisms. Mostly it just betrays your own biases and politics.
It hasn’t. Europe is still functioning perfectly well.
Let’s not start echoing far right talking points. Immigration is a topic that should be approached with measured language. Terms like ‘decimated’ is not helpful.
reply