You’ve done it: you’ve taken your own personal utility, library, or web application and placed it on GitHub as free and open source software for all the world to see.

Maybe you wrote this software to fill a personal need, or maybe you’ve always hoped that it would reach more people. One thing’s certain: it’s always been yours, and yours alone—but the moment you pushed that code for the first time, your baby left the nest. What comes next is up to you.

You can choose to never touch this code again. Even this can be of great help to other developers. But if you want to reach a wider audience you’re going to need to cultivate a community around your open source project. This requires a great deal of skills that don’t always come naturally. It’s not enough to be a great developer, if you can’t communicate well. Conversely, a charismatic personality won’t do you much good with those who respect code above all else. And if you somehow manage to luck into the right balance of the two, you might just burn out quickly if you don’t learn to take some responsibilities off of your plate and put them in the hands of your capable community.

Embrace your contributors

There it is—your first pull request. This is an exciting moment: a complete stranger has used your code, and liked it so much they’ve fixed a small issue with it, or even added something new. You eagerly accept that pull request, and your library or application becomes just a little bit better. But the reports keep coming in: bugs, feature requests, and unconfirmed reports of random incompatibilities. Some of these are valid, but a great number of them are completely irrelevant to what you consider your software’s goals.

When the volume increases, it can be difficult to find the time or desire to respond to each one. But that would be a mistake: keeping an open source project alive in the beginning means giving a response to everyone, even if that response is a quick explanation as to why you won’t either fix what is being reported or adopt the particular feature in question.

Exercise impulse control

This transition can be a little bumpy. An endless stream of bug reports and negative feedback can be pretty dispiriting, and it can lead even the best of us to become grumpy and frustrated. You must recognize this. You might be looking at the 50th bug report today, but it may be the first ever submitted by this particular person. If you take out your frustrations on them, you may have alienated a helpful contributor who, in turn, could spread tales of your bad attitude across the web.

Stay calm and react appropriately, and you may have an open source ally for life.

You certainly don’t have to do this. Some very popular open source project leaders exhibit an notoriously uncompromising demeanor. I myself have certainly not always been perfect. I do find, however, that a little empathy goes a long way.

Accept your limitations

As you get more and more feedback, you might find people offering to take over things that you’ve historically controlled. For example, when we added the ability to run concrete5 in multiple languages, we started receiving a large amount of feedback on the way that worked, and some of the limitations around what we had done in that regard. I was so proud of getting a diverse community of developers using concrete5 in multiple languages that I was reluctant to accept this feedback.

It was a point of pride.

And, this was stupid. The people giving this feedback were non-English speakers actually using my software in the way that I had hoped, and finding ways that it fell short. They were asking to help, and provide real measurable improvements to the way it worked. By realizing that they were always going to be more knowledgable on this subject than I, I was able to delegate responsibility for all aspects of concrete5’s internationalization to this group of developers. The result is a system that is much more complete, because it’s actually being developed by those with specific experience in that particular area.

Once you can give up this impulse for control, you’ll find it liberating: suddenly, you get to work on the things that you want to work on, rather than simply having to work on on everything.

Eat your own dog food

Ok, you’ve done it. You’ve given up total control of your project. It’s flourishing, but you find yourself doing much more planning, wrangling, and communicating than developing. In fact, the better your project does, the more removed from it you feel.

This can be a dangerous time.

You created this project because you wanted to solve a problem. If you don’t continue to use it for its intended purpose, you won’t know where its most painful points lie. You won’t see where it could use improvement. It’s fine to give up control of your project, but you still have to use it. Don’t relegate yourself to email, Slack, and IRC: stay active and engaged as a user of your software.

Trust your gut

Staying active as a user enables you to trust your gut. You may get to the point where much of the active development on your project is done by other people. This is awesome! It means you’ve become a cultivator of talent, and that your project is thriving. But even at this level, as you see new development taking place in your project, don’t be afraid to step in and exercise leadership when the direction of a fix or feature doesn’t make sense to you.

It was your vision that got your project to where it is today, so don’t lose sight of that.