On more than one occasion I've needed to modify contributed and other open source libraries so that it will 'simply work' for my project, or work BETTER than the original for my project, and so on. After all, in many cases you get what you pay for with free and open source libraries. You get free code, and you get the source, at no actual cost except the labor you need to supply to make it work for what you are doing.
but the single BIGGEST problem I run into is the use of 'private' rather than 'protected' in the class definition. It is something that I wish had NEVER been invented for the C++ language. It basically means I have to edit the original header files to change 'private' to 'protected', or else re-name everything into my own copy of the original built-in class [and potentially have unnecessarily duplicated code in my HEX file].
So, WHAT compelling reasons exists to use 'private' instead of 'protected'? I mean, really?
Why not just make a mass-edit of ALL of the code and convert 'private' to 'protected' so that it becomes EASY to write a derived class that does something specific and low level? This is about as 'open' as you can get, after all. No 'closed' class members, in other words.
As an example, I would like to do things with 'HardwareSerial' that take advantage of what's already been written (thanks), but instead of doing it "that way" for a particular function (let's say 'write()') I might have some updated high-speed buffer thingy that uses the head/tail pointers directly, making it possible to write out data FASTER than before at high baud rates. I would need direct access to head/tail pointers to do this. But they're 'private'. If they were 'protected', they would still be unavailable to regular user code, but AVAILABLE to a derived class. That's the point. I SHOULD be able to derive a class and directly access these members.
Granted, you can't always support that kind of thing in perpetuity, BUT AT LEAST YOU SHOULD MAKE IT POSSIBLE for people who want to do this, with an "at your own risk, this may change in the future" caveat. I could, I suppose, write a "MyHardwareSerial" library by copy-pasting the HardwareSerial code and re-naming a few things, but that's probably not the best solution.
In any case, can you at least CONSIDER changing all of the "private" stuff to "protected"? Please?
And this goes TRIPLE for contributed libraries. Again, I wish 'private' had never been invented for C++, when 'protected' does what you want AND lets derived classes access the 'would be private' members. After all, if you REALLY want to stop people from accessing those members, you should use abstraction. 'private' is completely unnecessary, and it gets in the way.