It has now been a little more than a year since my first call to action on trying to improve the state of Linux touchpads. I had hoped that we would be further along at this point, but goonies never say die. This time around we're going to try some new tactics to manifest the dream driver.
In the latter half of this blog post I'll delve into why more progress hasn't been made. But people are busy, so let's start by looking at what can be done to drive progress forward from here.
In which we formulate practical next steps to deliver a Linux touchpad driver that's more like the Macbook touchpad driver.
Perhaps the biggest challenge to crafting the optimal touchpad experience is that so much comes down to a matter of taste. We can (and do!) wave our hands and say "just do what macOS does," but that's an end destination, not a first step. In order to help pick the right first steps, I've created this poll to better capture the specific shortcomings of the existing Linux touchpad drivers:
By leveraging the collective wisdom of the crowd, we can pinpoint where to get the most bang per buck on improvement efforts. Since resources figure to be limited (more on that below), it makes sense to start with what's causing people the greatest pain and work down the list. The poll confers other incremental benefits as well. More notes about the poll.
As articulated in the "What are realistic cost expectations?" section that follows, my best guesstimate is that we could make a dent in the Linux touchpad universe with $10k. Administrative overhead is $0, and it stands to reason that some developer who reads this post might be willing to take the reigns and work with me to start making things happen.
I haven't asked for cash in previous posts. But that hasn't stopped tens (hundreds?) of past commenters from offering their own money to make the Linux touchpad work more like macOS. It continues to boggle my mind how much potential energy exists for this cause, even if nobody has been able to convert the potential energy into kinetic energy so far. To create movement, we need to harness the potential energy.
Thankfully, the new GitHub Sponsors program offers a lifeline that massages away almost all the complexity of stewarding an open source project like this one. Not only that, but GitHub currently matches the first $5k of donations in a year! I don't think they get nearly as much appreciation as they deserve for this, so I'm dedicating this praise hands emoji to them: 🙌. Thanks for being more awesome than could be expected, GitHub Sponsors 💖.
This fork has yet to see meaningful work started on it for reasons that are described below. Progress can happen in a hurry once a developer is contracted to begin work on the issues that are most voted by poll respondents.
Hiring a developer who could dedicate themselves to creating a Macbook-like touchpad experience figures to be a relatively expensive proposition. In the past year, the libinput project has seen 18,000 Line Impact contributed in total, thanks almost entirely to Peter Hutterer. Think of "Line Impact" as a proxy for "cognitive load," or "Story Points" in Agile. If we could implement half a year's worth of Story Points (aka ~10k Line Impact), that could probably solve five major issues, likely closer to 10. It would probably take about 20 developer/weeks.
If we can find a reliable, contracted developer willing to work on this project for $50/hour, the goals I'm setting above pencil out to something like $40,000 to fix the top 5-10 improvement opportunities identified by poll respondents. While there is an appetite for improved Linux touchpads, it's difficult to imagine that there is $40,000 worth of appetite. However, if we can scrounge up $5k worth of donations, add in GitHub's $5k worth of matching, combined with the free QA that many seem eager to provide, that could go a long way toward fixing at least a couple of the most voted pain points.
Bottom line: if there's enough enthusiasm to generate $5k worth of donations, which becomes $10k thanks to GitHub 💖, which becomes $10k + QA help thanks to volunteers... we won't be looking backward in April 2021 at no significant progress having been made over the past year.
Are you a developer interested in working for $50/hour to improve life for a bunch of Linux touchpad users? Here are the job requirements:
Has access to a modern Linux laptop
At least a couple years experience with C/C++
Proven track record of delivering projects on schedule (please provide examples)
Strong English skills
Self-starter, able to make progress toward high level goals with minimal oversight
Positive, solution-oriented collaborator
(Preferred) Has personally struggled with Linux touchpads.
If you have these qualities, please email me bill -at- gitclear.com, with a cover letter and your LinkedIn (or resume if you don't have LI). Please indicate in the cover letter whether you've been able to get the libinput project building in your dev environment (how long did it take?). Applicable insight: I'll use the cover letter to gauge project enthusiasm, communication ability, and collaborative spirit. When it comes to cover letters, my order of preference is "appropriately concise" > "too long" > "too short."
When I published my first Linux touchpad blog in 2018, my goal was to stir up enough passion to ensnare a couple developers with spare time to make improvements to libinput. I went one for two. My attempt to frame the Linux touchpad problem stirred up enough passion that ultimately about 5 developers emailed with interest in helping. To these respondents I requested that they could get their dev environment setup to build our libinput fork and report back to me. Building the project seemed like as good a starting point as any, but I went 0 for 5 in hearing back from the volunteers. From having run my share of volunteer coding projects, this is consistent with past results.
The bigger problem than volunteer follow-through was me. Interesting tasks at my day job sapped attention from the side project. The problem isn't quite as pressing to me as it was when I had to suffer through it regularly. I could make plenty of more interesting excuses but the bottom line is that anyone who has tried to stick to a big project over years probably sees peaks and valleys of progress. Sticking with it through the valleys and not giving up is an important component to succeeding in the long term.
Here is the timeline I'm targeting:
Now: Add the gitclear/libinput project to Open Repos to improve the transparency of progress
Every few weeks, from now through June: Post an update about project funding status (dunno yet if GitHub or blog will be the home of that)
June: Post the preliminary results of the poll
~Summer: Have a developer contracted to work on the project
Fall: Get a first PR approved by Peter
That's what I'm hoping for anyway, if people remain interested in this esoteric cause. It's edifying to see so much support toward a greater public good. Ensuring that mobile Linux remains a viable alternative to macOS helps keep Apple on their toes.
Odds and ends.
Does anyone need a better survey gem for Rails? I've been mulling whether to open source the survey code we wrote to run GitClear/Bonanza surveys. It implements the superset of features we've needed for surveys over the years, which is quite a few more than the current top Google result for "rails survey gem." Drop a line in the comments if this is a gem that would benefit you.