Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I see this problem quite often. I like a certain value proposition of an open-source project. I try out the basic tutorials. Great. It works! But if I move on to more complex problems, I spend hours of doing research, debugging, frustrations, etc.

What are your strategies to keep motivation in open-source going? What is the reward of open-source after success of basic tutorials? What "success" of open-source did you experience?

share|improve this question
1  
Are you talking about contributing to an open source project or using open source software? It's not clear to me from the question. –  Paddyslacker Oct 8 '10 at 21:25
    
let's say using an open-source API –  poseid Oct 8 '10 at 21:26
4  
Welcome to software development. This is our life, we try we fail we try again until we figure it out. –  Chris Oct 8 '10 at 23:57
add comment

2 Answers 2

up vote 3 down vote accepted

I am assuming you are looking at small open source libraries like those found on github. In my case I am often using one to solve a specific problem. If it doesn't solve it cleanly, then I dig in, learn how the code works and make changes as necessary. If my change is for something useful or a bug fix I attempt to contact the open source owner or fork my own branch.

Other times I am just adapting something close to my own needs, in those cases I just keep my changes and move on. I add watches or check back in regularly to see what has been updated.

As in the notes though, this is the life of software development. It's an ever changing environment.

share|improve this answer
add comment

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

  1. explained in an easy to spot location on the project web site and/or in the documentation in the download bundle.
  2. 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.
  3. 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.

share|improve this answer
    
thanks for pointing into the direction of software quality. –  poseid Oct 9 '10 at 6:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.