FreeBSD Focus 2024: Recruitment

Prolog

For years I've advocated that the FreeBSD Core team should write down a roadmap for the project for the benefit of elements of the community. People get hung up on the word roadmap, and that this is a volunteer effort. This document represents my response to that. It's also, sadly, a bit src focused in what it proposes, though many of the ideas can generalize across the project (and a real work product from core would have that balance)

Main Theme

This year's main theme is recruitment. The project's aging developer demographic strongly suggests that we need to focus on bringing new people into the project. Recruitment drives three areas of change: Technical, Management and Social.

Technical

FreeBSD is behind in a number of areas that's visibily hampering new people trying it out. While the project shines brightest in VMs, cloud, jails, storage and networking, there are a few areas that represent a barrier to entry to using the project as your daily driver.

Wireless

Our wireless stack is woefully out of date and needs a major update. Younger people need wireless that just works, or they will move on to something that has wireless that's working. There's two main areas the project is behind: Fully integrated drivers that support any connectivity with chipsets that are in popular laptops. If you can't pass packets to your system, you can't get anything done. It needn't be the fastest, best access either. The second area is advanced WiFi features from newer standards. This area primarily limits the speed one may connect at and the performance one may expect. But in some cases, lack of support for newer crypto can keep the device off the network entirely. Efforts should be made at addressing these issues. In addition, some quality of implementation issues need to be addressed, like easier loading of firmware and better suspend / resume support for the wireless cards.

Desktop / Graphics

While the project has made great strides in this area in the past few years, we still have not completely caught up with the latest hardware. Continued effort is needed here to support the latest LTS branch of Linux, and to find ways to make porting to newer versions faster and easier. If people can't use their laptop to do useful work becaue graphics support is too far behind, they'll go somewhere else.

Old Versions of New Technology

This is a general catch all for technology we do have drivers and stacks for, but that needs to be updated to support newer (not even the latest) standards. Our Bluetooth stack is a bit out of date with respect to the underlying technology, and woefully inadequate to easily pair devices. While it's possible to pair a keyboard and mouse, more advanced devices like headphones remain elusive. The SD card stack does a great job of supporting even newer SD cards, but the SDIO portion of the stack is somewhat lacking and drivers hanging off of that are behind even the other BSDs. This makes it harder to do cool things with the wireless card that's built into most SOCs. While these issues deter fewer people than the first two, they do contribute to people losing interest when they can't listen to music streamed from their laptop, or put that latest board on the wireless networks.

Management

The project has never been good at management. In former times, we were able to adapt to the lack by a combination of there being a surplus of people wanting to contribute and a good match between developers and users. These days, there are fewer people wanting to contribute, so decades long problems that make it hard to contribute are weighing us down. In addition, the gulf between users and developers has grown larger (more about that in the Social section). This means we've been bad at proactively recruiting prolific contributors. We've been bad at accepting patches. And the mentoring needs of the contributors we do get has shifted from a few, short term tips on what's expected of you from the larger project to needing more nurturing to help them mature as developers. Despite all these things, we're still an easier project to contribute to than many larger ones, though if we address the fundamental things that turn off new people and shut down their enthusiasm, the project will be better for it..

Accepting Changes

The project has for decades let patches languish in various places: gnats, bugzilla, phabricator and (until recently) github pull requests. We've been terrible at providing feedback, especially when that feedback has been 'no' or otherwise negtive. This is because we've never had anybody or group whose job it's been to act as oversight for even the promising patches, so users that submit chanages get met with indifference, poor feedback, or worse: approval of the patches, only to drop them on the floor.

Outward: Need to constrain where we get patches

We need to constrain the number of places we recommend new committers go to contribute. My recommendation would be to change all our documentation to funnel them to github. Of all the tools we use, it's the friendliest to newbees:

