[HN Gopher] Attracting and Retaining Debian Contributors
___________________________________________________________________
Attracting and Retaining Debian Contributors
Author : sohkamyung
Score : 108 points
Date : 2024-09-20 06:21 UTC (4 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| mistrial9 wrote:
| for those (rightfully) complaining about the experience of making
| dot-deb packaging .. yes all true and needs to improve YET the
| Apple iPhone app developer experience has been tremendously
| painful and rude for a decade also.. somehow given $INCENTIVES
| the app devs for iPhone just consider it table stakes?
| adamc wrote:
| Money is a powerful incentive.
| robocat wrote:
| Except for 99% psych studies showing that it is a poor
| incentive[1].
|
| Talking to a person doing hotel reservations today - his
| personal incentives were to do give quality service
| (unfortunately the managers incentives were financially
| misaligned with that!). Most job satisfaction seems to be
| derived from internal incentives and money is not that good
| in my experience. Maybe different in the USA from New
| Zealand.
|
| [1] see psych reproducability studies.
| ericjmorey wrote:
| All of that is demonstration that money isn't an ideal
| means of incentive, but I have never worked a job without
| getting paid despite being asked many times to do exactly
| that.
| adamc wrote:
| No, that demonstrates that the monetary delta wasn't a good
| incentive. But I challenge you to find a lot of people
| working jobs without pay. There are some, if they have
| independent means, but not many. Likewise, most fiction
| authors expect at least the _potential_ to make an income
| if enough people read their book -- etc.
|
| There are other incentives, for sure. Evidently not enough
| of them attract Debian contributors.
| o11c wrote:
| Apps are usually first party, which makes a big difference.
|
| The thing that seems to be relatively rare about Debian among
| Linux distributions is that the packaging data is _intrusive_ -
| a debian / directory within the package itself, which must have
| already been downloaded. Most other distros seem to have
| _external_ packaging - some sort of package specification that
| _points to_ the URL of the upstream and is responsible for
| pulling it.
|
| It _cannot_ be overstated how much friction this inversion
| adds, whether for new packages, for updated upstream packages,
| or for distro-specific (hopefully temporary, but Debian has a
| bad record for that) patching.
|
| (I actually tried filing this as a bug once, but it immediately
| got moved to the mailing list, and I promptly got un-CC'ed and
| stopped being able to reply, since what lunatic actually
| subscribes to a firehose of a mailing list? Email also
| considered harmful)
| candiddevmike wrote:
| Debian losing contributions is a fairly big deal because Debian
| and its derivatives represent the most popular Linux
| distributions.
|
| You'd think Canonical would contribute more...
|
| I think there's also a larger conversation of what folks really
| need from a Linux distribution in the year 2020+. Desktop Linux
| is fairly needy but AppImage and flatpak have largely fixed that.
| mass_and_energy wrote:
| Do we want canonical that involved in our beloved Debian? Look
| at what they did to glorious Ubuntu, if they think Snap is a
| good addition to any OS then should we listen to their input?
| bee_rider wrote:
| Canonical was with Ubuntu from the beginning, so if it was
| ever glorious, that was partially their doing.
| jcastro wrote:
| > that involved in our beloved Debian?
|
| They've been there for 20 years already.
| bregma wrote:
| What percentage of Debian Developers are Canonical employees?
| 40%? 60%?
| Rinzler89 wrote:
| The beauty of Linux is that we can have a _new_ popular Linux
| distro. It doesn 't have to be Debian based. It can be
| Opensuse, Fedora or Arch based.
| develatio wrote:
| > You'd think Canonical would contribute more
|
| Context: I have +10y exp with Python, Linux (some packaging,
| kernel hacking, sys admin / SRE), C, several cloud providers
| (AWS, Azure, Hetzner, DO, OVH), etc...
|
| Applied to a Canonical position (Senior Python Eng + required
| Linux exp + nice to have cloud knowledge), got rejected
| automatically because I don't have a university degree.
|
| Tweeted about it, asking for some feedback. Tons of replies,
| same opinion: Canonical are plain elitists.
|
| Don't expect them to contribute.
| rlpb wrote:
| > You'd think Canonical would contribute more...
|
| How much is enough? Did you know that significant contributions
| to Debian are made by Canonical employees who are Debian
| Developers being paid to do so?
|
| As a recent example, Debian's recent 64 bit time_t transition
| was driven by Canonical employees. Canonical employees continue
| to maintain various packages in Debian, but it's not obvious
| because they use their Debian "hats".
| kombine wrote:
| I see little reason to use Debian on a personal computer, despite
| using a Debian-based distributions (Ubuntu and Debian itself) for
| more than 10 years. I switched to Fedora and OpenSUSE Tumbleweed
| and they perfectly fit my needs.
| pmontra wrote:
| Honest question. What do they do that Debian or Ubuntu don't?
| dilawar wrote:
| For openSuSe, their open build service is awesome. You can
| create packages in your personal repos and submit to the
| official repo in one click. Though zypper (suse package
| manager) download packages serially and takes a lot of time
| during upgrades.
| Yasuraka wrote:
| Major advantage of Fedora is being closer to the upstream
| sources, both in terms of freshness and in terms of not
| meddling with libs or similar. Debian patches lead to several
| possible exploits over the last few years.
| yjftsjthsd-h wrote:
| > Debian patches lead to several possible exploits over the
| last few years.
|
| Which ones? There was the OpenSSL entropy bug, of course,
| but that was 1. in 2006, and 2. run by upstream so feels a
| bit unfair.
| lucifargundam wrote:
| I'll concede with it being a matter of preference. For me, I
| used Debian for everything. I even use it to play VR games on
| Steam.
| loughnane wrote:
| Same for me
| mvavassori wrote:
| Genuine question(s): Who pays maintainers? Are they even paid? If
| they aren't paid, why do they do it?
| candiddevmike wrote:
| This is the open source paradox. Fun, fame, power/control,
| employment... If you think about it, with how useful/critical
| some open source projects and distributions are, it seems
| bizarre to have what amounts to a "group of monks of yore"
| maintaining it vs government funded.
| binary132 wrote:
| At least monks have free time and presumably sponsorship or
| at least survival necessities
| stcroixx wrote:
| The first generation of open source devs did it for fun and
| ideological reasons. Back then, before any of the big tech
| companies even existed (except Microsoft, who was widely hated)
| software was not a highly paid profession, more in line with
| being a CPA, so people looking to maximize their earning
| potential weren't in the field at all. Those people did finance
| back then.
| skobes wrote:
| I had the same thought. For all the talk of lowering
| barriers... should we really be surprised that unpaid labor is
| hard to find?
|
| Maybe if I were independently wealthy I would spend my time
| contributing to Debian.
| 5040 wrote:
| >should we really be surprised that unpaid labor is hard to
| find?
|
| Music is mostly unpaid labor and there's no shortage of
| musicians.
| dingnuts wrote:
| making music is a lot more fun than making software and way
| more immediately, personally, and emotionally fulfilling
|
| I say this as an accomplished programmer and an absolutely
| shit musician. the parts of programming that are fun and
| the parts that make money, also, have almost no overlap
| whatsoever
|
| lucrative business problems that are also fun or
| interesting computer science problems are so rare that
| whole companies are built around a single interesting CS
| problem surrounded by a fleet of mundane business problems
| bityard wrote:
| I nearly down-voted this question because every time funding
| and open source come up together, there will be a lot of
| arguments about it.
|
| But to answer your question: Debian maintainers are not paid to
| maintain Debian. People volunteer to work on the Debian project
| because it's something they use, love, and believe in. Working
| on Debian is where they get their passion and joy, money comes
| from somewhere else.
|
| A few maintainers few _might_ get paid by their employer to
| work on Debian packages that the employer has a vested interest
| in. As an example, there were some Canonical employees who were
| also Debian maintainers, but I don't know if this is still true
| today. I think there are a few companies that tend to hire
| established Debian developers, like Freexian.
| taftster wrote:
| Do you feel like Debian has it different (worse) than other
| distributions? Does Debian not have the same number of
| maintainers paid by corporations, etc.? Like in comparison to
| Ubuntu or Redhat?
| jmclnx wrote:
| Getting smart young people to contribute to Linux Distros (and
| BSD for that matter) to me is a tough job.
|
| Linux kicked off in the 90s because young people at that time
| wanted a real OS, so Linux came out and people flocked to improve
| it.
|
| Today, almost all kids use Cell Phones, which are all locked
| down. I think only a few young kids rely on PCs, thus the issue.
| I hope it can be solved at some point and good contributors can
| be found. Otherwise we will be left with just IBM Red Hat.
| shakow wrote:
| > Getting smart young people to contribute to Linux Distros
| (and BSD for that matter) to me is a tough job.
|
| I mean, they came with enthusiasm and a lot of hard work,
| brought a new language with many advantages (as said by the
| BDFL humself), dusted off the whole GPU stack, tried to
| formalize a bit the FS systems, then got shunned out by the
| greybeards because "muh youngsters and their religion".
| arp242 wrote:
| That's not really a fair representation of the argument, and
| the stereotyping of everyone who disagrees or expresses some
| caution as an old stubborn greybeard who refuses to learn
| anything new is exactly the thing people (rightfully)
| complain about.
| shakow wrote:
| Please feel free to develop what you perceive as being a
| fair representation of the situation.
|
| > or expresses some caution
|
| Bellowing about religions while monopolizing a talk Q&A is
| not "expressing some caution".
| arp242 wrote:
| I'm not going to spend half an hour (or more) doing a
| full detailed write-up in response to a lazy assertion,
| especially since your attitude does not resemble that of
| a person with genuine interest in understanding other
| people's viewpoints.
|
| Stereotyping an entire viewpoint as you did in your
| previous comment is pretty much always wrong. I might be
| a bit more forgiving if it has included _some_ context or
| details, but it doesn 't. Your post is little more than
| an insult.
|
| I will add that people having been choking each other
| over all sorts of technical stuff for as long as this
| "free software" thing has existed, because there are
| usually 20 ways to do anything and typically between 2
| and 10 ways are reasonable. This is really nothing new
| and discussions surrounding Rust are really not that
| special.
| NobodyNada wrote:
| The full quote:
|
| > You're trying to convince everyone to switch over to
| the religion as promulgated by Rust, and the reality is
| that ain't gonna happen because we have 50+ filesystems
| in Linux. They will not all be instantaneously converted
| over to Rust. Before that happens, we will continue to
| refactor C code because we want to make the C code
| better. If it breaks the Rust bindings, at least for the
| foreseeable future, the Rust bindings are a second class
| citizen, and those filesystem that depend on the Rust
| bindings will break, and that is the Rust bindings
| problem, not the filesystem community at large problem,
| and that's going to be true for a long long time. And I
| think we just simply need to accept that, because the
| answer "you are not allowed to refactor the C code
| because it would break 5 critical filesystem that distros
| depend upon" is not a starter. So we'll see; I suspect
| the best thing to do is for you to continue maintaining
| your Rust bindings. Over time, there will be continued C
| code refactoring -- maybe we will start using kfree RCU.
| If that breaks Rust, we will find out whether this
| concepts of encoding huge amount of semantics into the
| type system is a good thing or a bad thing, and instead
| of trying to convince us to what is actually correct,
| let's see what happens in a year or two. And it will
| either work or it won't, and we will see, more likely,
| where does the pain get allocated. Because with most of
| these sort of engineering things it's almost always a
| pain allocation question.
|
| > [...]
|
| > You're not going to force all of us to learn Rust -- if
| I make a change, I will fix all of the C code, because
| that's my responsibility. Because I don't know Rust, I'm
| not going to fix the Rust bindings.
|
| Some of his language is more emotionally charged than was
| productive, sure, but I think his underlying concern is
| reasonable: most kernel maintainers don't know Rust, and
| so when they make changes to C code, they won't be able
| to fix Rust clients of that C code. The Rust maintainers
| accept this, and agree to take responsibility for
| updating Rust code to match changes in C (which is
| contrary to the usual development workflow of the kernel,
| hence the concern over what happens if major distros
| start depending on Rust code).
|
| Note also that Ts'o isn't objecting to including Rust in
| the kernel! His recommendation is to ship the Rust
| bindings and see "where the pain gets allocated" as the C
| code continues to evolve. (The idea being that either
| Rust's type system and borrow checker will make it easy
| to identify semantic breakages early, thus making Rust
| code lower-maintenance than C, or the Rust bindings will
| turn out to be fragile and high-maintenance, and that the
| best way to tell is by waiting to see).
|
| I'm not a part of the Linux kernel community at all, and
| I certainly don't know all the context that led to
| Almeida leaving the project -- I imagine Ts'o's comments
| were a "straw that broke the camel's back" kind of thing.
| But the Linux kernel is a complex project and critical
| infrastructure, so surely concerns about organization and
| maintainability need to be hashed out before Rust can
| make it to production.
|
| Also, Ts'o's comments struck me as some of the _most_
| reasonable out of that talk, at least from a technical
| perspective -- the next commenter after Ts 'o objects to
| Rust in the kernel on the basis that its function call
| syntax reminds him of Java.
| steveklabnik wrote:
| > (which is contrary to the usual development workflow of
| the kernel, hence the concern over what happens if major
| distros start depending on Rust code)
|
| The issue here is that this wasn't decided in this
| moment: it was decided as soon as the Rust was approved
| to merge. You're right that it's a concern, which is why
| it was addressed back then, and so a few years later,
| bringing it up feels like an argument in bad faith rather
| than a genuine attempt to bring a concern to the table.
| arp242 wrote:
| Just because it was discussed way back when doesn't mean
| everyone has to accept the resolution from that. People
| obviously think it wasn't addressed in a good way.
|
| There's a lot that you can say about all of that, but
| calling it "bad faith" is not great, to put it mildly. I
| had seen the video before, but didn't realize the person
| speaking is Ted Ts'o (I'm sad case and don't recognize
| Linux developers by voice alone). Ted has spent about 30
| years working on all of this stuff, including investing a
| great deal of his spare time on it. He isn't some sort of
| random internet troll or anonymous HN user. Dismissing
| his views as "bad faith" does not leave me impressed.
| steveklabnik wrote:
| I don't see how anyone but Linus could sign off on
| changing something as large as "Rust code is now required
| to build the kernel." I'm also not aware of anyone
| suggesting that should change.
|
| I know who Ted is as well. That's why I expect better
| behavior. Then again, I'm not involved in any way, so my
| opinions don't really matter.
| renewiltord wrote:
| Rust on Linux will happen. One way or another. At the worst,
| one funeral at a time. I wouldn't sweat it.
|
| I remember a HN comment that I really liked and can't find
| now that went something like:
|
| You know what stopped me from programming? It wasn't that I
| didn't have a good computer. It wasn't that I started later
| than all the other kids. It wasn't that I had to work.
| Nothing. Nothing stopped me from programming.
|
| There'll always be folks like that. And I hope I'll be like
| that for some thing too!
| mustache_kimono wrote:
| It's a shit take, but I like it.
| cesarb wrote:
| > Linux kicked off in the 90s because young people at that time
| wanted a real OS
|
| It's easy to underestimate how inferior MS-DOS was, unless you
| lived through it. Windows (3.x and later 9x) was slightly
| better, but still had severe issues. Modern Windows is, from
| what I've heard, a lot better, so the incentive to migrate is
| not as strong.
|
| > Today, almost all kids use Cell Phones, which are all locked
| down.
|
| Not just cell phones; with Secure Boot and BitLocker, computers
| are more locked down too. In particular, BitLocker means that
| it's harder to share disk space between Windows and an
| alternative operating system; back in the MS-DOS (and Windows
| 9x) days, it was not unusual to install Linux in a directory
| (or a disk image file) on the same partition used by the other
| operating system.
| arp242 wrote:
| > Not just cell phones; with Secure Boot and BitLocker,
| computers are more locked down too.
|
| You can just disable secure boot, no? I just got a brand new
| laptop today, and I could just disable it. I know you can get
| Linux to work with it, but I can't be arsed to mess about
| with it and the practical security benefits for me are
| basically zero.
|
| Also, don't underestimate the friction that existed in the
| 90s or early 00s. Nothing worked on Linux or BSD. My
| government sent me .doc files. Tons of stuff was Windows-only
| desktop software.[1] Mucking about with xfree86 -configure
| and /etc/X11/.... was far from easy or straight-forward.
| Internet access was far more rare and "just Google it" wasn't
| really a thing, etc. etc. etc.
|
| If I look at the amount of effort I spent to "just get Linux
| running" back in 2000 or so when I first tried it vs. today,
| then I'm fairly sure the overall experience is a lot better
| today. Sure, you need to deal with some stupid nonsense, but
| that was always the case.
|
| [1]: For all the hate the "modern web" gets from some people
| here: it does replace tons of crappy desktop stuff with an
| abstracted isolated VM which, among other benefits, makes
| running "alternative" systems like Linux or BSD far more
| viable.
| Filligree wrote:
| > You can just disable secure boot, no? I just got a brand
| new laptop today, and I could just disable it. I know you
| can get Linux to work with it, but I can't be arsed to mess
| about with it and the practical security benefits for me
| are basically zero.
|
| An imagined conversation:
|
| "Mom, I want to disable secure boot so I can try a free
| operating system."
|
| "Oh no you don't. Security is important."
|
| This won't happen to anyone who actually knows what they're
| talking about, but it's having a real impact on the
| pipeline for getting there. The conversation isn't as
| imagined as all that.
| arp242 wrote:
| Systems like Ubuntu, Suse, etc. should "just work" with
| secure boot. This has been the case for over 10 years
| (Ubuntu starting with 12.04, in a quick check). I just
| run a custom hacked-up version of Void Linux because I'm
| cool like that, but no one new to Linux is doing that -
| they start out with Ubuntu or such, just as I started out
| with Mandrake back in the day.
|
| Also I actually got my laptop with Ubuntu pre-installed,
| a concept that barely existed in 2000.
| whyoh wrote:
| >In particular, BitLocker means that it's harder to share
| disk space between Windows and an alternative operating
| system
|
| BitLocker is completely optional, even on Windows 11
| (although in some cases encryption does kick in automatically
| - but you can revert it).
|
| And if you want to both use BitLocker and share files with
| another OS, you can easily do it with a separate unencrypted
| drive or partition.
| augusto-moura wrote:
| There are still a bunch of young ones on PCs because of gaming,
| unfortunately the gaming scene is chiefly on Windows. Proton
| and Steam Deck were improvements, but the market share is still
| heavily leaning towards Microsoft.
|
| Maybe if things get better we could see a steadily increase in
| Linux users, as we are already seeing
| Piraty wrote:
| Debian doesn't do a good job in making life easier for its
| maintainers.
| https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
| imtringued wrote:
| I made my own custom packages for Alpine Linux and Arch Linux
| for personal use. It is so easy that I am honestly I'm not
| seeing the point in doing things the way Debian does it. It
| just makes things unnecessarily difficult for no reason.
|
| What does a maintainer realistically do?
|
| He builds the software, so you expect that the package builder
| automatically installs the development dependencies and runs
| the build software inside a chroot.
|
| In case the software requires modifications, there needs to be
| a way to deliver patch files or additional files that aren't
| part of the original software or at least a standard location
| to store the distro specific fork that everyone agrees on.
|
| Once the software is built, the maintainer creates a directory
| structure that conforms to the distributions's conventions,
| adds things like systemd unit files or desktop shortcuts and
| other distro specific changes that exist outside the software.
|
| I would encourage everyone to at least give Alpine or Arch
| Linux packaging a try. It really is quite easy. Almost as easy
| as writing a docker file.
| sangnoir wrote:
| > What does a maintainer realistically do?
|
| Debian maintainers have to coax upstream packages to behave
| like other Debian packages and use supported linked
| dependencies. This covers everything from log and config file
| locations, startup scripts patching dependencies to match the
| versions supported by the release, backporting security
| updates, and documenting.
|
| I trust Debian (and in turn Debian maintainers) more than I
| trust the upstream developer of lib-random-4-dev. I only ever
| had to build a custom package from source a handful of times.
| Piraty wrote:
| I agree and add Void Linux to the list in the same vein.
|
| Generalley, ports-like package repos (all package build
| recipes in one repo) are really beneficial for large-scale
| operations or simply rollbacks. Being able to bootstrap the
| distro from a git repo and a well-defined set of bootstrap
| tools is really nice. try that with debian.
|
| See Void Linux and Alpine for a simple, yet refreshing
| aproach to distro package maintenance, with low overhead.
| bityard wrote:
| I can't find it now, but I read something just a few days ago
| saying that some prominent Debian members very much want to see
| the development/maintainership experience of the OS modernized
| and improved. They are suggesting (but not demanding) that
| packages be maintained by teams rather than individuals, manage
| source packages on Debian's own Gitlab instance, accept issues
| and PRs via Gitlab, better CI and testing infrastructure for
| packages, and so on.
|
| I respect the fact that current Debian development practices
| have carried the OS this far, but lowering the barrier to entry
| for volunteers to help maintain the OS going forward could only
| be a good thing.
| JonChesterfield wrote:
| Lowering the bar to entry in software can absolutely be a bad
| thing in a wide range of ways.
|
| The most obvious in the current context is possibly well
| intentioned amateurs proposing LLM generated patches for the
| usual developers to fritter away their time on until patience
| runs out.
| binary132 wrote:
| open source ain't what it used to be
| myprotegeai wrote:
| It's only going to get worse. There's a storm coming. The
| ageing open source engineers who hold up the whole house of
| cards cannot keep going indefinitely. It's going to turn into
| tragedy of the commons very quickly.
| zokier wrote:
| From my point of view it doesn't seem like really appreciate the
| Debian-style integrated self-contained OS model; what people want
| (these days) is more just a platform to run 3rd party
| applications. It is easy to see why some people see Debian more
| just getting in the way rather than being an asset.
|
| Part of the problem might be that Debian is something for
| everyone, and has cast a very wide net in terms of packages.
| Especially not all packages are all that integrated to the whole,
| or follow Debian guidelines very closely. I don't know if it
| would help if Debian would tighten ship, raise the bar for
| packages and cull more aggressively some of the less maintained
| ones. Although on the flip side one of the big advantages of
| Debian is its vast package archives so its a balancing act.
|
| Regarding the language aspect, that is the focus for much of the
| article, while I think local communities working in their native
| languages is definitely good thing ultimately I believe that any
| potential Debian contributor needs to be somewhat fluent in
| English. Debian is communal project after all and I imagine all
| the official discussions happen in English; its difficult to see
| someone being effective contributor if they can not communicate
| comfortably in community.
| Barrin92 wrote:
| > IRC is the default chat mechanism for Debian, but younger
| people do not use IRC; in Brazil, they use Telegram instead.
|
| This is I think one of the major reasons why a lot of older open
| source projects are absolutely starved for developers in their
| 20s and 30s. A lot of the mail based workflows or IRC based
| communication is just utterly foreign to any young person and
| also objectively atrocious in many ways. Having to rely on a chat
| service that doesn't let you see offline messages without setting
| up a proxy in 2024 is just not comprehensible to anyone used to
| modern services, for good reason.
|
| It's very obvious that open source projects that embrace github,
| discord, social media are able to do much better and attract
| contributors much more effectively. Purism is nice and all but if
| most of your core maintainers are in their 50s and 60s which is a
| reality now for a lot of long lived projects with no replacement
| coming up you're looking at the whole thing dying in a
| generation.
| davisr wrote:
| You've outed yourself as not knowing _why_ IRC and email are
| the established media. IRC is meant to be live chat rooms --
| and explicitly not persistent conversation. That is the whole
| point. For persistence, use email. These are the only two
| protocols required to cover most all needs of communication. It
| 's the simplicity and stability that is why they are preferred,
| and their usage translates to higher quality development --
| much higher quality than is usually ever found on GitHub or
| Discord.
|
| Also, putting the keys to one's communication into proprietary
| platforms, like GitHub and Discord, is a horrifyingly bad idea.
| Maybe it helps graduates of computer science work _faster_ ,
| but graduates of computer science also are (usually)
| embarrassingly bad hacks at what they do.
| duskwuff wrote:
| > IRC is meant to be live chat rooms -- and explicitly not
| persistent conversation. That is the whole point. For
| persistence, use email.
|
| Is there a compelling reason for those to be separate, beyond
| "we've always done it this way"?
| davisr wrote:
| Yes, because the live chat that happens on IRC is meant to
| be ephemeral. It's a place where you go to hang out with
| people, shoot the shit, or ask off-the-cuff things. Most
| IRC moderators have a no-logging policy because it's
| supposed to be a shared space that people "move into and
| out of".
|
| Email is where official business happens. That's where
| debug logs are pasted, and people can reply on a point-by-
| point basis, with quotes, references, and attachments. It's
| meant to be high quality/detail and searchable. That's why
| mailing lists have archives.
|
| When IRC and email aren't separate, you get Slack and
| Discord -- places that don't do either off-the-cuff chat,
| or searchable documentation, particularly well.
| hinkley wrote:
| Every volunteer group eventually starts to look alike.
|
| This is as it was explained to me over a decade ago, and I don't
| really need to change much since human nature doesn't change very
| fast, and this holds for all the groups I've belonged to.
|
| You get a lot of young adults who have more time than money.
| Their contributions are energetic but often short lived. They
| move away, their sense of self shifts away from the cause, their
| lives get too complicated, or they overdo it. It's the people who
| pace themselves that avoid burnout. The trap is caring so much
| about a cause that they hurt themselves and have to step back.
| You get a smaller number of generally older regulars who keep the
| wheels on, and you have a few old timers who remember all the way
| back to the beginning. What has been tried. Who we have
| collaborated with or gotten donations from in the past.
|
| So attract your volunteers, identify and groom some for small
| leadership roles. But make sure not to overload them, and
| encourage them to set healthy boundaries. It's keeping them that
| kills many orgs. Though some only focus on retention and become
| an echo chamber of greybeards. I don't believe Linux has that
| problem. Yet.
| meisel wrote:
| Moving Linux and its associated projects to GitHub would
| definitely help. I don't buy the arguments that GitHub isn't
| suitable for it, e.g. because it doesn't allow each sub-project
| to have its own area. Things like tags help a lot to separate
| issues and PRs based on which sub-project they're a part of.
| JonChesterfield wrote:
| Totally. Microsoft is a surely benevolent entity to host the
| Linux project. They've proven to be excellent stewards of open
| source in their copilot project.
| never_inline wrote:
| One reason I see hardly mentioned is change of tech stacks.
|
| Most modern developers do web development with a highly
| abstracted stack (including yours truly).
|
| So nobody is much familiar with C / Perl / OS level APIs. Closest
| they get is adhoc shell scripting in form of devops tools.
|
| Since people are so much abstracted from the stack, they don't
| feel much need to contribute to it or improve it to scratch their
| own itch.
|
| That's why new stuff like CNCF gets many contributions, old ones
| like Debian don't.
| jauntywundrkind wrote:
| I'm very conflicted, because Debian's strength is the intensity
| of package maintainership, but it's weakness is the intensity of
| package maintainership. Debian has a strong focus on being a in-
| group culture, believes in maintainers as strong operators over
| their fiefs, with freedom to operate in manners they like,
| usually with little support or help.
|
| There's been suggestions - ideas that maybe Debian should be a
| little more open to outside contributors, should have ci/CD tools
| & accept PRs more publicly. https://salsa.debian.org/dep-
| team/deps/-/merge_requests/8
|
| I do think there would be a lot of help that would show up, a lot
| of drive by contributions. And some people actively converting to
| maintainership that wouldn't have. But at the risk of a lot of
| people being able to help, without acculturating onto Debian,
| contributing more without becoming a full maintained.
|
| My only real Debian developership attempt was a go at packaging
| wayvnc a long time ago, and it's deps, well before it was
| available. Seems fairly straightforward, but I felt very
| unwelcome when I tried to ask about finding a maintainer or
| getting mentorship; it was a long time ago so I don't fully
| remember, but it was pretty discouraging and experience having
| re-learned so much about Debian & having some the deeds, only to
| feel turned away for unclear reasons.
| Tarucho wrote:
| The problem with these large open source projects is that they
| are already on maintenance mode and the fun part has already been
| done a long ago. Who wants to work for months doing menial tasks
| so that when they "graduate" they can start doing maintenance.
| recursivecaveat wrote:
| Truly. God bless the maintainers and we couldn't do it without
| them, but I cannot imagine myself sitting down on the weekend
| to do maintenance on a 20yo disk partition utility or
| something.
| Quekid5 wrote:
| I'm not qualified to comment on the larger Debian ecosystem, but
| having been forced (due to work) to create some Debian
| packages... the tooling is awful. Packages are two(?) layers of
| tarballs, there's the option of free-form shell scripts in there
| to do _whatever_ as a pre /post-install step, etc. etc. There's
| even several ways to try to hide some of that awfulness under the
| carpet, and yet it's still there.
|
| If they want to attract people who care in the least about
| developer experience they'll need to consolidate and fix their
| package system and tooling.
| ThinkBeat wrote:
| I think having high-quality documentation in one language would
| be a huge win. That is lots of effort can be spent improving,
| expanding, and editing existing documentation. English is a
| prerequisite for the wider Debian community, and it is the most
| widely spoken language in the world says Wikipedia1
|
| English 1.5 billion Mandarin. 1.1 billion Hindi 0.7 billion
| Spanish. 0.6 billion
|
| I wonder how real that number is for English. In a lot of
| nations, people are taught English in school officially, and it
| is true but with very poor results. (I was taught French in
| school and that had catastrophically bad results)
|
| When it comes to Mandarin Chinese, I wonder if the wider
| community has better mastery of it compared to English or if its
| the same or if it is much worse.
|
| When it comes to the tools used for communication, having a
| strong standard is again beneficial. What every 10 years? Every 5
| years? There is a new and hip platform that "everyone" uses.
|
| If you can't expect younger people joining to adapt some to the
| wider community, then you will need a lot of difficulty to handle
| bridges that will cause all manner of problems.
|
| Or should "adult" community members have to adopt whatever
| "everyone" is using every 5 years?
|
| IRC has all sorts of different clients, in all sorts of different
| platforms.
|
| Becoming a developer or maintainer for Debian will involve
| learning to use a lot of different tools that are needed to
| perform the tasks involved. Surely most of those tools don't
| change around every year?
|
| 1 https://en.wikipedia.org/wiki/List_of_languages_by_total_num...
___________________________________________________________________
(page generated 2024-09-24 23:00 UTC)