So the new way to contribute is to fork Make a better Ladybird successfully to the point the original contributors take notice. If the barriers to doing that are truly lower, then it should be easier.
Good luck!
Changing how we develop Ladybird
351–360 of 602 posts
Re: Changing how we develop Ladybird
#352Earlier quoted context omitted.
>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…
I sense your comment as saying: "AI is hype, and reality will catch-up.". But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies. Reality will catch-up with that too, once the other smoke clears.
I can believe that the difference between the slowest programmer in the world and the fastest AI aided programmer in the world is now 100x in terms of lines of code output. Like I can imagine a programmer writing 250 lines of code per week by hand and I can imagine an AI powered person writing 25,000 lines of code per week.
Re: Changing how we develop Ladybird
#353Their loss. Think about it. Anthropic just reported that their codebase is now improving itself. We're moments away from every open source repo being able to do the same. Think of it like torrenting — you'll be able to open your repo to the public, and have a stream of code flow in from millions of contributors. More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days. Lad…
> open your repo to the public, and have a stream of code flow in from millions of contributors. More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days. why would you want this. this sounds terrible
It would be free labour! Truly crowd-funded development.
I'm picturing something like folding@home, but where people donate their spare tokens to a service, and those tokens get distributed amongst all open source projects on GitHub. You don't think that would be cool? Like, someone might initialise a repo with only a readme and a to do list before they go to sleep, and then wake up to a complete software ecosystem that looks as if it's been in development since before they were born. Like, so much code that no one person could possibly understand it, and it all happened overnight while they were sleeping!
Re: Changing how we develop Ladybird
#354Earlier quoted context omitted.
>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…
> Juniors want this to be a chance to shine in a market that otherwise rejected them. I actually am training 2 trainees (Azubi in German) and 1 working student. All three are somewhat anxious about the future but also all are learning in a significantly increased pace, compared to the ones I worked with 1.5 years ago. They don't have to wait for random senior to answer questions, so they get stuck way less often. The…
I am skeptical. This is a testable hypothesis, and I know there have been tons of research done trying to provide evidence of claims like these. However I have yet to see a convincing evidence. If this statement was indeed true, I think experimental data backing it up would be old news at this point, it however is not, and I suspect that is because junior developers are by and large in fact not learning faster or more with the help of AI.
Re: Changing how we develop Ladybird
#355This seems quite misguided and is sad to see. They have every right to do this, but I was looking forward to continuing testing Ladybird as it improves and contributing in the future. I hope servo stays open to contributions, as it seems like it's all we have left.
You can still contribute through bug reports.
Re: Changing how we develop Ladybird
#356On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working. On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
I’m never getting accustomed to the fact that there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style (are people these days even aware of the metaphor or Raymond’s book?), a world in which the frigging Microsoft is a major OSS vendor and in charge of facilitating most of the open-source programming on the planet. Try explaining that to a time traveler from the late 90.
(Also, as a sibling comment implied, the archetypal "bazaars", like the Linux kernel project, now appear quite cathedral-like in conparison to the free-for-all GitHub model!)
Re: Changing how we develop Ladybird
#357Earlier quoted context omitted.
It's interesting to see this perspective in the wild. In the age of AI I wonder what "massive value" your PR is bringing to the maintainer. $1 worth of tokens?
[flagged]
I regularly find the code output of opus and gpt 5.5 to be garbage. Overly verbose, unnecessary abstractions, strange duplication of concepts across objects, unnecessary copying of objects and creation of objects. I have found its much more useful to just ping pong some ideas, have it generate helper methods, and do the code implementation by hand.
I guess I am a stoneager.
Re: Changing how we develop Ladybird
#358Goodhart's law, again.
I feel like 1/10 comment I make on HN are about this.
So merged PR were until LLMs a good proxy for the ability to code and contribute to a software project. Consequently they were used to estimate if a candidate was potentially good for a position. Merged PR on popular project were thus precious credentials one could "trade" for potential work. Since then the desire to provide PR changed from contributing to a project for its own sake, to make the actual project progress, to signalling.
A new proxy must be found to establish the ability to contribute to a project.
Re: Changing how we develop Ladybird
#359Earlier quoted context omitted.
>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…
> Juniors want this to be a chance to shine in a market that otherwise rejected them. I actually am training 2 trainees (Azubi in German) and 1 working student. All three are somewhat anxious about the future but also all are learning in a significantly increased pace, compared to the ones I worked with 1.5 years ago. They don't have to wait for random senior to answer questions, so they get stuck way less often. The…
Is that a good thing? I think getting stuck is an intrinsic part of the learning process and sometimes it's good that there isn't an immediate answer from a senior. For some things you'd never have solved yourself, sure. But pain and suffering is a big and important chunk of learning and I fear we just throw it all out of the window with asking AI.
Re: Changing how we develop Ladybird
#360I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…
The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort. In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a…
> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't have the actual engineering background required to do the work.
If I had to push this take to the extreme: software engineers never learned class solidarity and it's now biting the industry in the ass.