Skip to content

Latest commit

 

History

History
804 lines (598 loc) · 38.9 KB

README.md

File metadata and controls

804 lines (598 loc) · 38.9 KB
Raw

A list of notes/tips for how to "make your open source project successful".

The Problem

OK the problem in my own head is.

if you don't do something that's your "passion"(document on "passion project"), then you will tend to abandon it half way. Another, or possibly the same(?) problem is you might get split or diverted half way through. You need to push through probably (though pivoting is OK) to make something truly useful.

Seems at most a couple of projects "at most" that you really do/focus on, because if you have too many, you'll get support requests for "old" projects, and the motivation to fix it is harder, because you have to recreate your dev environment and somehow. Since its so old which makes it feel more foreign'ish, and resurrecting it is hard.

Another motivator: Start a real side business out of it.

you don't have to make it an "exclusive" business.
it could have free and pay tiers, or "donate what you think its worth" or
"make money without charging" like adwords, etc.
(or "make money later" or make money by being eventually acquired, etc.)

Not for me tho, not my style.

or have tiers for "if you can afford it,
you pay this, otherwise free [like "do you make enough money? pay this, otherwise pay this]" 
or "charge for business use" or what not

In the end, it seems that if you just do it as a passion project, free forever

1) you won't have as much time to work on it (since you gotta work your day job too)
2) you'll probably, most likely, assuming you're human,
human tendency for developers is to make it as good as they need it to be,
for them, for their own use, and that's it.
There is really little incentive to motivate more than that.
That's as good as it'll be.
However, if there's money involved,
you can move quite past that point in terms of overall quality.
So pick your destination here.

If you do pay/charge for it think of how much cooler it may become, even excuse to provide real support [!] etc.

I may have been wrong about preferring open source/free [?]
You can have a dual:  it's free with "an enterprise tier" or what not--it seems that if you reeeally want your
   open source project to be well polished, you've just gotta add some kind of income facet to it...

It's a question of what/how good you want the end product to be.

If you don't get remuneration (you don't have to always "charge" per se),
it will "end up looking like X" and
if you do get remuneration it will "end up looking like Z".

Which one do you want to bring into existence?

And yet there is a 3rd option:

you just pay for it, with tons of your own money,
and then it can exist
(like you setup the framework, pay others to do the heavy liftwork/amazon turk).
or *maybe* *just maybe possibly* you could setup the framework and have others contribute for it,
but don't count on it until you know you have rabid fan base that will do you every bidding.

Some projects do offer tiers, or an intro freebie.

If you don't go the pay route, expect:

1) to have to fund it yourself *forever*
2) to have to force yourself to work on it/put extra time into it to make it look good,
add features "you don't use" etc.
You're going to have to like schedule yourself to make it grand.

Is it something you're going to go back and add in little features that you don't even need, to it?

They feel useless to you.
Are you happy/excited to go and market it and keep marketing it, yourself?

Another option: do a patroen, then you can keep it free but it motivates you to go get more "customers" still :)

Is it something you'd actually "do" or "get around to" grooming the code, like really grooming it and finishing up the loose ends and unit tests?

Would you enjoy it that much?

Something you could be/become truly devoted to? (the project/cause)

Even if you run a kickstarter, it may not be enough, you might eventually run out of cash, then what? Example on openshot 20 september update (update after many months) unless you have some way of cash flow turn around [donations? "premium" version or "monthly donations" maybe]

normal people do this by producing a saleable post-product. :|

NOTE: Read this, how to spread the word about your code (hacks.mozzilla.org)

90/10: last 10% takes 90% and is the 10% you don’t actually like doing [mundane], but is equally as important.

It works better when it's your passion, something you are passionate about. Those long lonely nights for instance. People just give up.

SEE ALSO: my notes on soul project [though "pay factor" would work here as well]. you could have a half pay, half free tier as well, or what not.

Things to help you popularize if it's not a "soul project"

Possibly pay others to do it (ex: marketing it) for you. Or build a community and they advertise it "for you." (ex: word of mouth), etc.

The "startup community" has studied this awhile. They have studied "similar stuff" forever and come up with some excellent best practices for getting things started. So it would probably be useful to read/adopt some of "their" best practices. Example:

taking your idea,
ask tons of people about it, etc.
fail fast, pivot fast, etc.
therefore, you should be read these as well, possibly before even starting:

