Releasing an open source project without getting embarrassed [closed]

Question

I've been working by myself on a fairly large open source project for quite a while and it's nearing the point where I'd like to release it. However, I'm self-taught and I don't really know anyone who could adequately review my project.

A few years ago, I had released a small bit of code which pretty much got ripped apart (in a critical sense) on the forum where I released it. Even though the code worked, the criticism was accurate but brutal. It prompted me to begin searching for best practices for everything and in the end I feel that it made me a much better developer. I've gone over everything in my project so many times trying to make it perfect that I've lost count.

I believe in my project and think it has the potential to help a lot of people and I feel like I've done some cool things in interesting ways with it. Still, because I'm self-taught, I can't help but wonder what gaps exist in my self-education. The way my code was ripped apart last time isn't something I'd like to repeat. I think my two biggest fears with releasing my project that I've poured countless hours into are being absolutely embarrassed because I missed some patently obvious things because of my self-education or, worse, releasing it to the sound of crickets.

Is there anyone who has been in a similar situation? I'm not afraid of constructive criticism, so long as it is constructive and not just a rant on how I screwed up. I know there is a code review site on StackExchange, but it's not really set up for large projects and I didn't feel like the community there is large enough yet to get good feedback if I were to post parts of my project piecemeal (I tried with one file). What can I do to give my project at least some measure of success without getting embarrassed or devestated in the process?

Answer 1

Unless the project is aimed for developers (eg: a development framework, in which case you WANT them to criticize it if it makes you learn even more), you shouldn't worry. But even then, there are many open source projects aimed for developers that are crap, yet people love them because they go to the point (think of Codeigniter, which is very poorly architected, and yet it is the most popular php framework)

If it is an application for regular humans, they will probably only care about the results.

Answer 2

Your code has problems. So does mine. Anybody else answering this question? Their code has problems too.

Unless it's, say, 10 lines or less, it's flawed. Maybe tragically so.

To be a developer is to CONSTANTLY mash yourself up against the limits of your abilities and understanding. It may not be like this for ALL developers, but for me and for the ones I know, we work right at the edge of our competency pretty much at all times. And you face that over and over and over, then have a nice weekend, then come back Monday and do it over and over and over again.

Having worked that life for 15 years, the thing I've settled on is this one fact: You are not your code. You WRITE code. Judgement of the code is NOT judgement of you. Your code has problems, some you know about, some you don't. Having that brought to your attention helps you, unless all you can do about that is feel bad. Feeling bad doesn't improve your code, it just makes you feel bad.

You write your code, and you write it as well as you know how. Maybe tomorrow you'll know more than you did today, but today you did it as well as you knew to. My advice is: write today's code today and tomorrow's code tomorrow. Then have a nice weekend and come back on Monday to write Monday's code.

Answer 3

As a general rule of thumb, open sourced programs have three groups of people who look at the source code.

1. People who are considering modifying the code to make the program work slightly differently for them, to port it to a different platform, or as a jumping-off point for their own programs. If they don't like the code, they typically just won't use the code, and you'll never hear from them.
2. Students, trying to learn how to code in the language you used. These will almost never contact you, but you may occasionally receive an e-mail asking why you did something one way vs. another. (To be fair, I haven't actually had one of these e-mails in many years. I think that web sites like StackExchange may have replaced this interaction)
3. Security researchers, such as the guys at OpenBSD, trying to decide whether your tool is secure enough to be included in their distribution. If it's not, but they do still want to include your program, then they'll be in touch to figure out a way to secure it. (And if your program becomes popular, I imagine that it will probably attract black hat researchers as well, who won't contact you no matter what they find.)

In the real world, people really won't read your source code for any other reason than these, because they simply don't need to. You only got such a volume of feedback before because you posted the code on a forum, which implied that you wanted to receive feedback on the code.

I don't think you really need to worry about a torrent of abuse; the only people likely to contact you at all are people who want to add features or fix bugs, who have already browsed through the codebase and haven't run screaming for the hills. ;)

Answer 4

I really don't get the psychology behind this question... a better question to ask yourself would be "what do I have to lose by releasing this software"

Even if your project is full of code smells, do you have to lose anything?

Even if the code is awful and someone takes the time to write a flame-mail to you, guess what, he probably used your software enough to want to make some changes to it and make it better.

You should be happy about that! Accept the criticism and make your code better, ask the angry guy who took the time to write to you. He cares!

After a while the flame-mails will stop, people will keep using your software, you will have learned from your mistakes and the gaps you didn't know existed in your education will not be there anymore.

I'd much rather work with someone who is willing to do something, admit their mistakes, fix them and keep going than someone who's not willing to do anything.

If you are really not comfortable releasing the software under your name then release it under a nickname. If it succeeds claim it as your own, if not change your nickname :)

