Really Using Free/Open Libraries
There is a big jump between breaking the COTS mindset and getting into the free and open source software (FOSS) mindset. When dealing with COTS software you cannot change it. You make wrappers, hacks, and beg the vendor to make changes which are ignored (they may make them... if you are IBM, CSC, EDS or someone like that). You get used to this. You think of that library as a cement box -- you may know the inner workings, you may not. If you do you still cannot change them or the next release from the vendor will break them. So, you work around the limitations, no matter how minor.
Most people use FOSS libraries this way too. If you have been working in a company that uses FOSS software think how many times you have heard, or thought, "it would be nice ot make it do X, but then we would have to maintain our own branch". This is the mindset that needs to change.
The old saw that if you see a problem in open source software, you should fix it makes perfect sense to people who write open source software. Quite a few people who use it, on the other hand, it does not make sense to. They think that The Developers (ie, the committers) are the people who develop a project. This sounds insane to The Developers but is a common mindset amongst users. A typical user of an open source project will find a change that would make their life a lot easier and then look for a different library that does it that way, or scrap the library and write their own. They do this because The Developers are the ones who work on the library.
Making the jump from user to contributor is easy. Make the change, attach the modified source file to an email explaining it, and send it to the developer (or even user, though this is frowned up) list. That's it. Nine times our of ten your change will be integrated -- it may not be in the exact form you initially submitted as there may be other things that other people see, but that's it.
Really using FOSS software means making the changes to the software that you need -- and giving it back to the project. This is in fact easier than not doing so almost every time. Developers talk about using 3rd-party libraries, but the real benefit comes when the library becomes your own because you are in fact developing with it. If the library is critical to your application you really should contribute to it. Initially it will be tossing changes over the wall, but most projects are eager to give people commit priviledges once they trust them not to go berserk.
James Duncan Davidson captures a lot of the idea, from a very different perspective, in his Rules for Revolutionaries email on jakarta-general a few years back. He is talking about a different problem, but the theme is the same.