books that an Enterpreneur teacher loved/recommended:

  • Business model generation by Alexander Osterwalder, Yves Pigneur
  • The startup owner's manual by by Steve Blank , Bob Dorf
  • Lean startup by by Eric Ries (to a lesser extend)

Read Mozilla hacker article 'Treat Open Source Like a Startup' by Julian Shapiro. Very good blog post!

OK the real kicker is that you should probably not really start into something without realizing some caveats. Like, you'll probably, most likely, typically, be the only leader of your project. Maybe it would be good to therefore only stay into projects you are really passionate about and could stay passionate about for years to come. Like ten years.

Because you're the one who will be chasing down new features for people that you don't actually care about. Things that don't affect you. And doing the crappy work on it like bugs and dealing with poor input etc.. Stuff nobody else wants to ever do. And doing marketing. Possibly all of it. And it takes forever.

At least initial marketing to popularize, Then Google organic can kick in. If it does its the saving grace of developers since in essence it does your marketing for you. You can hope anyway. But even with good seo maintenance will still be present and on your shoulders.

And forums and irc chat 24/7. Having to check Facebook's.

Basically, it needs to "be" a passion soul project for you. see its notes. (passion project notes)

You basically "have" to choose something to "focus" on it, or else it will end up not being awesome. You have to focus on one or two projects or you'll never get them to super prime time shape!

Even if you're past the advertising phase, you'll still have "some" maintenance (like daily/weekly) stuff and it will take time. If it's your passion, won't that be much easier? (i.e. it still takes time, which requires something like passion or duty). there's nothing wrong with providing "$10 worth of value" to people and asking them to pay you back $2 :|

And it will all be for free most likely. Our absolute beginners who know nothing yet. Training them. You might make some money of it, or possibly convey into a pay project (where's the fun in that?). But probably not. The gifted few might even make a salary. But that is like rock stars.

There can only be free. Assume you'll possibly make nothing. This better be a passion. Or it will end mediocre, seemingly. Or at least not polished, and not improved.

I wonder if focusing on "only one project" would help but it would need to be only one, for years. Especially when that focus contains marketing (Which is another reason partnerships work sometimes. One can focus on one thing while the other does the technical)

It is either that or do both yourself which is tricky. Especially for technical people who dont want to do much. It is not natural.

Idea

One idea: try to take some more queries from lean startup. Like polling and pivoting so you can put your "decade". With off effort into something that can become even more popular/useful.

NB: the mentions here on google keyword stuff are less important since the EMD update. so are deprecated.

plan up front of spending a lot of time (budgeting a lot of time) to marketing

NB: that this doesn't include much on successful marketing. which is 80% of the product, though getting good google SEO is a strong step in the first right direction for marketing.

Steps to make your open source project popular.

The end goal of any project should be that people use it. And typically, you want it to be used by the most people that would benefit from it, if they knew it existed and used it. Basically your goal should be to make your app as popular as possible.

It is worth it to try to popularize your program. It is worth the extra time and effort.

Basically, you need to spend lots of time researching marketing and sales.

Expect to spend 50% of your time doing unsultry things, like writing documentation, writing up press reports, creating installers, etc. Also expect to spend some time (a lot?). Adding features that you don't care about (and possibly don't even really like?) because others think they'd be cool.

Having an in house "cooling down time" while you use it to test it before releasing is good.

They say that a website is 80% propaganda 20% usefulness. If nobody knows your project exists, it doesn't matter how cool or useful or better it is, nobody will use it, and nobody will participate in it.

So here are some ideas how.

  1. Have a useful app.
    • you can distribute it to developers before it's useful or polished.
    • you should distribute it to "prototype" users during the development process, to refine your requirements and re-assess what people actually want.
  2. Make it easy to use. Ask for user feedback on this. And do it early.
  3. Try not to have too many bugs which annoy users.
  4. SEO. This is the key. Google can help you find users that you never could. And is the great playing field leveler.
    • How to increase SEO: Use the google keyword ad tool to see what the most popular "related" queries are for your product. Make this the name of your project.

Example:

for a project which takes "loopback" audio and captures it as a device,
the following were the statistics:

waveout mix 1600
audio sniffer 390
record what you hear 12,000
virtual audio interface 320
audio loopback 1900
record speakers 12,100

