I've said this before, but the biggest takeaway from the balsamiq story seems to be: put your head down and focus on making a great product, everything else will follow.
And market the hell out of it.
The Balsamiq approach to marketing (market the success story) is quite similar to that of 37Signals, actually, and both essential and very effective.
The "build a great product and they will come" myth is bullshit 99% of the time (unless you have a built in marketing engine-- SEO or viral). Balsamiq won the same reason that 37s did (and JoelonSoftware for that matter)... They had a great story, told it well, and the story happened to resonate/be interesting to their exact target market (web geeks / entrepreneurs).
But try to build great software for supply chain management, or managing a beauty parlor and let me know how "everything else will follow" there. There's a reason that SalesForce.com (which, arguably, has/had a great product) has spent 60-70% of their topline on sales and marketing.
1. Make something people
2. Lots of hard work
But, YC is almost always investing in companies that have yet to make anything. Their entire business plan is about trying to predict which founders will have these two qualities.
A secondary reason (or perhaps the true one?) was a sense of reassurance that the source code really did belong to me (not violating anyone else's IP).
They offered 3 times my top license price, straight up. They arranged an international conference call with their IT VP, and two tech guys with me. I think they would have gone much higher. I didn't actually go with this, because I just felt uncomfortable about it.
My opinion: (1). Big US corporations are amazingly terrified of litigation, therefore you can trust a negotiated license; (2). Big US corporations will happily pay much more than you can realistically imagine your product is worth. The inconceivably rich corporations are not like you and me, they evaluate on a different scale, with different values.
I'm actually toying with the idea of shipping the source code to my first game when I release it. The game will be pretty large-scale (it's 3D, as just one example) so the game engine's source code could potentially be very valuable. However, I feel that I shouldn't necessarily keep it closed-source, because the profits from actually selling the game would far outweigh profits from licensing the engine, so it wouldn't be tactically wise to spend time on trying to license the code. Therefore, the closed-source model doesn't really provide a competitive advantage, so why not open-source it?
A potential problem with "open source on launch" is that someone could immediately clone the product and sell it for less. Except they can't. In the case of my game, I'm going to copyright all of the art assets and other game data. To clone the game, they would need to copy and redistribute that game data, which is illegal, which means I could sue them and shut them down. It would be an annoyance, but it doesn't make sense for them to do that anyway, so I doubt many people will try.
Also, piracy isn't a problem for the "open source on launch" model. In the case of desktop products, releasing the source code would allow pirates to easily circumvent any copy protection embedded in your code. But the thing is, it's easy to crack a closed-source program's copy protection anyway. It won't cause additional people to pirate your desktop product. And if your product is server-side, then by definition it can't be pirated.
Lastly, consider this. If it's harmful to open source a propriety application, then there should be examples which support that conclusion. However, can you find just one example of a company that failed or was harmed because they open-sourced their application? Id Software has released the source code to many of their games (Doom, Quake 1, 2, and 3, etc). Quake 3 generated over a billion dollars in revenue, and yet its source code is free to all. And it's very unlikely that Id was hurt by that decision.
It seems like source code protection is one of those logical fallacies that's easy for most people to believe, as long as they don't think about it too much. (Like "the world seems flat, so therefore it must be flat".)
Giving something away -after- it has earned you a billion is less risky than doing it -before- you've earned the money.
Also, one reason that Id's most recent engine (Id Tech 5) is closed and licensed is because of its brand-new technology: MegaTexture. As of now, no other engine has implemented that feature (or the engine isn't production-ready like Id Tech 5 is). So yeah, if you invent paradigm-shifting new technology, then it is probably a bad idea to immediately open-source it. :)
And I think that more or less all their engines have been revolutionary when they were released, not just this one!
A benefit to open sourcing the engine: it would make it possible to become a platform, with other games built on it - and the publicity etc could help you. (Of course, open-sourcing isn't enough to automatically have your platform adopted - you'd have to promote it and work at it. More work!)
BTW: your art assets are copyrighted automatically. You don't have to do anything (in the past this was necessary in some jurisdictions).
The vast majority of companies choose not to open source their products. It's therefore hard to draw conclusions from what happens to those that do. Please forgive me for this parody, it's for illustration purposes only: can you find just one example of a company that failed or was harmed because they exploded a hydrogen bomb in their head office?
balsamiq on piracy: http://news.ycombinator.com/item?id=337821
esr discusses id's decision (near the end) in the section "when to be open, when to be closed": http://www.catb.org/~esr/writings/cathedral-bazaar/magic-cau...
Netscape open-sourced their browser... that didn't work out too well for them (but there were other factors). Several companies are based on open source (Firefox, Red Hat), but it was open source before they came along. Some companies do open source their product, once it's old (your id e.g., there's also ghostscript). Cynwin open source their stuff, but they do it by selling services.
BTW: as the poster you replied to: I began as open source, but switched to closed source. Why? I found it very frustrating and disrespectful when people said they would buy a commercial license (I dual licensed), and then took three months to buy it. I clearly wasn't a priority - they didn't need to do anything; I was dependent on their goodwill. (I wouldn't have minded if they didn't tell me they were going to buy until later - I just found the waiting very difficult. Maybe this is a character defect, or I wouldn't have been affected if I had many many sales going at once... ). Anyone, I switched to closed (at the same time as a complete rewrite that was needed anyway), and immediately started getting several times as many sales.
Open source is tantamount to giving it away for free - make no mistake. (you've said you don't want to give it away for free; and that you don't believe open source necessarily means that - this is just my opinion here) You need a business model that works with that, such as: sell a service/maintenance; sell add-ons/upgrades; advertising (e.g. TV; google; firefox).
Your point about "pay it forward" gestures of goodwill - or just plain doing something worthwhile and good - does not mean you have to give it away for free. If you have created something great, or made something people want, or improved people's quality of life, or made something better, or righted a wrong, or fixed something that was broken, of helped people to do what they need to do - you have done something that is good. It's not just a gesture of goodwill, it's actual good. I think the focus needs to be on making something worthwhile in the first place - price comes afterwards.
I think their are two very basic pricing concerns, with respect to social good: (1). price it low enough so it's worth buying for the values it gives, and it's affordable for anyone who needs it. Too high, and you prevent some good you could have done - you can have different prices for different value given (e.g. per seat, functionality); and for different people (e.g. zero for charities); (2). price it high enough so that it's worth your own investment in doing it, and that you can afford to devote the needed time to it without starving etc (same arguments as above).
Within those two limits, anything goes, including giving it away for free if that helps.
Lastly, an exception: another way of doing good is just by price - Microsoft's DOS was cheaper; PC clones were cheaper than IBMs; web apps are cheaper than desktop apps. Often, a new conception of the whole business can reveal a cheaper way of doing it. These things are good because they make them affordable to more people, for more purposes. I'm not sure on the goodness of making something even cheaper that is already affordable to everyone... I guess it is good, but
not as good as making it cheap enough to be worth buying in the first place; or, more importantly, creating the valuable new thing in the first place. Maybe it's just because I think the latter is exciting and cool.
for one discussion of "be good": http://www.paulgraham.com/good.html
That is probably just the length of time to crank the paperwork through at their end. At some companies, taking only 3 months to buy something is considered quick! I appreciate it was frustrating but I'm sure no disrespect was intended.
However, switching to closed source did fix this problem, and I was still getting sales from large companies.
(I am considering doing this for a password vault app.)
Your argument for open sourcing your product is simply "why not?" rather than "why" :)
But enough generalities. Here are a couple reasons in favor of open-sourcing your project:
- Free bug fixes. If a bug is affecting a number of users, then some users will at least feel like they can do something about it. That is a very tangible benefit because there's no faster way to lose a customer than if they discover they can't use your product for some mostly-trivial reason after they dropped $50. But for desktop apps, it's more likely that a user will just tweak the product slightly to suit them. They might even have fun with it.
- Free marketing. Even though the tech crowd is not nearly as massive as the consumer audience, techies are probably the most valuable type of customer. They will help build a community around your product by answering other users' questions, for example. And what better way to attract people like us than by offering us more control?
That said, the primary reason is to help people. When I was first getting started with programming, it would have helped me tremendously to see how an "industry-strength" game engine worked, for example. I personally like the idea that a novice might cut his time spent on learning down by half or more. All they need are real examples to tweak and to build upon. So if there aren't any reasons to keep source code secret, then I'm going to share it in the hope that it will inspire someone, somewhere. How cool would it be to have access to all of Facebook's source code? And Facebook wouldn't be endangered by that at all, because its value is in its content, not its source code.
I couldn't agree more that it's very beneficial to thoroughly document your code. If you're curious, here's a snippet I wrote yesterday to tokenize a .X geometry file: http://pastebin.com/f74646d17 .... that type of aggressive source-code documentation is how I write all my code. My process is basically to write each function's entire algorithm in English, then to write the actual code. The result is "free" source code documentation. I also don't lose any productivity doing that. Just the opposite... I'm certain that it's more productive to write each function in that way, because I am constantly spotting bugs while writing the pseudocode that I otherwise wouldn't have caught until runtime. It's very easy to "misspeak" in C++. It's not a very good language for communicating concepts. But English is, and so by describing the same concept in both languages, you end up simplifying your ideas more than you would by just "speaking in one language". The result is usually a much simpler algorithm.
Unfortunately, the misconception that "writing comments makes you less productive" combined with the (valid) argument that "good code documents itself" makes this style of writing source code less than popular. But oh well, at least I can benefit from it, and maybe someone else will try it.
That said, the fact that such extensive documentation is necessary (or at the very least nice) suggests to me that you'd be better off using a cleaner, more powerful <http://www.paulgraham.com/power.html>; language that:
(1) documents itself to some degree through more elegant syntax
(2) takes care of low-level tasks that clutter and confuse otherwise clean code (resource allocation, memory management, etc.) and
(3) requires less code to do the same thing, which means fewer lines to document.
There are a bunch of great languages out there that are far more powerful (in terms of abstraction) than C++ or C. Haskell, Lisp, ML, F#, to name just a few. You might consider checking some of these out if you haven't already.
After writing a book about an open-source project, I get a lot of questions by e-mail. My usual answer is "Ask the mailing list."
This is much better for everyone -- the answer becomes google-able, and they can draw from the experience of the entire community, not just me.
Because people cheat. A lot.
First consider that every server-side game state (like a player's position in the game world) can be considered a statistic. So for example, a history of a player's speed at points in time would have certain maximums. (i.e. "players don't usually move at 500MPH. And if they do, they only do so for very short periods of time.")
Therefore, by definition, a cheater is a player whose statistics are significantly different from the norm. A speedhacker could be detected because his max speed would become way above the "typical" maximum player speed over a significant amount of time (like, he begins to run at 500MPH for 2 solid minutes). So we can then boil the problem of detecting cheaters down to evaluating probabilities (which is the same way spam email is identified).
This type of system would also handle the case where there's a game bug that accidentally causes players to run fast -- the system won't accidentally boot everyone, because everyone is now running fast, so therefore that fast movement speed becomes "normal". Now let me point out that the very same thing could be accomplished much more simply by just writing code to boot players when their speed exceeds a certain hard-coded maximum global speed, then being very careful to not introduce a superacceleration bug. However, that's special-case code, which should typically be avoided. It also doesn't take into consideration that a player's speed could legally be significantly accelerated for a short period of time by physics, for example, or for a number of other reasons. The idea is to analyze samples of a number of different game statistics, then boot any player whose maximum statistic value significantly exceeds the normal maximum value over a significant amount of time.
This type of system would prevent a situation where a cheater discovers how to manipulate the timing variables in packets, then tricks the server into thinking he's moving faster than he actually should be. (I believe Counter-Strike: Source is still affected by that particular speedhack problem.) We would also be able to detect and ban players using aimbots, because it is very statistically significant for a player to murder 20 opponents in 10 seconds, for example.
So if people modify the client to cheat, the server will identify and ban them. Godda love probabilities and statistics.
But here's the thing. The goal is not to detect all cheaters. That's not really possible. The goal is to eliminate all seriously disruptive cheaters. For example, the guys who run around with a speedhack plus an aimbot and annihilate every opponent in just a few seconds. That would quickly ruin the game, so those are the most important type of hacks to prevent. And I could just let the community report each offense then ban the cheater afterward, but that doesn't really scale, and at that point the cheater might have already ruined the game for a lot of people. So it would be advantageous to implement a way to detect cheaters realtime.
The server-side anti-cheat code would remain closed-source, so it wouldn't be known which probabilities were being monitored. Other parts of the server code also have to remain closed-source, actually, because otherwise people would be able to examine the game's rules to gain tactical knowledge. (i.e. a player could read the game rules source code to learn where and when creatures will spawn, then that player would go around and camp all the right spots to gain maximum benefit.) However, that's a fundamentally different motivation for keeping the source code closed. At that point, it's not closed because we're worried about the competition; it's closed to ensure that the game will stay enjoyable. So that type of thing doesn't seem like it would go against the spirit of open-source.
Consider this -- if people are cheating by pushing their statistics to the point just before they would get banned, then those cheats don't actually impact other players very much, because the cheater's statistics are still within acceptable ranges. At that point, the cheaters are using the cheats so infrequently that they don't statistically affect gameplay. So in that regard, it isn't necessarily worth the extra effort to stop them, because the goal of enforcing reasonable gameplay statistics has been achieved, so the overall game experience is mostly fine from other players' point of view.
Also, your blog posts are great. Please keep on writing them. One specific part of your writing I'm interested in is this:
"Increasing my effective working memory has an impressively super-linear effect on my problem solving ability, how fast I can learn things, and also how much fun I’m having."
I have working memory problems, so it would be really fantastic to learn how you improved yours. I didn't know it was even possible to do that.
With deliberate practice and the right techniques, people can learn to expand certain areas of short term memory by associating it with other, more solid knowledge. This used to be called 'chunking', but the process seems entirely different. There was a paper (referenced by Ericsson et. al. on expertise) on a group that increased their digit span memory from 7 to 80 in just a few sessions.
Some people (e.g. Ericsson) think that with deliberate practice and effort, experts route around the standard short term memory entirely: in a blink they can remember information just presented to them, in a field that they know about, in the long term. For fields outside their expertise this ability doesn't kick in, however.
"Improving fluid intelligence with training
on working memory"
In many cases, this is true. However, there are many types of software (and, games being on of them) where its not true.
You may be able to see how the graphics are rendered on screen. But without the source code, you have no idea what kind of clever hacks and tricks the author put into the engine to make it work. These kind of things are invaluable and in many cases (like Id software) are what separates their game from others.
Id Software, incidentally, does release the source code to their game engines, but only after enough time has passed that it doesn't make economic sense to license the engine out.
If he can build a community of "experts" that give advice (think rails or django here) regularly and help out new users he can answer this question by pointing to the "exceptional community that exists to help".
(BTW, I don't mind answering, but this is all in my profile).
Just remember, don't overdo it. $100,000 isn't much in the grand scheme of things, so keep pinching those pennies!
If you raise $50m, you don't have $50m - you have negative $50m, because that's $50m of value that you're going to have to create before you've even just returned their base investment to your investors.
Startups are a form of small business; viz. young ones.
Don't worry about competitors. Worry about making something people want.
Constantly improving your product, for what your users want, automatically protects you against competition. I also find that worrying about competitors (instead of customers) can lead to a self-defensive mindset.
If [users] take you up, no competitor can keep you down. http://www.paulgraham.com/startuplessons.html
Holy cow. It's awesome. As soon as some cash frees up in the budget I will splurge for the desktop version.
Most surprising, delightful feature: The guides that appear when dragging stuff around to line it up.
Cleverest feature: The intuitive way that the link bars work. I didn't need to be told that the commas break up the links, just showed in the example. Slick.
Well done, good sir.
It might be a good move to be sure your graphs all report the same information for easy reading, especially when observing trends... either drop the current month, or few a per capita month trend.
Regardless, you certainly are an inspiration, and I wish you continued success! As someone that just needs to design with photoshop and can't work in pen and paper, I'm considering purchasing balsamiq in the future. (It's a little steep for me now) Keep up the good work!
Keep the news coming and congratulations!
Good 'problems' to have though ;)
We starup people cannot compete.
balsamiq is an astounding success in the startup world, and a silly example of how not to do things for internet marketers (who, by the way are the plage!).
Maybe there are millions of people gullible enough to buy most crap internet marketers throw at them, but only a few thousands of us who are interested in the product balsamiq offers. Sad.