Andrew: It's a difficult. You could diff your changes against the original and try to apply it to future versions, but if they change too much then you'd have to go through and make the changes again manually. I started writing an application to look after these changes, but then realised that the changes to the original would just be too large to pick up on without intelligence. Unless the original project writer can foresee all possible modifications and offer a hooking mechanism for your changes, it seems like an impossible problem to solve.

Simon: Things like Perl and Apache have large enough communities that I feel that any bugs will be noticed and fixed, but even so, I am evaluating the quality of the project on its popularity, not its development procedures. Although for large projects with a massive following this method of QA is not a problem, perhaps it is something that should be addressed by smaller projects, and considered by the people who use them.

More importantly though, I am only using their source code as a platform to build upon, and we are separated by a well-defined API - I don't worry so much about that. My main concern about using open source code is when I'm going to be using it as part of a project; in fact the thing that made me write the entry was something you linked to, the Dojo WYSIWYG HTML editor.

A decent editor is a significant part of the new CMS framework I'm working on - in fact, it will probably be the biggest change from my current CMS that my existing tech-illiterate clients will see. As a result I've looked at what's around and haven't found anything right, so have been developing my own editor on and (mostly) off for a few months now. The Dojo editor does at least some of what I want my editor to do, but in the minute or two that I played with it, I spotted some significant bugs, which implies a lack of attention to detail in the development process.

The other reason I won't be using it is that it's part of a larger system that I don't need or want to use. I'd have to do a lot of work to get it integrated into my system, and I'd need to extend it to get all of the functionality I will require. Although they've got a good API that may well not change, I'd need to extensively rewrite their internal code, so you could say I'd be making a fork. However, with the amount of work that I'd probably have to do, I may as well just write my own editor from scratch - at least that way I'd know how it works, what to test, and where to go to fix it. Actually this leads me on to another question, but I'll ask that in another entry when I have more time.

The feedparser tests are fantastic - more of this! I've never seen anything like that on an open source project, but it's a perfect example of what I was thinking was needed. I'd feel confident using that in whatever I needed it for. I'd like to see more projects documenting their testing, even if it's just a table to say what they tested. Although for some things, any documentation would be a start :)