feed"Release Early..." vs "...First Impression"
Two phrases I've heard many times have been bubbling up in my head lately: "release early and release often" and "you never get a second chance to make a first impression". They don't seem compatible.
I've been accumulating JavaScript code to create a set of general-purpose JavaScript modules as part of a project called xjs. There is a base JavaScript shell module, a unit testing module, logging module, PostgreSQL module, web server modules, the Synergy web framework module, a partial sample blog app module, and others. These modules are all very young and need work and features but it seems the code has crossed an important threshold. There is enough code that it is now possible to work on refining one module independent of others. The whole system stands up and supports itself while I'm off improving little pieces here and there. All of the current code may end up being replaced eventually but the ability to work on pieces independently feels like a great advance.
My plan is to release this code soon-ish as alpha software and hopefully others will be interested in using and contributing to either the existing modules, creating new modules, or creating some infrastructure. The fact that the system works in a basic sense means others could start modifying pieces of code as the high-level module architecture is good enough.
If the code is released early then the code can be picked over by more folks than just me at my desk. As far as the shell and Synergy modules go, I know I've made some decisions that I really like and have wanted in a JavaScript shell and web framework for quite a while. There are other areas where someone else might be able to make a better decision because they have dealt with a particular problem before.
If the code is released too alpha then even though it is labeled alpha the whiners could spread a bad reputation that is hard to overcome. Ruby on Rails didn't do this. I think I was introduced to Rails only a few months after it was released. It had the famous "build a blog in 15 minutes" video and was quite a complete package of software ready to go. Popularity and a sustainable community followed resulting in a popularity rise of Ruby. I'd like to see a similar popularity rise for JavaScript outside the browser but maybe you only get one chance.
So is it "release early and release often" or "you never get a second chance to make a first impression"?
Comments
Have something to write? Comment on this article.
Release early and often.
BS on "you never get a chance to make a first impression". We're talking about software here, not life-partners.
If some particular project does end up making a poor impression, then just stop working on it, and start a new project. You get a whole new chance to make a first impression!!!
I'm thinking long and hard about an idea I want to pursue. When I get to development stage, I plan to release early. I do think it depends on the audience however as to which is the best approach. If you were doing physics, you might want to have solid evidence first. That however shouldn't stop you discussing your ideas and getting feedback. I disagree with Andrew here unless being open and dealing with feedback distract you from the problem your trying to solve.
Online... especially with frameworks, there's so much competition - I don't believe releasing late is an option for most people. I'll often have to revisit novel concepts to let their meaning sink in. Having something that out of the gate is polished enough for others to grasp early is beneficial. It's getting the /idea/ across that comes across as important to me there. Implementation comes in time. Community comes from seeding the idea, fostering it, and following up with the implementation.
I wouldn't worry about bad reviews, only how you handle them. You only need one person with influence to give you a favourable review, to see the value in your work for others to pick up on it, to then follow the power law and become viral.
I'm seeing more people talking about JavaScript on the server. I'd be releasing as soon as you can to get those early adopters in. Seeded with your own unique philosophy to differentiate yourself from other frameworks as well. I'm sure if someone came up with a Concurrent JavaScript on the server, it'd be all the rage. :)
I think the "you never get a second chance to make a first impression" is VERY important. However, it totally depends on what type of software you are releasing.
In my case, I was working on a 100% JavaScript web game, World of Solitaire (http://worldofsolitaire.com). I had it fully playable a good month before releasing the first version to the public. I spent that month polishing it up and removing anything at all annoying in it. I knew that if I didn't make a good first impression, many people would never ever try it again, no matter how good it got. I don't believe it's this way just for games. I imagine other consumer targeted applications would also fall into this category.
In your case, your working on a development platform. Your target audience isn't an 'average consumer' but rather a geek. A programming one at that. With that target I feel it's okay to release a earlier with less polish, as long as you feel what you have would truly excite some developers and they would use it. However don't underestimate documentation in your case. Having some good documentation or tutorials will go a long way in making a good first impression. It'll show that you care enough about the longevity of what your creating and the developers that will adopt it that you bothered spending time creating docs.
Anyways, just my thoughts :)
They're both equally important.
You shouldn't release something that doesn't work.
You also shouldn't sit on something forever.
Basically, you have one chance with your first release to MAKE an impression - so that's when you go over the details about "it's not perfect, future releases, beta, version .1, blah blah, etc. etc." It's your marketing tactics (or lack thereof) that creates the "sell" or "impression."
After that, it's a matter of fixing it in a timely fashion. Don't make promises that can't be kept, but also don't kill yourself in making them.
There's so much fuzzy pseudo logic in it, that it's best to release when you're so damned uncomfortable about it, just so someone can say "hey, there's a typo." :)
Have something to write? Comment on this article.
I think it partly depends on your approach to marketing. Google released maps when they still considered it "beta" software. But, the didn't market the hell out of it either, preferring to refine it while the early adopters acted as free beta testers.
There are certainly advantages to getting other hands in the mix. Perhaps you put it up on Google Code or Github, but don't blog about it, just invite a few people to help you out as they can. At some point, word will get out, of course, but hopefully with a favourable review.