[LEDE-DEV] openwrt and lede - remerge proposal

[Edwin van Drunen]

>> I'm pretty sure the ship has sailed on that approach

That would be too bad.
It seems to me that the vote was held amongst a small group of heavily biased people, of which a part was responsible for the split between OpenWRT and LEDE in the first place.
I am very sure if you would poll the large OpenWRT/LEDE user base the results of such a vote would be quite different, but these people never get asked anything

I also get the feeling more and more that the split was perfectly justified, probably there’s a bit too much ego involved.
What is the use of a project in the Public interest, when the targeted audience is not involved in the process?
This is exactly where the LEDE project did better than OpenWRT.

With kind regards,
Edwin van Drunen

> On 12 May 2017, at 13:09, David Lang <david at lang.hm> wrote:
> 
> On Fri, 12 May 2017, Daniel Golle wrote:
> 
>> Hi Edwin,
>> 
>> On Fri, May 12, 2017 at 10:02:36AM +0200, Edwin van Drunen wrote:
>>> As a long time user of OpenWRT and recent “LEDE convert” I would also like to chime in on the naming and branding of the post-merge project.
>>> My employer and several of my industrial clients have used OpenWRT/LEDE extensively over the past few years in many projects, ranging from routers and access points to embedded servers and industrial controllers.
>>> It was the small footprint combined with the versatility of the platform that made it work and the availability of generic pre-built images for many platforms and documentation that made it a success.
>>> But despite the great track record of the system, there was always a bit of a “hobbyist” feel that the OpenWRT name brought with it and a sense of unprofessionalism being perceived by management and some end users.
>>> Most likely this is because the name OpenWRT is strongly related to “hacking" consumer routers (WRT54GL etc.) and the 90’s style website also didn’t help.
>>> When LEDE was forked and presented as a more multi-purpose embedded linux, came with new releases quickly and with a more modern website and interface to code and documentation, the switch was easily made.
>>> Not having WRT in the name, implying it would be for wireless routers, but instead using the broad term “development environment” was helping to better describe what the platform is and give it a more professional sound.
>>> With the new name the platform was now seen as a professional piece of infrastructure.
>> 
>> This quite matches the experience I've made when presenting the LEDE
>> fork...
>> 
>>> In my opinion LEDE perfectly describes the combination of OpenWRT’s version of the buildroot system, the set of patches and the Luci interface:
>>> The entire development environment that is needed to build a generic bootable image and software packages from source for almost any platform, with matching pre-built SDK’s and image builders.
>>> OpenWRT better describes the wide range of specific system images built for COTS products (which are mostly wireless routers) and is a more suitable name for a final “product".
>>> You should consider maintaining the LEDE name or somehow differentiatie between the “development environment” and the "final product".
>> 
>> I strongly agree here as well, I believe the "LEDE" project could
>> release an "OpenWrt" product in reasonable time intervals and that
>> should be targetting home routers and similar embedded systems.
> 
> I'm pretty sure the ship has sailed on that approach, being rejected by the current openwrt devs last year.
> 
> remember that a vote has been held already on the naming scheme. There was near universal agreement that a remerge should happen, and a slight majority that the result should be named openwrt. it doesn't do anyone any good to keep arguing points that have been agreed on.
> 
> David Lang


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170512/f64cb837/attachment.sig>