I got a couple of projects at github ( http://github.com/jgauffin) which have received some users. What I do is:

Examples

Developers are lazy. If they can’t figure out how to use your code they’ll just continue to search after another library. Clear and concise examples are important

Documentation

When they have started to use your library they’ll need some sort of documentation to be able to configure and use it as they whish. No doc = they’ll give up.

Source code history

Users will always be skeptical to new projects. Not many open source projects survive. Just look at github/codeplex/sourceforge. there are a lot of abandoned projects. You can’t expect users to dive in until you have proved that the project will continue to live.

Articles

Articles are a great way to attract new users. I blog ( http://blog.gauffin.org) and write articles at codeproject.com and other similar sites.

In short: Your project probably needs a clean and simple explanation/introduction on what business problem does it (library/project) solve. Thus, there should be a good reason to prefer your solution over others to be picked up.

Thus, with good, clean and short explanation you may get the interest of community.

As it is mentioned, you have to spread the word about your “baby” project in social media and programmer blogs. Look to the related forums where such a specific problem is discussed or issue is not addressed yet.

Resources to look about Github sharing and managing tips:

• Share your open source project via GitHub
• How should I create an manage a github repository for a shared project?

My first step would be to post it on any social media outlet that you use.

Twitter, Facebook, Google+, maybe even your LinkedIn profile (if you have one)

It will be the easiest avenue for word to spread out of your hands.. Post it to twitter, ask all of your friends to retweet, ask your friends to share and see what happens!

What is the project, if you don’t mind me asking?

You say that it’s very usable for others, what for? If there’s a particular niche that could find use in it (computer vision, audio processing, UI, statistical analysis etc) chances are there’s probably numerous forums and online or even physical communities around this. If you’re part of one start there. Create a post in the forums, let people know what it does and where the project is going. If you’re not part of one, join, be social, talk to other programmers. Hell, you might even find another project you want to contribute to.

Apparently those in need of your project, whose problems it intends to solve, have to be made aware of it.

I think Stack Overflow, as “The Wikipedia of Long Tail Programming Questions” is quite appropriate place for your target audience:

^{For every person who asks a question and gets an answer on Stack Overflow, hundreds or thousands of people will come read that conversation later. Even if the original asker got a decent answer and moved on, the question lives on and may continue to be useful for decades…}

Stack Overflow practices and principles also can guide you on how to present your solution appropriately. Note these also apply beyond Stack Exchange network sites, it’s just that here, these are stated explicitly and polished by vast practice of presenting problems and solutions to these.

As an experienced high rep SO user you are probably already well aware of these and in particular of the guidance given in below resources:

• Stack Overflow -> How to Answer

  ^{Read the question carefully. What, specifically, is the question asking for? Make sure your answer provides that – or a viable alternative. The answer can be “don’t do that”, but it should also include “try this instead”. Any answer that gets the asker going in the right direction is helpful, but do try to mention any limitations, assumptions or simplifications in your answer. Brevity is acceptable, but fuller explanations are better…}

• SO FAQ – May I promote here?

  ^{Be careful, because the community frowns on overt self-promotion and tends to vote it down and flag it as spam. Post good, relevant answers, and if some (but not all) happen to be about your product or website, so be it. However, you must disclose your affiliation in your answers…}

Note if you found no questions to “match the answer” you’d want to write, it is legitimate (and even encouraged) to submit your own question and answer it yourself. If you’re interested in details, refer to MSO ‘self-answer’ tag wiki, there are quite helpful references to SE blog articles. You may also check some questions in that MSO tag to find out what can possibly go wrong and how to do it right.

Overall, your tactics can be pretty straightforward. Find (or write your own) description of the problem and write an answer explaining why and how it could be solved by your project. The better answer you write, the more chances for upvotes it gets, the better chances it will get to reach your target audience.

One thing to avoid is posting link-only-answers – as you probably already know, these are rather highly discouraged. Posting just a link to your project won’t bring you much, you better give an easy to read and understand description of the project explaining what problems it solves and how.

Assuming that relevant questions may appear at any time, it may be difficult to be always ready to quickly give an answer of good quality. For your case, the most natural way to be prepared is to have a readme file right there in your project, with text that would be easy to just quote when needed to explain purpose and strong points of your project. Keep it under version control, update and polish the text in there and you’ll always be in the best possible shape to send a message to your target audience.

In a small simple project, readme file like mentioned above can also serve a purpose of developer guide, having sections for usage examples, how to start, release notes etc.

Another thing you better be prepared to is to answer typical questions about your project. First of all, these could be like how to start and how to use – it could be very helpful to have “canned” answers to these in respective sections of readme file, as mentioned above. Note if you find some section gets too large, nothing prevents you from “extracting” it into separate file and just referring to it in your “main readme”:

• ^{How to start.
  Refer to file docs/QuickStart.txt
  Usage examples.
  Refer to file docs/UsageExamples.txt}

Another kind questions from potential users one can always expect is “what if I discover an issue / bug in the project?” This kind of questions is best served by issue-tracking.

For a small simple project with little or no issues at all, this can be done as simple as just adding a section “Known issues” in readme file (if issue tracking eventually overgrows that, this will likely need to “migrate” to real tracking tool).

• ^{– what if I discover an issue / bug in the project?
  – Update section “Known issues” in readme file}

Even if you believe that for some reasons your project is bug-free, it is just easier to refer askers like above instead of giving them lengthy explanations for why you can’t have bugs (especially taking into account that it’s unlikely someone will believe in bug-free code:).