The egocentric decisions of the CM team - why hurt independent devs and the community

---

There are several kernel tweaks implemented by various devs that require/support adjustment of some sort of parameters. As an interface a dev usually adds some additional entries to the sysfs. When writing a GUI/frontend for this sysfs interface one simply reads/writes a value from/to these sysfs entries.

Around a year ago one CM team dev (which shall remained unnamed) did start to take kernel tweaks that are out there from other independent kernel devs and to re-implement them under an incompatible interface. His goal was to unify the sysfs interface across different devices so when implementing a GUI in the CM ROM Control the CM devs could use the same sysfs hook. This meant less work for the CM devs since they could use the same code in the ROM across different devices without modification.

However on the other hand that also meant that for each of those devices there now were two incompatible implementations for the same functionality which in most cases could not be both simultaneously added to the kernel. And while some kernel devs stuck to the original implementation, others adopted the CM version to be compatible with the CM ROM Controls. So this practice of CM did lead to an additional artificial fragmentation for those devices resulting in several negative consequences for both independent kernel devs and also the common users.

For kernel devs this means that they are forced to make a decision which implementation to support which practically means to decide which GUI tools to break since these are normally only compatible to one implementation. The original kernel dev of these ripped-off tweaks are hit the hardest since some of them have put out apps on the market to fund their work. So when other kernel devs adapt the CM flavor their apps will no longer work with these kernels.

On the other hand there is the common user which now has the additional problem to keep track which flavor is implemented in the kernel he is using and which GUI tools work with it. This results in unnecessary confusion which again leads to people complaining to the kernel devs that this or that GUI tool/ROM Control is not working.

As one can see the decisions CM has made work out fine for CM themself, however independent kernel devs and essentially the entire community gets the short end of the stick.

In February I contacted that one CM dev who was reponsible for these incompatible re-implementations and I explained my point of view, however he was not willing to cooperate. So early March Imoseyon, Francisco, Morfic and me contacted the CM team leaders. The reponse from the CM team was friendly, they seemed to be willing to cooperate and promises were made to get this problem resolved. Unfortunately it became clear that these promises were not sincere since after giving us a run-around for two entire month nothing at all has happened (http://h11.abload.de/img/cm11t89f.jpg).

At the end of these two month of fooling around with us and wasting our time the CM team did inform us that not only they will not revert the changes they made to fix the mess and confusion they caused but also that for the future they reserve the right to take kernel tweaks from other independent devs out there and re-implement them under incompatible interfaces (http://h11.abload.de/img/cm2evk65.jpg).

For kernel devs in practise this means that one cannot release a new tweak without fearing that CM takes it and reimplements it under an incompatible interface creating another mess. So for the future if one wants to implement a new functionality one better makes sure to use the same sysfs interface that CM has defined at standard. Whether this is intended or not by CM, this will be the practical end result. And having that threat always lingering in the background when one releases a new tweak is simply not acceptable.

We tried to avoid the drama that comes with publicly critizing other developers and showed a lot of restraint and patience in working out a compromise with the CM team in private, however as anyone can see from the published communications our effort clearly have reached a dead end.

We strongly feel that this is an important issue not only for us but also other independent kernel devs and the entire community and we thus feel responsible to bring an end to this hurtful practise adopted by the CM team of creating additional unneccessary fragmentation. So we turn to you - the community - to ask you to voice your concerns to the CM team. Please contact Jef Oliver (jeagoss@cyanogenmod.com) and let him know what you think - as always be respectful.

seriously didn't know the CM team owed you anything. They can do whatever the hell they want. Its your choice what you want to support or not.

I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).

Originally Posted by codf4ther

I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).

Well CM team aren't doing anything illegal, but what they are doing is just wrong. Taking a dev's work and turning it into their own work without permission and cease support on the original work. That's plain wrong...

Sent from my Nexus S using Tapatalk 2

Why not adopt CM's sysfs interface as a standard? Then either the kernel apps or rom control can both control the kernel? Isn't that best for the community?

I remember when we never had to pay to control our kernel, now you are basically forced to buy the kernel apps ... Doesn't forcing users to buy separate apps actually hurt the community and foss?

I have no problem with supporting the great work of rom or kernel developers but, I would rather donate to a dev than be forced into a market app to control the kernel.

I have bought Franco, GLaDOS and Trinity apps btw.

Originally Posted by ljordan2

Well CM team aren't doing anything illegal, but what they are doing is just wrong. Taking a dev's work and turning it into their own work without permission and cease support on the original work. That's plain wrong...

Sent from my Nexus S using Tapatalk 2

ummm this wasnt about permission, furthermore the code is gpl, dont need permission as long as they obey the licence and release source. the case here is fragmentation caused.

Originally Posted by codf4ther

I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).

I never said they stole something nor that they did something illegal. I am just describing the consequences of their decisions which is hurting independent devs and the community for the sake of saving some work for the CM team devs. And hurting others out of laziness is wrong in my book.

I remember the different Voodoo and BLN sysfs in NS CM

and Color Control for GN

The Kernels using Ezekeel's Color Control

GLaDOS / franco / Trinity / Lean / Popcorn / Air

vs

The Kernels using CM's Color Control

CM / CMPlus / faux123 / JameBond / FuguMod

serious disruption!

Originally Posted by blowtorch

Why not adopt CM's sysfs interface as a standard? Then either the kernel apps or rom control can both control the kernel? Isn't that best for the community?

I remember when we never had to pay to control our kernel, now you are basically forced to buy the kernel apps ... Doesn't forcing users to buy separate apps actually hurt the community and foss?

I have no problem with supporting the great work of rom or kernel developers but, I would rather donate to a dev than be forced into a market app to control the kernel.

I have bought Franco, GLaDOS and Trinity apps btw.

+1 Sounds like a format war to me. If there's no disadvantages to their implementation than I don't see what the big deal is.

Originally Posted by JS0724

+1 Sounds like a format war to me. If there's no disadvantages to their implementation than I don't see what the big deal is.

All users across all devices would benefit from using CM's kernel standard