The blessing and curse of having a prolific contributor (mostly the former). The trick is to manage burnout and figuring out continuity for these individuals to avoid massive upset in the open-source project if they decide to move on or take an extended break.
>> The trick is to manage burnout and figuring out continuity for these individuals to avoid massive upset in the open-source project if they decide to move on or take an extended break.
Another good trick would be to get more maintainers. If a bunch of people would just handle one package each...
what was your motivation ? and what changed ? I like high output in jobs, it's tiresome at times but makes me tired is lack of freedom and lack of surroundings. You'd like to organize things to promote speed and quality but some companies don't care. Good colleague will allow you to find better ideas, bad colleague will make you regress.
I have intrisic motivation, I just like what I work with and like to do a good job. I often have high standards for my work.
What changed? It's very tiresome to swim against the current. You can only care about so many things that your team doesn't until you get tired of barking at the tree.
At my new job it's the same, as usual, but I'm not forcing things and just getting with the flow. If I can, I'll suggest some ocasional improvements but if it falls on deaf ears, I'll let it go.
This is so relatable. I was looking forward to working on projects that I cared about more, but then when I got there I realized how much energy actually caring takes.
Especially in terms of emotional investment - I've decided to save my passion more for personal projects instead of spending it all where it won't necessarily go anywhere.
Good point. I got into a few discord groups about that. But I've seen some issues, everybody is very motivated.. but about incompatible things. So it doesn't work well (at least so far).
To the point I was investigating the value of money (which I often despise).. because all of a sudden, people collaborate a bit more when there's a stupid material advantage in the end.
I just suffered the same fate. There's a thick fog of absurdity in teams where people who lacks knowledge, drive and desire to do great work waste time on nothing, bragging about nothing, while slowing everything you try down (even when done with a wide care about the team operations in general) [0].
I lost the will to fight even though I think about it on a daily basis but now I just coast along. My issue is that time passes and I don't want to live my life like this so I keep dreaming of a way to sustain myself and then do better work for better purposes.
[0] it's a common pattern in groups, I've seen that in many different jobs.. it can be jealousy, old age fatigue making you sour, mob think, lack of communication but in the end, there's a natural tendency to create friction. It's the complete opposite of childhood playtime.. where everybody had one goal : maximize fun together in some game (Intrinsic motivation 100%). Adult life makes this very rare.
I know how you feel. It leads to burnout. People don't value what you're doing because it's not on their radar. Maybe I'm misaligned with the company, maybe they're unaware of the scope of what's going on.
I'm at a new company now. I care but I keep my passion elsewhere. I can't keep getting burned out so I've just fallen in line with everyone else. People are more receptive to it. I spent my time drafting emails instead of commits. I make 4 tickets instead of one mega ticket. It is what it is and I'm happier for it.
I noticed that in teams without high pressure or high leadership, the tendency is minimal effort in all dimensions. People don't want to try.. maybe it's seen as being an idiot, or ambitious i don't know, but I often see a mediocre spirit and people bailing out at 5pm because the job is not worth staying (not that i encourage staying late).
It may have been a poor choice of words intended to suggest she was "relinquishing privileges".
It's good operational and operational-security practice to ensure people don't have access to things they don't need when they no longer need them.
When I put a request in to access production to debug something, I immediately relinquish that access by way of removing my privileges, or asking operations to do so, as soon as I'm done with the task at hand.
It might have been. But but the other factors make me take it at face value. In each of the last 3 quarters, psykose had more commits than everybody else put together. Going from that to doing zero while saying she needs to sleep for a year, plus specifically dropping mantainership of everything is not just putting away a tool you don't need for the moment. It's locking in a major lifestyle change.
Hmm. Well I'm surprised to hear this actually. Figure I'll reply here. I work on a lot of open source projects and have done authorship analysis, and they do tend to follow a power distribution.
The thing is, I'm one of those authors that loves to make a bunch of changes. Fix this, fix that. I'll throw up a commit before I'll send an email about it. I love fixing things. I consider myself a programmer through and through. When I entered management, I don't get that "fix" at work, so I might code 9hr on a Saturday building something fun.
I've always viewed it as a good thing. An escape, a joy, cathartic, and pleasurable. Perhaps sometimes, it's gone too far. I left a birthday party last summer to go back and code. Though, you see, I'm also trying to build something, to do something.
So to see the full blown addiction behavior. It's like looking over the edge of a cliff. I don't think I would go that far, but for me the most important takeaway from the article was this too can be an addiction.
I disagree entirely. If we want to solve problems like "make sure packages have maintainers" we need to think very hard about human impact and human motivation.
People can be addicted to work. People can be addicted to anything that provides relief from pain while increasing the likelihood of future pain. This very site has the "noprocrast" feature, something that recognizes we can get hooked on things that can be productive.
When somebody goes from doing 6x what anybody else is doing to quitting cold turkey and saying that they're going to lock themselves out and catch up on a year of sleep, that's pretty clearly an unhealthy, unsustainable relationship. If we want to keep this from happening again, seeing what the addiction model can tell us is both helpful and relevant.
Sure. But surely you can admit that "we need to discuss maintainers mental health" is an entirely different thing than "wpietri is having a mental health episode, let's discuss"
I don't think that's what seeknotfind did. And I don't think somebody going cold turkey on an addiction is having a mental health episode; if anything, it's the opposite. But even if it were, if the article is "wpietri suddenly quits doing half of all Alpine maintenance, wants to sleep for a year", then yeah, I'd rather people discuss that then not even acknowledge the impact on me.
Some programming behaviour is addiction-like. A lot of programmers I know have spent >50 hours in front of a computer, barely going even to the toilet, to code something they're obsessed with. Don't know what to make of that really but it's not uncommon.
This always fascinating to see a person that maintains a ton of package, knowing full well that there is no way that they actively use all that software themselves. At the same time there are millions of us that just expects a package to be available, but never think to offer to at least help maintain a something. Frequently it's not even that hard, sure there are a few specialized packages which require more skills, but packaging up a Python library is something most of us could easily do.
Generally all of us needs to be better at pitching in where we can and not be depended on a few people overworking themselves.
I don't know about Alpine specifically, but many distributions put a lot of red tape around becoming a maintainer (for good reasons). I just don't want to get into it. AUR from Arch Linux has an interesting take on this — anyone can become a maintainer in a matter of minutes — and while that results in some low-quality packages and the expectation that you're supposed to review everything you install (which is easy though thanks to the excellent package format, which Alpine also uses with minor modifications), most of them are fine, and AUR gets a lot more maintainers than any other distribution.
You also don't put any obligations on yourself by becoming a maintainer on AUR — you can always orphan a package in less than a minute, no questions asked. Some users actually place new packages on AUR and orphan them right away. If it's of any use, it usually get a volunteer maintainer within a few days.
I've found packaging for Alpine has been similarly easy. There is a review process in the sense that you file an MR instead of committing directly, but my experience has been really quick and easy. Also, not everyone with commit access does this, but psykose would also fix minor issues like indentation without requesting changes and doing the whole back and forth. I really appreciated it and noticed the changes for next time.
The community and main repositories have some stability guarantees but that doesn't stop you from orphaning the package.
Fedora is particularly bad at what you describe. It's basically just impossible for somebody who isn't already in the system (or doesn't know somebody who is already in the system) to get into the system. Between hard to find documentation and requirements like, "just join the mailing list and ask for people to sponsor you" (which nobody wants to do when they don't already know you) you have to really want to do it. I could have easily maintained several packages that I built, but after sinking 4 hours into it (building the packages only took an hour or so), in the end I just threw them on my COPR and called it a day. I'm not going to spin my wheels trying to jump ridiculous non-technical hurdles and try to navigate needlessly opaque processes.
Sure, but building debian packages is akin to needing to read lord of the rings before doing anything. There's so many deb helpers and various files/file formats that need to be understood. How and where files should go. It's horrendously complex compared to PKGBUILD and makepkg.
It’s not great, true, but it’s not quite that bad. There are tools to generate templates, and “lintian” will complain about the package for most everything which is possible to get wrong.
> Fedora is particularly bad at what you describe.
Thank goodness. There is no other free Linux distro out there which gives the benefits of both a stable release with great support for most of the latest hardware AND rapid package/kernel updates (approaching a rolling release). This must not be easy since its so rare. Whatever they are doing regarding maintainership is working very well from what I can tell.
> There is no other free Linux distro out there which gives the benefits of both a stable release with great support for most of the latest hardware AND rapid package/kernel updates (approaching a rolling release).
This has nothing to do with that. They could absolutely make it easier for new people without harming their quality. For God's sake just better documentation would help, and I don't see how they're going to lose hardware support because they wrote one canonical page with all the info you need. The process should be more of a checklist to complete, and less of post-crime forensic investigation where tons of details and tips are missing and people have to draw flow charts and hunt for missing information just to figure out what the next step should be. Your reply is a (very) shallow dismissal of an actual issue and (assuming you're not alone) probably the reason this is such a problem in the first place.
Maybe so. You wanna hear something crazy? I'm still salty over MS partnering with SuSE to offer Linux indemnification from SCO's legal action in 2004. But I'm not entirely impractical. Most how-tos and tutorials cover the Debian and RedHat descendents but only occasionally cover rolling distros or SuSE derivatives.
That's...not what they meant. That's not what's happening either. It discourages newer maintainers. older maintainers eventually retire.
What a strange POV. "Thank goodness x and y are blocked off."
It's easy to make the same argument for proprietary software. "Thank goodness x or y don't allow just randos to touch their source code and make PRs. That'd be DISASTROUS!"
If you see the distros with more red tape ( cough debian cough ) , you have people "reigning in their little Package Kingdom" which also can end up with orphaned (or at least severely neglected) packages
Gentoo makes it pretty easy to add an "overlay" to get packages that someone makes, and if they get steam it becomes simple to import them into "mainstream".
~x86 helps too, masking a package is a good way to say "maybe tested, maybe not so much".
It's really hard to beat the PKGBUILD + makepkg ease of packaging. I really hope nix flakes kind of become simple and easy as time goes on. They kind of are, but nix having so many features and flexibility also means that super simple makepkg type program is sort of intertwined in a few other things.
Ideally? nix build someflake would just work. Reality is there's a few hoops at the moment which is kind of a disappointing aspect.
If nix build someflake Just Worked I could see a lot more ad-hoc type contributions happening. Better still unlike makepkg its very easy to customize a package so presumably fewer same-but-slight-variant type things tha aur has a lot of would be consolidated.
Whenever I tried to get into packaging something during the years, I've bumped into politics and policy issues associated with each project to a lesser or greater degree. Technical knowledge is not enough, you must also really get into each project's rules and mindset, find a sponsor/mentor, adhere to its standards, gain trust, attend meetings, learn a specific tool set, all of which is a whole different ballpark compared to throwing a working technical solution over the wall.
I think that's the purpose, you want to filter out anyone that is not highly motivated because otherwise you'll have to invest a ton of time into many different people and you don't have that kind of bandwidth.
> otherwise you'll have to invest a ton of time into many different people and you don't have that kind of bandwidth.
but who is investing this time and bandwidth?
It seems like this sort of governance model allows politics to replace egalitarianism or meritocracy. I could have become a Debian contributor/packager many times over, but it always seemed not worth it for a thankless job which is mostly dealing with bureaucracy and red tape instead of actually solving technical matters.
(To be fair, I've since moved on to Funtoo, which, like Gentoo, is very egalitarian -- but requires a certain, rather high, level of technical interest and expertise which is its own filtering function. On the other hand, Debian's packaging policies are very strict, and many distributions have much less strict packaging policies.)
How do the less-difficult distributions such as Arch or Alpine do it with less overhead (and is that better or worse?)
I always kind of wonder why self packaging isnt a better supported thing in general? Like if i use macos, why not read the brewfile from the repo directly and so on. Your are already trusting the software to not mess with your system to a certain extent anyway
Honestly I'm not so sure the arch packaging situation _is_ that healthy these days. More cases of updates being long delayed for stuff like glibc and some security fixes. I hope the gitlab migration ultimately opens up more contributions to a more nixos-like contribution model
This is really the barrier for me. I’ve written plenty of (company) internal packages that end up getting moderate adoption, but trying to open source is an exercise in personal marketing. It’s insufficient that your project solve a problem. You have to convince people to use it and make PRs to other repos that would use it, monitor SO for questions, etc.
My dad knew a mail carrier. Tall, lanky, energetic, and a bit of an odd duck. When he started a new route, he'd go through it quickly, finishing early. An early finish meant they'd add more to the route. He'd take that as a challenge, working even harder to get through it early. They'd extend the route again, creating another challenge.
This would repeat until he was nearly running to get the route done in time. At this point things got boring, so he'd use his seniority to switch to a new route. That mean some poor low-seniority sucker would get assigned his very demanding route and struggle desperately with it, finishing very late.
My point being that some people like being heroes, at least for a while. It seems to me kinda like the way I like running races: fun as an occasional challenge partly because doing something unsustainable causes me to push myself.
Sounds like a really terrible programmer! Too bad it at least seems to be sometimes pretty much the only way to go certain things when nobody else wants to.
After long stints with Slackware, RedHat, SuSE, and Debian, I got very much into Gentoo Linux. Kept a local copy of the portage tree. Ran a dozen servers out of my house. That sort of thing. Then, I found a new job with a very-small, highly-technical company, which had built a successful business on the back of a custom physical testing software written by the young guy who was my boss. They used Gentoo for everything. It was probably a year into the job before I went to look up something about a package, and found my boss' name listed as the maintainer. That made sense, because it was a vital package that our custom software stack depended on. Then I noticed his name on something else. Then I grepped the portage tree, and discovered that he was the maintainer of MANY HUNDREDS of packages in the distro. I believe it takes a special skill set to want to do that, but this guy was on another level. He is the most talented, yet most modest, person I've ever seen.
Gentoo has a special place in my heart... watching 2 days on a AMD Athlon 1Ghz to compile the system. I learned a lot from it not the watching part but everything else.
If NixOS were the standard distro everyone used, then I'd agree, packaging would be easy. But constant breaking changes that devs like to make complicate matters.
The stuff that's not already packaged tends to have 50 dependencies that aren't packaged, and need a version of Node that isn't packaged yet, etc.
For existing stuff, people are probably afraid the current maintainer is gonna do a better job than them, they don't want to mess something up, since breaking changes filter in from every package.
Android solves this by putting stuff in the os itself maintained by paid people, and not doing package management like Linux.
Nix solves it by making it easy to package stuff and allowing multiple versions. You can go from never used Nix to writing packages in hours to days.
Alpine's community has always seemed kind of "slap this together" combined with "figure it out yourself". I remember trying to contribute and it being a pain. Advice to the maintainers: spend a month or two finding ways to make it easier for us to contribute, and we will.
Could you describe what you found difficult? I'm pretty new to packaging on Alpine, but found it to be easy to get into, only requiring a bit more effort than the AUR.
What issues exactly did you have with contributing? I found it very easy to contribute to alpine, I wrote an APKBUILD, created a pull request, someone reviewed my PR and pointed out an issue, I fixed it and my PR was merged. I can't think of a way that could be made any easier.
No system built by committee will ever be trivially reckonable/navigable by a single person. Therefore the only people who will derive benefit from it will mostly be committees/orgs.
When one builds for oneself, or a single person, one builds under a set of constraints that truly allow for peak accessibility.
You've only got 1 person to do the whole shebang. And if one person can do it, you're on a much better footing from which to then allow anyone to do it.
As someone in the midst of building out a lab, it's been humbling, and in a way invigorating to return to grappling with building cohesive, single operator systems.
13K commits over the past year works out to almost 40 commits per day. Curious what the workflow is to accomplish that and the nature of the commits. Irrespective of that, that is super intense, sounds like she's getting a well-deserved rest.
83 comments
[ 1.7 ms ] story [ 166 ms ] threadAnother good trick would be to get more maintainers. If a bunch of people would just handle one package each...
At my new job, I'm taking it easy.
What changed? It's very tiresome to swim against the current. You can only care about so many things that your team doesn't until you get tired of barking at the tree.
At my new job it's the same, as usual, but I'm not forcing things and just getting with the flow. If I can, I'll suggest some ocasional improvements but if it falls on deaf ears, I'll let it go.
Especially in terms of emotional investment - I've decided to save my passion more for personal projects instead of spending it all where it won't necessarily go anywhere.
To the point I was investigating the value of money (which I often despise).. because all of a sudden, people collaborate a bit more when there's a stupid material advantage in the end.
I lost the will to fight even though I think about it on a daily basis but now I just coast along. My issue is that time passes and I don't want to live my life like this so I keep dreaming of a way to sustain myself and then do better work for better purposes.
[0] it's a common pattern in groups, I've seen that in many different jobs.. it can be jealousy, old age fatigue making you sour, mob think, lack of communication but in the end, there's a natural tendency to create friction. It's the complete opposite of childhood playtime.. where everybody had one goal : maximize fun together in some game (Intrinsic motivation 100%). Adult life makes this very rare.
I'm at a new company now. I care but I keep my passion elsewhere. I can't keep getting burned out so I've just fallen in line with everyone else. People are more receptive to it. I spent my time drafting emails instead of commits. I make 4 tickets instead of one mega ticket. It is what it is and I'm happier for it.
- But AI costs money to run, while maintainers are working for free...
And who maintains the AI maintainer maintainer?
It's good operational and operational-security practice to ensure people don't have access to things they don't need when they no longer need them.
When I put a request in to access production to debug something, I immediately relinquish that access by way of removing my privileges, or asking operations to do so, as soon as I'm done with the task at hand.
I'm glad they had the sense to disable their ability to publish since they don't intend to use it
What a weird speculation
The thing is, I'm one of those authors that loves to make a bunch of changes. Fix this, fix that. I'll throw up a commit before I'll send an email about it. I love fixing things. I consider myself a programmer through and through. When I entered management, I don't get that "fix" at work, so I might code 9hr on a Saturday building something fun.
I've always viewed it as a good thing. An escape, a joy, cathartic, and pleasurable. Perhaps sometimes, it's gone too far. I left a birthday party last summer to go back and code. Though, you see, I'm also trying to build something, to do something.
So to see the full blown addiction behavior. It's like looking over the edge of a cliff. I don't think I would go that far, but for me the most important takeaway from the article was this too can be an addiction.
People can be addicted to work. People can be addicted to anything that provides relief from pain while increasing the likelihood of future pain. This very site has the "noprocrast" feature, something that recognizes we can get hooked on things that can be productive.
When somebody goes from doing 6x what anybody else is doing to quitting cold turkey and saying that they're going to lock themselves out and catch up on a year of sleep, that's pretty clearly an unhealthy, unsustainable relationship. If we want to keep this from happening again, seeing what the addiction model can tell us is both helpful and relevant.
Generally all of us needs to be better at pitching in where we can and not be depended on a few people overworking themselves.
You also don't put any obligations on yourself by becoming a maintainer on AUR — you can always orphan a package in less than a minute, no questions asked. Some users actually place new packages on AUR and orphan them right away. If it's of any use, it usually get a volunteer maintainer within a few days.
The community and main repositories have some stability guarantees but that doesn't stop you from orphaning the package.
Thank goodness. There is no other free Linux distro out there which gives the benefits of both a stable release with great support for most of the latest hardware AND rapid package/kernel updates (approaching a rolling release). This must not be easy since its so rare. Whatever they are doing regarding maintainership is working very well from what I can tell.
This has nothing to do with that. They could absolutely make it easier for new people without harming their quality. For God's sake just better documentation would help, and I don't see how they're going to lose hardware support because they wrote one canonical page with all the info you need. The process should be more of a checklist to complete, and less of post-crime forensic investigation where tons of details and tips are missing and people have to draw flow charts and hunt for missing information just to figure out what the next step should be. Your reply is a (very) shallow dismissal of an actual issue and (assuming you're not alone) probably the reason this is such a problem in the first place.
What a strange POV. "Thank goodness x and y are blocked off."
It's easy to make the same argument for proprietary software. "Thank goodness x or y don't allow just randos to touch their source code and make PRs. That'd be DISASTROUS!"
Maybe it is shortsighted in the long run? We'll see. I'm glad that we have choices -- AUR on one hand, Fedora on the other (and Debian, Alpine, etc)
If you see the distros with more red tape ( cough debian cough ) , you have people "reigning in their little Package Kingdom" which also can end up with orphaned (or at least severely neglected) packages
~x86 helps too, masking a package is a good way to say "maybe tested, maybe not so much".
Ideally? nix build someflake would just work. Reality is there's a few hoops at the moment which is kind of a disappointing aspect.
If nix build someflake Just Worked I could see a lot more ad-hoc type contributions happening. Better still unlike makepkg its very easy to customize a package so presumably fewer same-but-slight-variant type things tha aur has a lot of would be consolidated.
but who is investing this time and bandwidth?
It seems like this sort of governance model allows politics to replace egalitarianism or meritocracy. I could have become a Debian contributor/packager many times over, but it always seemed not worth it for a thankless job which is mostly dealing with bureaucracy and red tape instead of actually solving technical matters.
(To be fair, I've since moved on to Funtoo, which, like Gentoo, is very egalitarian -- but requires a certain, rather high, level of technical interest and expertise which is its own filtering function. On the other hand, Debian's packaging policies are very strict, and many distributions have much less strict packaging policies.)
How do the less-difficult distributions such as Arch or Alpine do it with less overhead (and is that better or worse?)
How does one start a successful monastery, by the way?
This would repeat until he was nearly running to get the route done in time. At this point things got boring, so he'd use his seniority to switch to a new route. That mean some poor low-seniority sucker would get assigned his very demanding route and struggle desperately with it, finishing very late.
My point being that some people like being heroes, at least for a while. It seems to me kinda like the way I like running races: fun as an occasional challenge partly because doing something unsustainable causes me to push myself.
The stuff that's not already packaged tends to have 50 dependencies that aren't packaged, and need a version of Node that isn't packaged yet, etc.
For existing stuff, people are probably afraid the current maintainer is gonna do a better job than them, they don't want to mess something up, since breaking changes filter in from every package.
Android solves this by putting stuff in the os itself maintained by paid people, and not doing package management like Linux.
Nix solves it by making it easy to package stuff and allowing multiple versions. You can go from never used Nix to writing packages in hours to days.
Other distros put much more work on humans.
One person trying to do too much is no bueno. It needs to be a team effort and consumers need to step-up to be occasional producers as well.
No system built by committee will ever be trivially reckonable/navigable by a single person. Therefore the only people who will derive benefit from it will mostly be committees/orgs.
When one builds for oneself, or a single person, one builds under a set of constraints that truly allow for peak accessibility.
You've only got 1 person to do the whole shebang. And if one person can do it, you're on a much better footing from which to then allow anyone to do it.
As someone in the midst of building out a lab, it's been humbling, and in a way invigorating to return to grappling with building cohesive, single operator systems.
As an aside, I really should learn how to package stuff for alpine.