audio capture 246_000
virtual audio 135_000
audio grabber 165,000

So now choose a project name that matches the most popular:
in my case: virtual audio capture grabber device
  • Maybe add some personal flair, like "yet another" or something to make it distinct.
  • Rename your github project this,
  • create a sourceforge project with the same name style,
  • change its "project url" to point to yours,
  • create the "project site" as virtual.audio.capture.grabber.device.t28.net or the like. (t28.net is freely available on afraid.org)
  • You want as many links back to it as possible, esp. if it's a related conversation or the like.
  • Post to your blog a post "virtual audio capture grabber device" with a link just to your project.
  • Possibly several different posts with different common keyword combinations.
  • Also could blog like "competitor/alternative to xxx" with the name of some popular (pay) competitor et al.

Search for the various words that match (all of them, even low popularity), and try and post links back from there to your project. Be careful to not spam, though.

  • Use your "real" name when making blog entries, and don't make extra blog entries, just change the url you use to your site.
  • Be authentic/legitimate or you'll be marked as a spammer.
  • If you do get marked as a spammer, then change your url to somesubdomain.yourproject.com .
  • For the first few links, try and add yourself to them.

Reference: Promoting Open Source Projects by lex li (blog.lextudio.com)

  • Make it part of your email signature (have your name link back to it, or the like).
  • Make a facebook group page for it,
  • Get 25 people to like it so that it can be visible or the like.

Then the secret is to "keep pushing it" over time. As people blog related things, tell them about it, et al.

