Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

'It's hard to find maintainers': Linus Torvalds ponders Linux's future

theregister.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#41

Post by u801e »

kstenerud wrote: post #12
finnthehuman wrote: post #9

Earlier quoted context omitted.

I'm often confused as to how many people really have a potential future where they become motivated long term participants, but a few bumpy roads at the onset turn them off. And I don't just mean in kernel development, learning the guitar isn't fun either. Who gets into software as a profession, and then lets a bad UI turn them away from a project? When so much of the valuable skillset in programming is understanding…

If there were a better way to learn guitar, everyone would jump on it. Software doesn't have to be so difficult and tedious to use, as has been demonstrated by a decade of u/x in the UI space. Nowadays, nobody would ever consider gordian knot for their video editing, and I don't blame them. This idea that one must suffer to learn is as outmoded as alchemy. You don't need to take the good with the bad; learn from the…

> If there were a better way to learn guitar, everyone would jump on it.

This type of assertion is made in a lot of contexts, but I don't believe it holds true. I believe that there are a subset of people who are willing to learn a new skill. Of those people, there are very few who are willing to learn a new skill but won't because of some perceived barrier to learning it. The vast majority of that subset will learn the new skill despite the perceived barrier.

Of the people who aren't in the set of people who are willing to learn a new skill, there will be very few people who will be movitated to learn the new skill because the perceived barrier to learning it has changed in some way.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#42

Post by nujabe »

aboringusername wrote: post #3

For me, this is one of the most interesting aspects to the development of Linux, and one I've been studying for years at various levels. Even though I don't understand a lick of most of the code, watching the lkml and the process itself is very quite interesting, however, there are a few ways to try and put the kernel in a better position in the future. Each major release can be considered a "story", for example, the…

These are some very good suggestions. I think they should take note on how the Kubernetes project operates, with the various interest groups, Slack channels, meeting notes + their recordings on Youtube. I think those channels catch a large part of the history of the development. I'm not sure if Linux uses anything beyond mailing lists.....

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#43

Post by RMPR »

franga2000 wrote: post #35
ssivark wrote: post #26

Earlier quoted context omitted.

In this context it’s wise to move conservatively. Gitlab has “come of age” only in the last few years. We see that KDE is now moving. If that works well, I wouldn’t be surprised if other OSS projects slowly start migrating. Remember that there is heavy organizational inertia and culture on the LKML. Moving to Gitlab is practically akin to gutting that and beginning a fresh project with forked code — the kind of cultu…

I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it. The problem is cultural, as well as organizational. Firstly, I doubt any of the current maintainers would be willing to do that, especially without Lin…

> I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it.

FWIW that's already happening with the BPF subsystem https://github.com/libbpf/libbpf

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#45

Post by rgfvdcxz »

ritwikgupta wrote: post #33
aboringusername wrote: post #3

For me, this is one of the most interesting aspects to the development of Linux, and one I've been studying for years at various levels. Even though I don't understand a lick of most of the code, watching the lkml and the process itself is very quite interesting, however, there are a few ways to try and put the kernel in a better position in the future. Each major release can be considered a "story", for example, the…

I think the heart of what you're getting at lays in the world of ethnographies. Perhaps a cultural anthropologist would take a hand at documenting the process of developing for the Linux kernel, its rich history, and all the minutiae that go into it.

Read up on the field on Science and Technology Studies (STS). STS researchers do this kind of work all the time, since the 1970s.

More specifically, check out the work of Matt Ratto, who defended his 2003 dissertation on this exact topic: https://bit.ly/2YQL1yf

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#47

Post by asfarley »

This kind of reminds me of a similar article I saw, saying that Ruby needed maintainers/contributors.

I contacted the Ruby development team, and was told: "find something to improve, maybe do an optimization" with no further guidance. So, I moved on to other things.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#48

Post by effie »

icelancer wrote: post #31
effie wrote: post #29

Earlier quoted context omitted.

Modern does not mean better. Email-based collaboration is most welcoming to new people and good enough for the regular participants. I for one do not want to create an account and learn how some slow web application works for each project when I can do with sending an email.

>> Email-based collaboration is most welcoming to new people What? Aren't new collaborators way more likely to be younger and acquainted with Web-based tools like GitHub/GitLab?

New wannabe collaborators maybe. But does the project want to attract only young people who don't care about corporate control creep over free software? Or does it want to attract all able young people including those who understand the benefits of the email based collaboration, which is being the only convenient, decentralized, non-corporate-controlled and the most equitable way for strangers to communicate over the Internet?
Post reply on HN