A few weeks back, I was at XDC and gave a talk about various current and past input stack developments (well, a subset thereof anyway). One of the slides pointed out libinput's bus factor and I'll use this blog to make this a bit more widely known.
If you don't know what the bus factor is, Wikipedia defines it as:
The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.libinput has a bus factor of 1.
Let's arbitrarily pick the 1.9.0 release (roughly 2 years ago) and look at the numbers: of the ~1200 commits since 1.9.0, just under 990 were done by me. In those 2 years we had 76 contributors in total, but only 24 of which have more than one commit and only 6 contributors have more than 5 commits. The numbers don't really change much even if we go all the way back to 1.0.0 in 2015. These numbers do not include the non-development work: release maintenance for new releases and point releases, reviewing CI failures [1], writing documentation (including the stuff on this blog), testing and bug triage. Right now, this is effectively all done by one person.
This is... less than ideal. At this point libinput is more-or-less the only input stack we have [2] and all major distributions rely on it. It drives mice, touchpads, tablets, keyboards, touchscreens, trackballs, etc. so basically everything except joysticks.
Anyway, I'm largely writing this blog post in the hope that someone gets motivated enough to dive into this. Right now, if you get 50 patches into libinput you get the coveted second-from-the-top spot, with all the fame and fortune that entails (i.e. little to none, but hey, underdogs are big in popular culture). Short of that, any help with building an actual community would be appreciated too.
Either way, lest it be said that no-one saw it coming, let's ring the alarm bells now before it's too late. Ding ding!
[1] Only as of a few days ago can we run the test suite as part of the CI infrastructure, thanks to Benjamin Tissoires. Previously it was run on my laptop and virtually nowhere else.
[2] fyi, xf86-input-evdev: 5 patches in the same timeframe, xf86-input-synaptics: 6 patches (but only 3 actual changes) so let's not pretend those drivers are well-maintained.
I never even thought about this!! I would love to help, except my skills are in python + statistics. I imagine your code is C.
ReplyDeleteWhere would one start, if they were motivated.
I'd love to help out, but I'm a beginner in C and am in the middle of my Undergraduate studies in CS. If there's any way I can get started on helping, I'd love to know (hexagon@iastate.edu)
ReplyDeleteI am interested as well
ReplyDeletePlease add link to libinput source and version control repo
ReplyDeletehttps://gitlab.freedesktop.org/libinput/libinput
Deletegit@gitlab.freedesktop.org:libinput/libinput.git
https://gitlab.freedesktop.org/libinput/libinput.git
Probably the best way to start is to go to the list of open issues at https://gitlab.freedesktop.org/libinput/libinput/issues and pick one that sounds interesting. Doubly so for anything marked with "help needed" because those are the ones I won't be able to implement myself (time or hw requirements, but usually the former).
ReplyDeleteYour backlog seems to be much better than all commercial projects I worked on! Big congrats!
ReplyDelete@Peter
ReplyDeleteThree years ago, I posted a bounty for a feature request in my Dell XPS 13 touch pad.(https://www.bountysource.com/issues/38423871-support-three-finger-drag).
Compared to your IT job's salary, I knew my $10 buck contribution is a peanut.
However, if you could figure out how to make the bounty/donation grows like a snowball in social media to reach out more people, I bet your project will definitely attracts more attention.
Let say your want to prioritize adding or fixing issues in your project, how about you sort it out by the bounty? I knew vim.org has done this things for years.
The motivation of human being are driven by incentives. Instead of crying help for more volunteers, how about changing your strategy first?
Just my 2 cents.
You could consider proposing projects on outreachy or communitybridge. These are nice places to get new contributors involved.
ReplyDelete@Ricky Zhang - The entire premise of Linux is that community cooperation can produce astounding things without financial motivation. Sometimes people just want to do good.
ReplyDeleteThat said, the mega-corps have turned Linux into a multi-billion dollar industry and are exploiting all of that free labor to further enrich their shareholders.
Sometimes I think that the FOSS guys should all go on strike until the Googles, Apples, and IBM's of the world decide to start contributing back in a more meaningful way.
@Jian Yang
ReplyDeleteExploiting free labor? Well, you must be sent from a different planet.
Let me tell you some facts:
1. Everyone in IT are well paid everywhere on the planet earth.
2. Majority of PR sent to open source projects are funded by the employees working in big corporations. Check out lwn.net (https://lwn.net/Articles/798505/).
I don't see where you hateful message comes from. After all, we all need to pay our bills.
Here is the reality we face: there is not enough traction from open source community to join this project. I propose my solution using bounty to add new features, fix bugs and attract attention. You propose to go on strike.
Which way is more meaningful?
Am a software developer and would like to contribute. Have gone through the list of open issues too. Is there anyway to communicate with you? Have sent a LinkedIn request to connect too, but I guess you ain't active there.
ReplyDeleteThanks