MocLG/rtw88-rtl8723bs

I looked at MocLG/rtw88-rtl8723bs as a focused hardware enablement project, and the strongest thing about it is that it is solving a real, narrow Linux driver pain point rather than trying to be a generic Realtek dump. The README makes the goal clear: bring RTL8723B/RTL8723BS support into a cleaner rtw88/mac80211-style driver path, with SDIO RTL8723BS as the active development target. That matters because the existing RTL8723BS story on Linux has historically involved staging or vendor drivers, and this repo is explicitly trying to move that work toward something more upstream-shaped.

The project shows serious hands-on debugging work. The tree includes the modern rtw88 driver files, RTL8723BS-specific entry code in rtw8723bs.c, firmware assets, DKMS support, and reference vendor/staging trees for comparison. I especially liked the diagnose.sh approach: it builds and loads the local modules, captures module provenance, runs scan and WPA tests, compares against the vendor driver, and packages logs into a diagnostic tarball. That is exactly the kind of workflow a hardware-driver project needs when the maintainer may not have every device locally. The open MEDION Akoya testing issue also shows useful maintainer/tester collaboration, with logs driving concrete changes around SDIO TX/free-page behavior.

The main adoption gap is that the documented install path is DKMS, but there is already an open issue about rtw_8723bs not being built/installed by DKMS, and the current dkms.conf still appears to list SDIO companion modules without listing rtw_8723bs itself. Since RTL8723BS is the headline target, that mismatch is worth fixing or documenting very prominently. I would also make the project status more explicit near the top of the README: scans/authentication are still under active debugging, DKMS may not be the recommended development path yet, and testers should expect instability. The Arch forum thread and GitHub issues communicate that, but new users landing on the repo may see “Installation Using DKMS” before they understand the current maturity level.

A few community/maintenance additions would make the project easier to trust: add GitHub Actions that at least compile against one or more kernel header versions, publish known-good kernel/hardware combinations, and add a short CONTRIBUTING.md focused on how to provide logs, test patches, and avoid unsafe module-loading mistakes. Releases would also help, even if they are marked experimental, because driver users need a known snapshot more than they need whatever main happens to contain that day. Overall, this is a small but valuable project with a clear technical purpose, active maintenance, and unusually practical diagnostics; tightening the DKMS story and status documentation would make it much easier for the right testers to adopt safely.