I have a tiny project (<1k but let's say its <5k of lines). I made it open source and put it on github.

I did this once before and I didn't get a single download nor fork but that was very specific and this tiny project is very useable to other programmers.

It's open source (let's say LGPL, GPL, public domain or somewhere in between these). What can I do other than let it rot on my computer/online while only I use it?

I'll keep this as generic as possible and won't link my stuff.

  • 11
    For one, linking to it here. Jan 8, 2013 at 3:47
  • Blog post, hacker news, reddit?
    – elssar
    Jan 8, 2013 at 13:51
  • @SomeKittens: How? I mean, wouldn't creating a question and answering it myself with a link be spammy? Theres 2 maybe 3 i'll want to post in the future.
    – user2528
    Jan 9, 2013 at 0:03
  • 1
    @acidzombie24: We don't know what your project is about. Depending on what it is, there might be specific recommendations or ideas that people might have that could help you more than general "post on programming blogs" answers. Not only that, your project might even be useful for the very people who are reading this question! But if you're reluctant to tell people about it, I guarantee you'll find it hard to attract users. Jan 9, 2013 at 0:15
  • 2
    I got a tiny project (link here). I made it open source and put it on github. You should always use every chance you have to do advertising (as long as it wont be considered to be spamming). How do you know that no one here codes graphics?
    – jgauffin
    Jan 12, 2013 at 6:28

5 Answers 5


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


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


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 are a great way to attract new users. I blog ( http://blog.gauffin.org) and write articles at codeproject.com and other similar sites.

  • nice answer, but the blog link isn't reachable
    – CapelliC
    Jan 8, 2013 at 8:28
  • Most of your answer doesn't address how to tell people about the project. Examples, documentation, and source code history are only useful once somebody knows about the project. Articles, however, are a good way to get the word out. Jan 8, 2013 at 12:13
  • Well. He also said I did this once before and I didn't get a single download nor fork ... and What can I do other than let it rot on my computer/online while only I use it?. Which means that he didn't just ask about attention. Getting users is a lot harder than getting attention.
    – jgauffin
    Jan 8, 2013 at 12:46
  • But if you've not got any attention, you won't get any users. Jan 8, 2013 at 13:06
  • 1
    Examples examples examples examples. Really good examples substitute documentation, description and so on. Jan 9, 2013 at 8:35

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:

  • I don't really know any programming blogs. I only know of reddit and only once did i post something there.
    – user2528
    Jan 8, 2013 at 23:41

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?

  • That would be my additional option: a non-intrusive twitter account. It is easy to follow a user and if you don't spam, then people interested will not hesitate to do so... Jan 8, 2013 at 18:39

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.

  • I only post on SO. I guess i could put it in my profile but for two of them (the two i didnt do yet) i rather not. The old one i took down for a few reasons. One because i found that its a tool easily abused so i just decide to make it unavailable
    – user2528
    Jan 9, 2013 at 0:55

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 .

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:).