It seems to me like working from home has transformed the residential neighborhoods. I recently visited Inner Sunset as was astonished at how many people were out and about.
Unfortunately I feel like recruiters at larger companies are squinting at CVs and think like: "Open source? Entrepreneur? Eh, oh. Smell of despair and discarded pizza boxes.".
Of course unless your passion project is very successful one, but majority of them are not.
While I agree with the sentiment you are delivering, I think successful is probably the wrong word here.
I worked on a repo for several years with many tens of thousands of lines of code and attempted to promote it heavily with little success. At some point I chopped out about 2,500 lines of code from that repo and packaged just one feature as a standalone product.
Years later the child repo has thousands of users and the parent has barely any. While I consider both projects to be successful by definition, if I'm going to briefly showcase one over the other I'll showcase the smaller project that received more engagement. Because the engagement metrics do indeed matter. It lends credence and legitimacy to a project.
> One of the things which gets very frustrating from the maintainer's
perspective is development teams that are only interested in their pet
feature, and we know, through very bitter experience, that 95+% of
the time, once the code is accepted, the engineers which contribute
the code will disappear, never to be seen again.
This was painful for me to read as someone who has seen how corporations think about “Open Source” - he isn’t wrong at all
He's not wrong, but he hasn't addressed the problem:
Some maintainers are rejecting changes as a way to block a project they disagree with - ie. there is no path forward for the contributor. I wouldn't assume this normally, but they're not hiding this fact, it's self proclaimed.
On the other hand, Linus has been largely in favour of the R4L project, and gave the green light for it to go ahead.
The Linux kernel maintainers need to figure out among themselves whether they want to allow Rust to be introduced or not, and if so under what constraints. If they can't come to an agreement, they're wasting everyone's time.
Once that happens, either the project is canned, or people can stop arguing over if these changes should be upstreamed, and start arguing over how instead, and that's a lot more productive.
It's not the maintainers job to make your project happen.
It's yours.
If you need someone to do free work but you can't convince them then you either get their boss to tell them to do it, you take over their job, or - the one thing that no one under 30 ever seems to do - fork and do the work yourself without anyone stopping you.
Reducing this to age is overly simplistic. When Linux was younger and simpler, it may've been easier to fork, but today it's a massive system with huge inertia behind it. Even if you are right in principle regarding your changes, it's extremely hard to overcome that inertia.
In the related submission on this topic [1], the author makes this argument in a lot more detail, that it's essentially impossible to make a Linux fork sustainable without massive investment that no one can realistically obtain.
Noone's asking the maintainers to make the project happen.
It is the maintainers job to determine whether a project should be pursued at all.
If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer!
That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent decision regarding R4L.
Yes but the parent has addressed this and you're just talking past them like they didn't comment. If the maintainers don't want it to happen then they need to come to an agreement that it won't happen. If they do want it to happen then they need to stop blocking it for non-technical reasons. If they can't actually decide then that's "no" or up to the project lead to enforce the decision at the risk of losing maintainers.
Wow, the entitlement here is absolutely amazing. You are not entitled to any work, or explanation, or "agreement". Show me where it says maintainers owe you any of this at all.
I think that being open to working with others is implicit in deciding to maintain a widely used project like Linux. There's tons of open source tools which are explicit "this is something you are free to use but I created it for my own purposes and don't intend to support it"; however, that isn't how Linux presents itself.
That is to say, if you are building an tool as a collaborative open source project, then that implies that you intend to collaborate.
They don't owe me anything, I don't work on it and have no oar in one way or the other. I'm sure they don't give a fuck about any of these conversations. Still, I owe you nothing and I can put forth my opinion, as can you.
Maintainers are gatekeepers. If parties on either side of the gate aren't accomplishing what they want/need, they naturally look at the gatekeeper. If both sides of the gate agree that the gatekeeper has become problematic, discussions popup to remedy the situation.
So far, I haven't seen discussions from both sides of the wall. But I hear a lot of noise from one side of the wall trying to get the attention of people on the other side of the wall. Now we will see if the people inside the wall think there is an issue with the gate.
> If you're asking them to accept your code then yes, you' are asking them to support your project forever.
> If you weren't sending them patches then they couldn't block you. Since you are they can.
One of the big turning points of this drama was a maintainer from a different area (who had been CCed on the threads, but was not the person the patch was being submitted to) blocking a patch that they weren't going to have to maintain.
He NACKed the patch. Blocking the pack would mean that he is in a position where that NACK is final, which isn't clear at all. If that isn't the case then the NACK is only an opinion that it's a bad idea.
But saying that he is't going to have have any additional maintenance burden just because the rust code using his subsystem is in a different subtree is also not an honest assesment of the situation. That's not how the kernel developent works.
>Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.
Then say that. A big part of the issue is that there has been mixed signals from the Linux maintainers about R4L. Linus seemed to have supported it, and others are trying to block it.
The maintainers should get on the same page about the inclusion of rustlang code, and communicate that.
They can absolutely block you if the code is not good enough. But if they don't want to accept the code at all, then just say from the outset "I'm not accepting rust code", rather than waste everyone's time.
I agree with you completely. If rust is so great why not make a new kernel with it and compete? or fork and start rewriting subsystems?
I do also understand the frustration when an open source project strings you along (me: can I join your club?), ask for this and that (them: sure if you pay your dues), ensuring your cover every "important" person's pet use case (them: and also buy us lunch), then publicly snark about the whole thing (them: this new guy know about no mustard on the lunch!) and kill your failing motivation (me: oh, sorry).
That's why the fork is so appealing. If it's good enough for long enough you get to join the club.
What I don't get is the complaints from the Rust people.
If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden.
Then they can write every driver they can imagine to their hearts' content.
The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.
The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel.
It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
That doesn't make sense, and you can look at the patches and see that the Rust code didn't impact the C code. It's not like we have to take anybody's word for it.
This is primarily around Rust filesystem drivers. If you want to run a filesystem but it's implemented in Rust, you'd have to use that fork. If another person had the same issue (say a GPU driver that some maintainer decided they didn't like because of the country of origin or some other petty reason), then that would have to be a fork as well. Suddenly, you can't use that GPU with a Rust-implemented filesystem, because you have to pick one of the forks, or you have to make your own merged kernel from the two.
"Just fork it" doesn't work here. It's a logistical nightmare.
Rust developers are promising that rust in the kernel should have no impact on c in the kernel.
If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.
IIRC Linus has been in favor conditioned on the agreement of the respective subsystem maintainers. Meaning, he’s not deciding over their heads. And introduction of Rust can be handled differently from subsystem to subsystem.
That doesn't exactly strike me as a bad thing? Isn't that sort of the point of open source? Lots of people working on the things that interest them and through a diversity of interests arriving at a useful project?
Aside from this being a great article with lots of interesting details, it's also a rare example of a headline that does NOT follow "Betteridge's law of headlines"
Not trying to neg how you phrased it, but I wonder if the whole damn system would be a smidge better if we had strong well-worn widely-used terms to discriminate between profit-taken and surplus-reinvested (and maybe to further discriminate between unrelated r&d, related r&d, and direct performance/capacity/resiliency/etc. investments)
Can you distinguish effective investment from ineffective? For example, paying competitively to attract and retain talent can be seen as an investment as well. And before you restrict it to just physical infrastructure investment, a non-trivial part of the cost of that infrastructure is in salaries and also how you manage everything at scale and I would think you’d want to incentivize more efficiency there too. This is why the tax code gets so insanely complicated.
I'm a little unsure how to take you here, because I avoided dragging the efficacy of an investment into frame on purpose.
Maybe you just mean to tack on the idea that we could benefit from having better language to separate shrewd and incompetent investments, in which case I'm ~fine with some language to retcon the difference between merely lighting investments on fire and using them to drive an engine back on to those investments once we know the difference.
But if you mean to suggest that it's pointless for us to bother discriminating between profit-taken and investment-(effective|ineffective) just because we don't know whether the cat is dead or alive yet, then I suspect I disagree to the death.
(Edit: In case I'm being obtuse, I at least think I agree that "investing" surplus in hiring and retaining great employees is a surplus-invested, and not a profit-taken.)
> (Edit: In case I'm being obtuse, I at least think I agree that "investing" surplus in hiring and retaining great employees is a surplus-invested, and not a profit-taken.)
So the executive compensation packages that many people hate on then are just a mechanism to reduce the profits of the company. And it’s not clear to me that Apple saving up profits so they can make larger investments without taking out loans is a strategy we want to disincentivize either.
My point is that designing top-down incentives at market scale are very difficult and while attractive are basically the central failure of central planning. Even setting aside the challenge of figuring out how to word the incentives correctly in a way that maximizes gain and minimizes gaming of the system (basically impossible) in a political system you also have to get buy in from people who don’t see it your way which muddles your ideal solution regardless of you being right or wrong. I’m highlighting that’s how and why we have the current tax system - it’s many many people trying to tweak and optimize incentives and curtail problems over a long period of time.
(It feels like you are talking like you're gotcha-ing me, but I don't feel like I am trying to address any of these problem at the level you are focused on.)
I wouldn't say surplus held to be invested, even for many years to support a large capital project, is profit-taken. The surplus isn't being taken. (But, as before, I do still think it may be worth discriminating between related/unrelated, because this is somewhat relative. A large for-profit utility could extract surplus from most of its regional markets and plow it all into supreme resiliency for the city its headquarters is in...)
Designing good incentives or tax policy are very different problems than having slightly better vernacular for average people to use to distinguish between patterns of organizational behavior that throw surplus in a bin for a truck to take away and those that toss it in a compost pile for on-site use.
Accountants and auditors can classify inflows and outflows however they like--but I think specific problems like good incentives are more tractable when common people can leverage simple language to build the understanding and support that policy wonks will need to dial in incentives or tax policy.
reply