Answer 5

I am a firm believer not just in open source, but in open development, where people can see the complete evolution of your code. From hair-brained prototype to working code...you shouldn't ever be embarrassed. You are putting yourself out there - that takes guts. Own it and be proud of it. Nobody is perfect.

Answer 6

The longer I've been in this game, the more I've come to realize that the only measure of code quality is the client experience. If you're writing a function, it's the caller of that function. A library? The devs who write for that library. A framework? The adopters of it. A standalone? The person or daemon who launches the program.

Nice code has its virtue, don't get me wrong- but when it's said and done the only measure is "Does it work?" I've seen plenty of clean code that is a buggy mess, and plenty of satanically deranged code which is completely reliable (plus good clean and bad ugly too :) )

So, if the critics say your code is ugly, who cares. If they say it doesn't work- that's the useful criticism (testing data!) which you seek to improve your program. Hang in there, avoid the internet's population of trolls, and have fun on your project!

Answer 7

I strongly agree with what other posters have said: Even if your code is crappy and not high quality - most people simply don't care. Everyone who has dived into OpenSource code at one time or another may have thought to himself "WTF happened here".

But I don't know anyone out there with the motivation to criticize the codebase of a project just for the sake of saying "dude, your code looks awful!". We've all been there and we all know that any code we're writing right now will seem pretty lame for ourselves in only a few feeks (mine definitely will).

So don't worry that much - people simply have a lot better to do in their spare time than nitpicking on the code of OpenSource projects.

Answer 8

Real code is always rotting and dirty, slapped together and maintained in an approximately ad hoc fashion. Cleanup is limited to documenting special cases and special constants. There is an impedance mismatch between clean code and the real world.

I also have noticed that any competent engineer can tear someone else's code apart.

If (1) it passes tests and gets the purpose done without failing AND (2) you can make minor changes with only minor rewrite, it's good code.

Answer 9

Some wise words from Reid Hoffman, co-founder of LinkedIn:

“If you’re not embarrassed by your first product release, you’ve released too late.”

“Getting engagement with members and seeing what is actually important is completely key… So you get out the minimum viable product as soon as you can.”

I think this especially applies to open source projects where having a great idea with a promising start encourages people to contribute and participate. Something that's so polished it makes you put on your sunglasses might not evoke such feelings. But the most important thing about releasing early is to shatter all your preconceptions about what should be done and start moving in the right direction.

Answer 10

Who are you? Are you someone whom people know as the God programmer, and worries that your reputation will come down? Are you the one who is going to apply for the job and worries that the employer may read these criticism, and think that you are bad programmer? What I am asking is why are you afraid of criticism about how you screw up. You get to decide which are genuine comments and which are rants. Take the good ones as defects and fix them in next version. I am just feeling that you are worrying unnecessary about the criticism. You are helping the open source community, that itself is a very good cause. Please keep up the good work.

Answer 11

If you are genuinely worried, simply use an online pseudonym when releasing the software. Then there is no way it will impact on your real-life reputation.

When/If you do receive public criticism, that'll lead to improvements in the code and will help you grow as a developer. That is a good thing.

I find that for my projects most constructive criticism/suggestions are sent privately rather than broadcast publicly, and even then you'll be unlikely to receive a flood of comments. Therefore, I recommend to just go for it!

Good luck.

Answer 12

There is nothing wrong with self-study in and of itself. You can't be isolated and peer code reviews can help with that.

You also need to focus on what you are doing. Why do you care if you get negative feedback on your work? If it's because you are making the assumption that if you get criticism it's because the code is bad or you aren't any good at programming, that may or may not be true.

The purpose of the effort is to make sure the code works and to get the best code out as possible, but from practical experience, not all the commericial code out there is stellar either. Sometimes you get bad requirements, sometimes you don't have time to do it right. Sometimes developers want to come across as a genius by making others look bad.

I don't believe you can learn without making some mistakes, especially if it's something that takes real discipline and effort. If it was easy, everyone would be doing it. Just try to limit mistakes to minor ones, using established best practices. I realize that isn't always possible!

If I worried about what others thought of me as a programmer, I wouldn't have gone into the field in the first place. That being said, my first take at criticism of the code is, try to take it objectively and learn from it.