A “Linux Embedded Development Environment” (LEDE) fork of the lightweight, router-oriented OpenWrt Linux distribution vows greater transparency and inclusiveness.
Some core developers of the OpenWrt community have forked off the project into a Linux Embedded Development Environment (LEDE) group. LEDE is billed as both a “reboot” and “spinoff” of the lightweight, router-focused distribution, with the objective of building an open source embedded Linux distro that “makes it easy for developers, system administrators or other Linux enthusiasts to build and customize software for embedded devices, especially wireless routers.”
The announcement, signed by Jo-Philipp Wich and six other former OpenWrt core members, claims that LEDE represents a “significant share of the most active members of the OpenWrt community.” The group promises an organization with a stronger focus on transparency, collaboration, and decentralization.
As with the recent LibreELEC fork of the Kodi-focused OpenELEC media player project, differences seem to be primarily about governance rather than technology. Here again, lack of transparency and inclusiveness lead the list of complaints. Yet there are no promises regarding compatibility, so a greater technological reboot may be also be in the works.
Arduino Yún Mini
The rift has appeared as OpenWrt is expanding beyond being a firmware replacement for routers and NAS devices to acting as a broader platform for mostly MIPS-based SBCs and gizmos aimed at Internet of Things applications. It also comes amidst increasing complaints about the lack of security and automated updates on Linux-based routers, as well as attempts by the FCC to block hackers from loading open source firmware on routers.
The LEDE announcement alleges that the OpenWrt project has done little to reach out to new members. The number of active core developers is said to be at an all-time low, and there are not enough developers with commit access to handle incoming patches, testing, and builds.
The LEDE organizers go on to cite a lack of communication, transparency, and coordination, both within the core team and with the community. They claim that the basic infrastructure is unreliable, and that bug fixes have been “prevented by internal disagreements and single points of failure.” The group also criticizes the lack of focus on stability and documentation.
LEDE goals include a greater focus on stability and functionality, and implementing “regular, predictable release cycles coupled with community provided device testing feedback.” Decision processes will be transparent, “with broad community participation and public meetings,” says the group.
Specific changes that the LEDE project says differentiate it from OpenWrt include:
- All our communication channels are public, some read-only to non-members to maintain a good signal-to-noise ratio.
- Our decision making process is more open, with an approximate 50/50 mix of developers and power users with voting rights.
- Our infrastructure is simplified a lot, to ensure that it creates less maintenance work for us.
- We have made our merge policy more liberal, based on our experience with the OpenWrt package github feed.
- We have a strong focus on automated testing combined with a simplified release process.
The OpenWrt project responded to the announcement with “a great amount of surprise.” The response disagrees with the main points of LEDE’s announcement, but concedes that it contains “a number of very valid points which we hoped we had an opportunity to discuss and attempt to fix, in a public manner.”
The OpenWrt project says it is actively working on some of the issues, such as decentralizing infrastructure. The response encouraged LEDE members to come back into the fold, to work things out.
A sampling of the comments from the OpenWrt community on various forum pages such as the OpentWrt response and this LWN.net announcement suggests there are indeed some major problems with OpenWrt. Some commenters complained about outdated listserv, patch management, and bug-tracking systems. The community website forums and wiki are also dinged for being antiquated. A story in The Register noted that an OpenWrt downtime incident earlier this year was traced to a “single, small, server without redundancy.”
Lack of delegation and sharing of tasks was another theme. One avowed LEDE supporter writes: “A critical part of many of these debates was the fact that people who were controlling critical pieces of the infrastructure flat out refused to allow other people to step up and help, even in the face of being unable to deal with important issues themselves in a timely manner.”
Some complain about the project’s attempt to support too many devices, with not enough focus on quality. Others chip at the increasing bloat in certain OpenWrt components. There were also a few critics of LEDE, with some noting that for all its talk of complacency, the LEDE group presented the fork as a fait accompli, rather than discussing it openly.
OpenWrt emerged from a stack running on the venerable Linksys WRT54G WiFi router, beloved of Linux hackers. The distribution has been widely used on router-based hacks, and was also loaded on the Linksys NSLU2 (aka “SLUG”) networked attached storage device, as well as a number of new open source routers.
In order to fit on resource-constrained hardware. OpenWrt is more limited in some ways than Debian and other platforms. However, it’s far more advanced than uClinux, which targets even lower-end hardware. More background on OpenWrt, and its emerging role in IoT devices, may be found here.
OpenWrt is increasingly expanding beyond routers, such as the new Turris Omnia, to power home automation gizmos and other, frequently MIPS-based, IoT-oriented boards and devices. Some recent examples include the Arduino Yún and Seeed’s Grove-enhanced Seeeduino Cloud and LinkIt Smart 7688 hacker boards. There’s also a Domino.IO IoT kit and Imagination’s Creator Ci40 SBC, among many others.
Recently, OpenWrt has found itself at the center of a controversy involving WiFi spectrum. The project would seem to run afoul of an FCC proposal to keep hackers from flashing new code onto router devices developed outside the U.S. that might exceed a WiFi router’s radio spectrum certification. In March, router vendor TP-Link proactively complied with the proposal by attempting to prevent users from loading OpenWrt or DD-Wrt on its routers.