[LEDE-DEV] Actual community change and additional developers compared to OpenWrt

[Jo-Philipp Wich]

Hi Alberto,

> I think it's mostly because of the usual reasons in opensource projects.
> Core developers are overloaded, and in what little time they have they 
> prefer to code (understandable, but same self-defying issues in OpenWRT).

IMHO this summarizes the current situation quite nicely and I'd say I
agree with it completely.

Note that we're trying to slowly dig ourselves out of the hole we made
ourselves over the years but it requires time and dedication. I for
example would love to lean back a bit and start caring more about
community matters and communication but before I can do that, we need to
find some more people compensate the missing developer time.

> IMHO The only way we can get over this situation is if current core 
> developers start giving others responsibility over some parts of the 
> LEDE system/infrastructure,

This is what we're trying to do with the Wiki atm.

On the infrastructure administration side, I am glad that Ted helps me
with handling things and for the wiki hosts we handed administration
access directly to the wiki moderators to minimize friction.

> put down some decent documentation about 
> current state of affairs in LEDE programs (what they do now and what 
> they should do)

That is sorely lacking atm ...

> and guidelines for checking contributions (mostly for 
> people that must check if the patch/PR is valid).

... and I partly agree here as well.

I would be interested in a more contributor oriented insight at this
point. For example it took me a while to realize that being on Github
suddenly means that people edit C code via the web interface without any
means to syntax / compile / run test their changes or to sign off their
commits.

The problem of such unsuitable contributions can be tackled from
different angles, first by improving documentation and enable people to
do better changes in less time and second by lowering the entry barriers
somewhat (while increasing developer workload), for example by stating
that a "Signed-off-by" in the PR description alone is enough and
requiring the developer doing the merge to copy the signoff into the commit.

One should keep in mind though that lowering the contribution quality
requirements increases the individual workload even more, at least in
the short term, until the increased contribution-friendliness eventually
leads to more man power in the long run.

> I'm taking the linux kernel as a model where things are split up in 
> subsystems and each subsystem has one or more mantainers. Yes it is not 
> a headless commune, but it isn't a nazi-like authoritarian regime either 
> (even if Torvalds likes to shout at people).

The Linux kernel is a good goal for a distributed and delegated
development model but one must keep the very high entry barrier in mind
- it is hard to write kernel code, most people working on it already are
professionals, there are no real bug trackers or easy web based pull
request choices available and the main contribution channel is very
active mailing lists, forcing potential contributors to send proper
changes from the get-go.

All that is making it easier (or in the case of the Kernel possible at
all) for the developers to cope with the steady stream of incoming patches.

As a somewhat related anecdote, people already neglected LEDE because it
requires real names and sign-offs in its Github pull requests - deeming
it a too high burden to invest time. Such contributors would never be
able to contribute anything to the Linux kernel.

> That way you can have a person that has commit access but can only 
> commit stuff of his subsystem, and core devs only need to look at stuff 
> filtered by others (or not if they don't have time).

Personally I'd like to move away from the fixed role of core developers
but I agree that some kind of multi-tiered system is likely unavoidable.

> This is the only way you can have more people in that checks incoming 
> code and core devs can be less overloaded and can actually take 
> decisions for the project where needed, or put down developer 
> documentation (what we have is very outdated and partial).

I agree.

> I understand that people have a life and all, but a project like this 
> cannot run headless forever because the 2-3 people that have access are 
> busy. Solution -> more people with access, each to specific areas.

Agreed, we just need volunteers with a somewhat proven track record at
this stage. Personally I see no problem with letting more people push
directly.

> Really, there are already quite a few large-ish and not-so-large PRs 
> rotting on Github, you can't afford to let them sit there for too long 
> or the people will lose interest in sending them, and think you are the 
> same as OpenWRT.

Which brings me to another yet unsolved point. There are large PRs
(think the Mikrotik changes) which are unsuitable for inclusion as-is,
yet too worthwhile to be left rotting.

Maturing such change series takes time and needs to be happen in a
dedicated staging tree, this is something we simply lack the man power
to do atm. That would be another useful area to have some help in -
having one or more persons who are able to incorporate requested
feedback into otherwise orphaned PRs to shape them up for inclusion.

> The same about that guy from a wifi community asking the state of 
> affairs. You can't let that go unanswered. Bad PR will add up and again 
> people will think you are the same as OpenWRT.

I am not sure what you refer to here exactly.

> Sadly I can only take seriously community-oriented roles atm as I'm not 
> a true programmer (I'm a junior Java developer tho), but with decent 
> documentation and guidelines for checking patches I can help out with 
> the PRs about new device support.

The help you provide, the effort you already put into cleaning up
packages and your participation in the discussions are much appreciated
already as this is exactly the kind of involvement the project needs to
survive in the long run.

~ Jo