You can never make it too easy for end users. Assume they'll be "way more naive" than you even think they might be.

  • Post to mailing lists that are related (or even once with each release or major release).
  • Create google group with the same name.
  • Link appropriately.
  • Get your-name.com

  • Add yourself to alternativeto.net.

  • Get people on facebook to "like" you or your web page

  • Maybe add yourself to online indexes of competitors (like dmoz or the like)

  • Create youtube account with name, some videos, link back to your project.

  • create google "project" (code) with same name, link in.

  • Try to have "related" sites link back to you, in their links page for example,

  • or have them do a blog post "about" your new site or the like, Friends, family, anybody.

  • If your project is a fit, advertise it on stackoverflow questions, while extolling its virtues.

    • Same with various mailing lists "semi-old" threads or the like (don't do too many obviously).

  • Tweet about it. That is, be social, so that tweeting means something, then show it off.

  • Post it in ycombinator (?).

  • Stackoverflow has some good ideas (follow the links, too).

Basically your goal is to advertise "where your people are" (your end users).

Find them. Find a way to advertise right there.

  • Add tracking (google analytics works) so that you can see where more traffic is doming from and how to focus perhaps).
  • Ask your users or potential users what they would want to see (and/or possibly "what would you pay money to have related to this project" since that's what would be more important to them).
  • Don't have your project "home page" be github as then you can't track analytics
  • Try to get past a tipping point artificially.
  • Sit down with somebody and have them try it out (preferably while talking out loud).
    • The closer to your target audience the better.
    • Ask for feedback (then respond to feedback and show them the fixes preferably).

In general, start early, release early (but fully tested) to build your project(?).

In general, start with something that "if users knew it existed, it could become popular ever" (example: Imagine the best that could happen with your project popularity wise to check).

You could also submit a patch to a previously existing already popular project, as a way to immediately have "your" project be popular.

If there are no google searches "near" or "close" to your idea (it's too radical or the like) then you could look for popular searches that are "near" or "related" and append them to your project name possibly, though I've never tried that.

You could take over an already popular project you're interested in (or become the "3rd main developer" for it) to get some free popularity.

A few case studies:

Luis Lavena took over the One click installer for ruby for windows.
Its download number was already 3 million when he took over.
Instant popularity!

VLC media player does something most free players don't,
which is play DVD's back right (and also most files, etc.)
They're by far the most popular sourceforge project.

Rails had some screencasts initially (and high-ish quality online tutorials)
that really helped its popularity.

  • May want to include "free" in the name.

  • Do polls what else would you like this to do? or What about these ideas how important would you rate them?

  • Polish like beautiful code or documentation, examples, "book style" tutorials, books, all help.

Keytool

Use generic searches (two words'ish ?) and it will tell you what related popular searches are, so you can see the best names to use. Click "order by global to see which are most popular. You can also enter "competitor's" names as search criteria and it will tell you all related searches to them.

  • Blog posts that make it, match google searches that are high for it. Advertise as a competitor to that other fella.
  • Google the various, try to leave comments et al.
  • Add project as list of competitors on alternativeto.net
  • Present at conferences/fairs/local user groups et al (never tried this myself but it could help spread the word/look for collaborators/get early feedback)
  • Advertise local newspapers (?) "local company creates x!"
  • Big "free download" links.

This may be annoying, but if you want to attract "lay" members, you'll want a youtube video or something like that (with a person describing it or what not). maybe on the main page, but don't auto-play that's just too hard.

For code projects, and a little bit other projects as well : Until you have demos/screen casts/sample programs written in it/production apps, nobody knows that they can show interest.

  • Screencasts on youtube with good "appropriate" names so that it can attract google SEO/be helpful.
  • Google +1/Facebook like.
  • Easy way for "lay" contributors (ex: google +)
  • Easy feedback (feedback box).
  • Uservoice, to allow for voting (?)
  • If you have any related projects (or perhaps any other projects at all) where you could advertise it, that could help, esp. if they're popular.
  • Be kind, gentle, thankful when you get user contributions. Why not?
  • Have an contributors file, add people freely, tell them.
  • "Lurk" online (google alerts? stackoverflow?
  • Other related mailing lists?
  • Blog entries that get posted about your topic?) and
  • Answer peoples' questions/point them in the right direction.

Support your product.

Why not?

Be nice to newbies. If newbie questions are too lame, establish a FAQ so you can redirect them easily to something that even they can understand.

Port it to Linux if you want to have developers help you on it (and/or mac if your developer base is more on mac). Your initial users may only be developers, anyway, so building that initial community might be good to get things started.

If there's something like rubyflow/infoq that you can submit things to, then do that.

On your website:

  • Make it look reasonably good. At least one image, nothing ugly.
  • Extoll virtues of your product.
  • Extoll what makes it unique.
  • Big download button, right on front page.

Rename your product early.

Don't like some other project? maybe consider fixing that project instead of starting your own.

Benefit:

  • Less maintenance burden for you.
  • You avoid having to popularize your project at all.
  • Forking is an option, too. (and/or re-branding).

Release "dev" betas earlier on, for testing, even before user betas.

  • Pay for related newsletter
  • Adwords,
  • Plead for facebook like/google +1's on your web site.
  • "Follow us" on facebook.
  • Tweet/facebook it for releases/news/comments
  • Mailing list same name as project.
  • domain, title same name as project. At least the subdomain.
    • m/b domain name like netflixinstantcompetitor.com though I'm not sure if that helps or not.
    • m/b subdomains with that name? e.g. netflixinstantfreecompeitor.com

Start with a project that (imagine the ideal of what would happen with this project) could ever become very popular.

  • Just help some popular project instead of starting your own.
    • Or use their libraries in your project possibly
  • Try to advertise to "your audience" or in vaguely related newsletters or real newspapers [?].
  • Ask people first if they like your idea (people from your potential user base).
  • Make it easy to use/human friendly, GUI/admin control panel.
  • Polish (Not the country). Get the fine edges worked out.
  • Have a UI. make it friendly.
  • Make a "lay" version that cannot be misunderstood (expert version is ok too).
  • Watch people using it while they talk out loud.
  • Look past your own needs for what it should do.
  • Submit it for reviews by cnet, etc. slashdot? That type of thing.
  • Put your "name" in h1 tags, also name your movies/video with SEO friendly names.

For the true work-a-holics, here's how to try and boost your facebook page more: 7 tips for boosting seo of your facebook page by jim belosic (searchengineland.com).

Basically name the tabs well is all he says.

The reality is that you may need some GUI or some simplified means for them to access your program, and/or understand or use it more easily.

You need two means of contact a "feedback" form and a group. Preferably google. Email address doesn't hurt either, though you can post the email to address of your group, too.

Don't be afraid to not do your own project, but just become the "5th man" in another popular open source project. After awhile and many high quality patches, you'll probably become well accepted, and your contributions make a difference, not to mention the ease of not having to take on the "whole load" of maintaining/popularizing the project yourself, as well as possibly being able to avoid having to popularize the project at all, if it's already popular!

Sourceforge is a good place to host your "main" site since you can have a custom subdomain url, and add your own analytics, and have free hosting.

Or hosting it under github as "github pages" works, too, subdomain wise effectiveness, though possibly a bit odd.

Don't be afraid to "pivot" your project every so often with feedback from users, so that you can create something of most value. You want to create something of value because that would be good for society, right?

NOTE: register with me and I'll give all the adwords profits to you! (or, give me your adwords ID)

Possibly something that connects bid for fix'ish with their checkout(?), since your goal is to help people. In the end, become the 5th man/documentation guy/mailing list helper for some other project or group. They'll love it, you'll make an immediate impact, avoid duplication, life is good.

Use google alerts.

Super simplified version of app

You may need a "super simplified" version of your app, for distribution, for non technical users.

The mark of a truly polished product (not that polish matters, functionality is 20%, propaganda is 80%) is that it runs "wonderfully well" on windows (Like VLC). They've polished the edges off in windows.

For software projects: documentation isn't finished until you have a book.

Once you have used your software for too long, you have no idea how normal humans will see it. Or how they will use it. Or what will concern them. You need to run it through/past a few of them first.

Screencasts for "getting started" (and/or "how cool this is") are needed.

Quality over quantity.

Become a contributor for a lesser maintained project maintain lower "layers" of software to have a big upper impact.

Maybe advertise next to some related projects, or (if retail) list things on ebay in the hopes of attracting traffic back to your site a bit (interested parties).

"Push through to perfection" (and have something that people would use if they knew about it, I guess, but quality over quantity anyway :P)

Maybe sometimes in order for a program to be useful to people, it has to be made more system whole. Like, not a directshow screen capture device, but something that makes screen capture easy/awesome using it.

If something is more "generally" useful (a new mouse trap) then it has the potential to become more popular. VLC "a video player" but I suppose that doesn't prevent you from writing something small, high quality. Find a niche, fill it, I guess. (an end niche might be better than just a library, indeed)

Sometimes you have to have tons of value added before. you can add value, if that makes sense (angie's list). Seems like once you have the right name, and the lurking, then you just need tons of value.

Your command line utility is not complete until it has some type of wrapper GUI on it.

It helps for web sites to add tons of "useful" data first somehow. Escpecially if you want to crowd source it. Like wikihow needed/needs to pay people to do most things originally [or was it ehow], and how amazon pays people via the first vine program to write high quality reviews. It is forcefully adding crowd sourced useful data.

The ideal is quite possibly a "multi tiered" approach, where each tier is its own full blown distro somehow, so that others can notice/re-use/know of the individual pieces bundled underneath. And you can get SEO for each piece.
Developing a "final, end user" app for your individual component pieces may help them to get used.

advertise, advertise, advertise. it's what business people love, more exposure, and so should you.

I think the principle is, work on a few projects and polish them, not tons of projects that don't affect many people.

Normal end users want some wrapper that insulates them from all of the output and complexity of the lower layers. dirt simple, your own layer on top that abstracts out all the others.

Functionally complete != polished!!!

Add a link to your "stuff" in your email footer. spammy, but possibly effective.

Make yourself "very useful" and you will get the users (ex: firefox, but other things too).

opensiteexplorer.org "might" show you which of your backlinks are actually useful like they don't have a rel nofollow

Actually, trying to add your site to wikipedia articles that are related "might" help with SEO, even though they don't give credit for the URL. It "might" build traffic as well.

Focus

Better to focus on just "one thing"? (lyrics vs. sheet music?) first?

Once you're done with it, that doesn't mean it's finished.

If you can build a tool that other people can use "for their projects" then that could be useful. Making others money is typically popular. A tool they can use to build their dreams/help them is typically useful.

You should make it functional, and also make it pretty.

The best way to "fine tune" it to match your audience is to walk a mile in thier mocassins. Or ask them. Or if they're techy, they'll just tell you.

In other words, the idea is that there is no way you can fix the command-line interface, for a number of reasons, not the least of which is the inertia of a precious few power-users, which according to Apple's Human Interface Guidelines is not a good thing: "If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users.". "

"Like" making it easy to use for end users. Make that your goal. Also making it easy to install/get, easy to use.

People like things that are useful to them. New mouse trap, som tool for marketing, a DVD player.

In reality an open source project should "pivot" to do/know what is useful for them.

Github "readme" links might add some SEO. Probably not enough to matter :P

Don't rely on somebody else to make a pretty gui for your app. You make it!

Make it as good as you need/want it, then envision/go one step beyond.

"Imagine you were making it for paying customers, what features would you add? How would you change it to make it more user friendlier?"

In true, normal business sense:

  • take surveys to see what people would actually "like/want" to use if they could have it, too.
  • See what do/don't use currently, too.
  • Ask them for feedback for the program, i.e. what they'd like, too.

For a library, you need good "documentation coverage" of basically everything. Like examples, in the documentation/tutorial, of how to do each/everything. reference: best documentation thoughts by rogerdpack (betterlogic.com)

Every project (well maybe not API Libraries) needs a website (or at least some way to get to the documentation/tutorials straight-forwardly). Non API, definitely needs its own dedicated website.

To get a language/runtime popularized, you have to do a lot of things "for" people--like a quality standard library. This same principle may apply to other things.

Put on final touches like a professional looking webpage, the "installer icon" of the installer package, etc.

Making things easier for the end user can be excellent.

Actually working and being user friendly is only 20% of being successful. Rest is propaganda or something else that I don't understand.

Others

  • Get awards.
  • "Have popularity contests somehow" that can help press releases?
  • Read books on it,like acangiano's on blogging
  • You need a pro looking website, and pro looking installer, and pro "marketing" something like that.
  • You may need to "know how" to build up a community.
  • Real website url probably helps.
  • Advertise on alternativeto.net, SO, reddit, community forums "related to your topic" [?] etc.

You can't rely (at the get go) from crowd sourcing people to do your work/propagate things/get the ball rolling for you, nor can you rely on "other developers" to pitch in/join the team immediately and start adding features/fixing bugs/ making it work for you.

The only thing "end users" really end up caring about is 30% functionality, 70% the "look and feel" and "ease of use/ease of setup". Something close to that anyway.

They say building a tool will bring people running but, building something intuitive might be more important for end users?

User and developer

Should pivot often to meet "real" user needs.

User feedback is critical for developing what people actually want to use. I'm not sure how closely this is related to actually becoming popular.

Realize that "closed source, free" == "open source, free" to typical end users.

submit it to c.net for reviews or the like

Don't expect basically any other developers to join your core team. For some reason, it's really rare (like FFmpeg rare).
Small contributors, possibly, feedback from "lay users" more probably.

Having an irc channel (with easy connection somehow) might be a nice thing, ideally inline on the website.

Expect it to take more time than you anticipate it will take (well coding always does, but for the polishing and advertising and doing things beyond what you would normally do just to get it working for yourself to use). This may mean that you can't do as many simultaneous/different projects at one time. Limit yourself to one or 2.

A quality "README" doesn't cut it. It should be a website explaining the concepts to users.

Market early and market hard. Since it's 80% after all. Even before functionality has been built. It should be stable probably. So I guess polish up early releases to a marketable state? Don't need bells and whistles.

"Real" end users only care about (mostly) the final final end product "what could this be, at its conclusion/fruition with all the bells and whistles added, etc. Of course, you'll want to pivot to really know/understand what end users end up wanting.

NOTE: re-read How to make your open source project really awesome by the clojurewerkz team (blog.clojurewerkz.org)

Seems like you almost want one guy just full time doing PR/getting feedback from users/beta testing while the other works on it. Submitting it to C|net, polishing UI [?] maybe there's enough work there.

Best way to test is to have somebody use it for an extensive period of time (or you use it). In use you tend to run into things. It is excellent testing.

People dont' care how excellent your code or test bed is. They just care about the polished end product. Like the technology side, per se, doesn't matter. Awesome code? don't care. Rockin' gui? care, possibly more than I imagine.

It seems that if you do your project then are just fanatical about promoting it, watching ML's so that you can promote it, basically getting all fanatical about it (and possibly about supporting it? adding new features to it, etc.?). Basically devoting yourself to it, then you could make it more successful [viz: some of my ruby projects. I just don't care enough to promote them].

Don't be afraid to spend money (your own personal money, and possibly a kickstarter too?) on it.

Also ideally you should get customer feedback, and meet some niche that people want/demand, if you want to be popular anyway. Maybe in the ideal world people would make money at it?

Note

on 2017 'how do you promote advertise evangelize your open source project' question on Stackoverflow is deleted.

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

Links

See also: