@Carla, 

It does not mean that we all agree in the "way"/"detail" things are done with FRR since we have different visions for solving similar problems. But what is important for contributors is to have a valorisation and integration of their innovations in a coherent manner with the others: accept all innovations as long as they do not hurt.

Quagga was created in 2002 because Zebra was not open enough (close in fact) for any innovations. Quagga was successful in creating a new momentum but after almost 15y an evolution was needed. Unfortunately this shift lead to a fork! We did try to avoid it during almost a year, but we did fail collectively. So based on the push and pressure of the backlogs (see JR's email) the only exit was a fork:

  - FRR name is owned by a 3rd party neutral  (LF was selected),

  - no money, only engineering that is focused on improving code, code rules!

I hope FRR could get more attention from more IETF folks because some protocols are over specified, some others are under specified, some protocols become vendor lockin. I hope to see more universities innovating with FRR (like babeld from Université Paris Diderot), I enjoy the works from Netdef having some people attending IETF and being involved in FRR, etc.

We see many DPDK projects around since dpdk.org was launched by 6WIND in 2013 (fd.io from Cisco over DPDK, Contrail has been ported on DPDK by Juniper, NTT did launch lagopus) ; we see many networking orchestration and controller projects with some wide communities (ONOS,  cord,  Opendaylight, etc.) ; but there is a gap and lack of focus with routing protocols. So FRR becoming better is a must have into this networking landscape. 

Best regards,

  Vincent