I'm sure there are some difference between the development of a framework or library and an application.
Development processes are essentially the same. The differences may come down to marketing and deployment issues, although I find that the biggest differences are usually in terms of project scope and definition. Remember that an Application may include or use a framework or a library, a framework may be a collection of libraries.
I have some doubts about how to handle the organization and managment of that project: Are there some general rules to follow, tips, best practices or something to keep in mind for developing this kind of project?
Project organization and management are again the same for any development project. Again it comes down to scope. When it comes to writing a framework however, it pays to have a very clear vision about what it is you are trying to achieve, and to place strict design rules on the public interface to the framework to ensure consistency in terms of the API's presentation. If you allow every developer to do their own thing, you'll end up with a complicated mess, and a very inelegant API design.
I'll second Ryan Hayes' recommendation to read Framework Design Guidelines even though the book itself is aimed at developing .NET based frameworks, because the general advice is applicable regardless of the specific implementation technologies that you might choose to use.
From experience, I would advise sticking to the classic YAGNI principle by implementing the most simplistic public interfaces first, and then expanding to offer greater control and depth later on, but be careful to use useful names to show why methods or classes are being expanded. I've never been a fan of adding "Ex" or other similar suffixes to method names, or adding numbers to expanded Interface definitions. Differentiate on functionality, and your interface/method names should become clearer, and hopefully less obfuscated and confusing.