But thats the choice you make as the constructor (developer).
I doubt you´ll do the same, if there was a need of the 5 rooms, and no pool, right?
I think you miss my point. I´m speaking of functions, not how something is developed.
Okay, my mistake then. I thought thats what you said.
Ofcouse, if the binding no longer function after a certain time of periode, I would care. But as I said, I believe most manually installed bindings are under “work in progress”, which means, it´s just a matter of time before they´re added to the system itself. Ofcouse if there is no more development going on for this binding, it will never reach to the system itself… But then, why care… No one can do anything about it, if no one continue the development.
Ofcouse… Like I said - People dont like changes, (or some people I might say).
It´s their freedom of choice. They´re probably not complaning either, (and if they do, they´re wrong, except if it´s due to missing functions. Then its a matter of needs).
Re-building (or re-implementing if you like) is a sort of developing. Specially if you´re re-implementing to a newer core/OS/stage/whatever because it´s required. Which is exacly what I meant is important, if the addons (binding) in questions is still beeing used.
And as I said, I believe this IS the purpose of the poll to tell which 1.0x bindings is still beeing used and therefore needs to be re-implemented/re-build/developed futher. But if you re-implement and remove functions of a 1.0x binding, because the polls shows its beeing used, it makes no sense to me. The the poll would have to focus on function level insted. (which functions in a 1.0x binding is beeing used). I guess this require a new and a pretty huge poll then.
From the functionallity aspects, the re-implemented binding has to support the the needed and used functions. Otherweise there is no reason for re-implementing it to a newer core/system, except for new users, who may not need the old and missing functionality.
Those who use the “old” binding because they need it functionallity, they will not upgrade the core.
Those who needs the re-implemented binding due to upgrading the core, but need the “old” functionality, would be facing a dilemma. They simply cant use the binding. They will be forced to use the old core system insted. Or go without their needs.
So where does it leave the binding. Or even worse, where does it leave the core system and the users?
Lets try another example, a more “inside” one.
If Pauli stops development of the IHC binding, and re-implementing is required to be used in openhab 3 (and future version), it will put me into a huge dilemma, cause I need the IHC binding, (and I will probably hunt him down for the rest of his life 
).
I got two options. Either hope someone else continues from Pauli work or someone making a new binding (with the same functions ofcouse). Otherweise I´ll be left behind with openhab2, which means I can not support openhab3 and any future versions. Maybe I´ll even have to abandon openhab because of this.
There is a rather specific reason why backward compatibilty is important. You can start all over from scratch leaving out functionality. But you´ll have to face the fact, that it may result in users leaving or not following the development of the core system, if they are in a need of the functionality. A user not following development means a loss for the core system itself, in my opinion. Many windows 7 users havn´t upgraded to windows 10, because the applications they use and need, havn´t been updated to work in Windows 10. This is a loss for Microsoft/Windows 10, and noone else, in my opinion.
I dont think I can explain this any better.
Kim_Andersen: