You ask how you keep the motivation in using a given open source API project?
The trick is figuring out which Open Source projects are the good ones. The major qualification in Open Source is the fact that you have access to the source code, which is extremely useful when you need to find out how things work (which usually happens when you need behaviour to change in some situation), but this does not imply anything else than that. This includes the quality of the project which is completely unrelated to the openness of the source.
Quality consists of several more or less subtle things when speaking of a code project:
- How well is the API designed? Does the code you need to write to actually call the API read easily?
- How well written is the actual code in the API? Is it easy to understand what goes on? Are the data structures well chosen and do not have expensive runtime characteristics? Are variable names well chosen? Does the code conform to a coding standard?
- Is the API documented? This is both the design and javadoc of the actual code, and is it useful? This is more important than you may think, as it shows the maturity of the code.
- Does the project have a web page? Is it updated and without broken links? Does it provide easy access to source code, downloads and documentation?
- Does the project have a community and mailing lists? Are the archives available and accessible? Is the community helpful?
All these things are useful to have in mind when choosing if you want to use a given open source project or not. Any derivation from the best should cause a warning sign to flash in your head as it is an indication that this is not a best-of-breed project.
Then when you found the project, you like what you see, there is the final test:
- How hard is it to get up and running from scratch with a simple program invoking the API in a useful way?
This should be
- explained in an easy to spot location on the project web site and/or in the documentation in the download bundle.
- easy to get right - the documentation must be accurate, the program simple to write or adapt from a given, simple example, and both well explained and easily understandable.
- quick to get right - if you need to do any debugging at this point to get the program to run as explained, something is very wrong.
If it is evident that this is an anticipated and prioritized use case, then this should be trivially simple. If it is evident that the project does not care about this particular thing, then I would strongly consider not using it! If it is uphill here, it will be uphill many, many times later, and it will be better to just not use it.