1. Most people have github accounts, or are willing to create them.
2. The tool offers the best filtering facilities of the lot to allow them to be managed and yes/no answers to be generated.
3. The tool has the best exensibility of experience so things like commit checklists, automated greetings and categorization can be made, etc. This makes requests that have passed initial tests more rewarding to process.
4. The code review tool is adequate for most pull requests.
5. Automating integration of the pull requests into FreeBSD is relatively straight forward.
6. Since it uses git, we can ask contributors to do most of the work to make it ready for the tree, easing the burden on volunteers landing them.
7. Provide a fast turn around to feedback, both automated and human-generated. This keeps the contributor engaged and enthusiastic about the project and the possibility of making future commits.

While the project can still accept patches via bugzilla, it would be better to split the description of the problem to a bugzilla bug, and then to have any patch as a pull request (with mutual cross references). This is a little tedious, and long term we need a more integrated solution or forge. In the short term, though, it leverages the tools we have without a lot of heavy lifting.

Inward: We need better automation

The project needs batter automation. With it, we can

1. more easily provide a good experience to contirbutors.
2. test contributions to a higher level with less effort.
3. focus on the change, not on the mechanics.
4. harness the larger pool of talent that's out that who don't have a commit bit, but can contribute.
5. give us the data we need to know who to proactively recruit for the project.

Mentoring and Recruiting

These go hand in hand, so I'll address them together. We need to find some way to have a ready pool of mentors for new contributors. Relying on good working relationships to just spring up and for people to be "punished" with a commit bit makes for good cultural lore, but bad policy. We need to be more intentional at all levels. From starting a lurker program for core and the new srcmgr, to maintaining lists of mentors, to having a single point of contact for new contributors to report breakdowns to (so one person disappearing doesn't bring down several new people's efforts), to proactively seeking out people that send in lots of good changes, the project needs to adjust its ways of doing business to bring in more people, nurture them, and grow them into members of the developer comminity that can both contribute technology to the tree, as well as wisdom to future newbies. These efforts don't happen on their own, and the project could use people with the skills to organize and manage the resulting chaos.

Developer Tools

There's nothing wrong with developer tools. Phabricator is a decent review tool and works best in the hands of a developer because they can drive the change start to finish. We'll continue to need them, at least in the short term.

Longer term, though, we need more integrated tools.

Bug Busting Has Two Sides

We've done a good job on only one of the sides of bug busting. We have good triage that gets us curated lists of bugs that are decent. However, the other side, the fixing, we've been hit or miss. Especially where patches are concerned (which is why I recommended above we focus on github for patches and split the 'this is a bug' off from the 'this is a fix').

Social

In the early days of the project, we all got together on Usenet or on mailing lists (often both). Developers and users were in social and technical forums side by side, and it was relatively easy to connect the two. However, over time, the developers have largely moved to only mailing lists on a few online irc channels that are developers only. The users have migrated to forums, twitter, mastadon, discord and other soical media that developers have largely shunned. The project has had a hit or miss track record here, in part due to the disconnect. The project proscribed methods to submit patches to developers that were then largely ignored, also fueling the golf.

The project needs to update its patch intake to be more social, and update its documentation to be clear the best way for the average user to contribute, rather than focusing on the special case of the developer, or relying on methods that have proven to be ineffective at driving change.

In addition, we need to start looking at other ways to connect users with developers. Our project generally is more approachable than some others in this respect. We could do better. New people that are just starting out and trying to find some way to contribute often get a huge bump in their enthusiasm when they can get the focused attention of a developer for a little while to point them in the right direction. This must be weighed, though, against the limited time developers often have for the project. More connections need to be made, but they need to be thoughtful ones.

Conclusions

By focusing on things that will help recruiting, we can bring more people to the project that can contribute to making the project better. Making the right efforts, and fixing the major sources of frustration can have big payoffs. Not everybody that starts to contribute will continue. Not everyone that contributes will be great. However, the little contributions will add up, generate good will and help people feel more connected. In some cases, it will become habitual and project will grow. We should focus on fixing the technological stubling blocks to adoption, plus focus on accepting (or rejecting quickly) contributions to help grow the developer pool. Together, these things will bring benefits to the project.