The MicroISV Show #10 - Joel Spolsky

The MicroISV Show (Audio) - Channel 9

Joining Michael Lehman as co-host of The MicroISV Show is Bob Walsh, Managing Director of Safari Software (www.safarisoftware.com), author of "MicroISV: From Vision to Reality", author of the soon to be published "Clear Blogging", and proprietor of 3 websites which are useful to the MicroISV community: www.mymicroisv.com, www.todoorelse.com and www.clearblogging.com.
In this first collaboration, Michael and Bob interview former MicroISV and successful software entrepreneur, Joel Spolsky (http://www.joelonsoftware.com/AboutMe.html), co-founder of Fog Creek software, prolific blogger and host of the Joel on Software forums including one on the Business of Software (http://discuss.joelonsoftware.com/?biz) on which many MicroISVs ask and answer critical questions about starting and staying in the software business. Bob Walsh along with Eric Sink are the "hosts" of the BoS forum.
In the interview, Joel talks about his experiences as an ISV, Fog Creek's CoPilot 2.0 application and ends with what he thinks are the two most important things every MicroISV should know.
UPDATE: Transcript of the show:

[music]

Michael Lehman: Hello and welcome to the MicroISV Show here on Channel 9. I am your host Michael Lehman, Technical Evangelist for the Microsoft Corporation, specializing in micro-ISVs. Today on the MicroISV show we are starting a whole new format. The beginning of this new format is I would like to announce that I am now going to have a co-host. My co-host will be Bob Walsh, Managing Director of Safari Software, and author of the book, "Micro-ISV From Vision to Reality."
Bob, would you like to give our listeners a one-minute introduction to who you are?

Bob Walsh: Sure. I am a micro-ISV running a company called Safari Software, Inc. I basically do two things. I write and that can be in the form of books and blogs, and I write code in the form of applications. I have done about 20 odd years of contract programming but my main focus now is my micro-ISV. It has one product out right now called Master List Professional.
On the right hand side of things, you will find me at three different blogs, mymicroisv.com is the first one. It is a blog and resource for micro-ISV with lots of good guest posts from people who actually know what they are talking about. My second blog is todoorelse.com, and that's where I get into things like David Allen's Getting Things Done and online productivity.
And finally I have started a new blog called clearblogging.com, and I have a book out in a couple of weeks by Apres by the same title. That is a book about everything you need to know to successfully start blogging or to improve the blogging you have got right now.
I am hoping that with this show, working with Michael we can get to some of the people out there who really have useful information for micro ISVs, be they micro ISVs, be they huge vendors, be they people in any name, weight, shape or form out there. So we are going to be expanding the focus of this show not just interviewing micro ISVs, but interviewing people from all sorts of companies, all walks of life who can provide information and experience and wisdom. Stuff you can't get out of a book or out of a tech proposal for micro ISVs. My hope is that we can come across enough information in this podcast to really make your micro-ISV succeed.

Michael: Perfect. Without further ado I would like to welcome Joel Spolsky to the program, and Bob, take it away.

Bob: If you have been programming under a rock for the last few years, you don't know who Joel Spolsky is, Joel Spolsky is the driving force behind Fog Creek Software, which is known for several products, specially FogBugz, an excellent bug tracking and feature tracking online application, as well as joelonsoftware, which is one of the most read developer blogs, I think, out there in the world. So how many people now read joelonsoftware in a month?

Joel Spolsky: Now at least 50, well, maybe a little bit more than that. [laughs] I don't really know. [laughs] I have stopped counting.

Bob: OK. The last numbers I had heard were pretty significant, something on the order of 4-500,000 unique visitors a month.

Joel: Well OK, it is probably more than that. Just the job section - that's the only place I track it because that is the place where we charge for advertising to list jobs - the job section is over 700,000 unique visitors per 21 days. That's how long an ad runs for. So probably a little bit more than that per month and that really is only a section of joelonsoftware. So I don't I think it would be exaggerating to say that there is at least a million a month.

Bob: OK. So Joel's been talking to the developer community for a long, long time. Joel started out with his partner, Michael... I am always getting his last name spelled wrong.

Joel: Pryor. Michael Pryor.

Bob: Michael Pryor. They were what we would call today a micro-ISV but obviously Joel's and Fog Creek Software have graduated to bigger and better. How employees now at Fog Creek?

Joel: About a dozen. We usually have large numbers of interns. We have some more interns coming back this summer. We will probably have about 24 all told in June. Not quite micro but still mini.

Bob: OK. What are the things that some of those interns did a couple of years ago was Copilot. Maybe the best thing to do is, can you tell me a little bit about what Copilot is and who is it for?

Joel: Sure. Well it started out - I guess I will tell a story - which is that when we... Our main product is FogBugz. FogBugz is a product that our clients install on the server. Everybody's server is a little bit different and so even though we have a pretty good setup, we wind up having to diagnose their problems quite a bit. We found that it is much easier when you can use some kind of remote desktop kind of application. Terminal server is a remote desktop that comes with Windows or VNC.
The trouble is 99.9% of the time, both parties, both the helper and the helped party are behind some kind of firewall. So a regular traditional VNC-type program won't work. So we had all kinds of things that we kept trying to do. We had a server setup outside the firewall on our side, where we tried to get our customers hooked in through that. What we found is that just getting our customers to install and run VNC, even with a fairly technical customer who actually knew what VNC was and how it worked, would take about 15 minutes on the phone. This was rather frustrating so we didn't bother doing it.
Then it occurred to us, "Gosh, we can have a little script that just installed VNC for them and set it up and open the appropriate holes in the firewall and various things." We had some summer interns coming down the pipeline, so I thought lets stick one of those interns and we will have him write some sort of script and then we will be able to do our remote desktop support that much easier.
Somehow that sort of expanded into, let's take all the interns and let's make a from scratch program, a custom version of VNC. Fortunately it is open source, so this is possible as long as whatever changes you make go back into the product. So that's what they did. It became a standalone executable that configures itself completely and that doesn't require setup steps. It doesn't leave files around the helper or the helped person's computer. We did just about everything we could think of to make it really simple to use.
Our initial target market... The truth is the target was people like us, other software companies trying to help their customers with their product with a remote desktop-type situation that would be a very secure, all SSL secured and so forth, 128-bit, and not leave anything around on any computer that could later be used as a hacking target or something like that. Also very, very simple, very, very easy to use. Basically the instructions are, go to copilot.com and type in this 12-digit number, download and run the program that you find there, and that's it. So the 12-digit number is the probably the hardest part of that. We are working on it.

Bob: You mentioned in your post when you announced Copilot 2.0, that one of the reasons you were able to accomplish so much with those interns, was that you used open source software as the starting point. I want to know that a little further. So really your product is a total sort of a hybrid, part of it is open source, at the desktop, and part of it is proprietary, the backend server code. What do you think of that as a model for micro-ISVs?

Joel: The model is really not so much some open source software and some not open source software. It is not the fact that we have that software on the server - because it doesn't do very much, it handles billing and it is what we call a reflector, which means that in order to get through the firewalls we have to have both parties that need to communicate connect outwards. Where they connect outwards to, is our server and our server basically just passes traffic between them once they both get connected. That is a very, very trivial thing that the first intern wrote in the first two days. Then there is some backend billing and subscription services. Basically what we feel like we are charging for, is the support and just the fact that it works and you don't have to do anything to get it working. Not really a software component. So there is an awful lot of open source software models that are built on the, "what we are charging for is service and not necessarily the best", and that is pretty much our model as well for Copilot at least.

Bob: Does that leave Copilot vulnerable to, let's say some big company walk in and take a look at the GPL code that you have got out there and say, "Well, we are bigger and better and we would have it out there today."

Joel: Yup. No, please don't. Yes, but they could have done that before we created this product and they didn't. Actually I am not that... There is a few issues here. One is that it doesn't really worry me that much. I believe that there is lot more to it than a brand around service, support and just awareness, than the actual do you have the bits that cause this thing to work. The reason I learnt that is, over the years, when we first released FogBugz bug tracking software about 2000, a bunch of clones started springing up. I should say about FogBugz we do distribute the source code for our customers' convenience but they are not really allowed to resell it. It is not open source in that sense of the word. For their convenience they are allowed to look into source code, modify it in-house. They are certainly not allowed to sell it.
But over the years, at this point, probably seven or eight Fogbugz clones have popped up all over the world. None of them has two million sales. We look at them and sort of giggle. They are cloning the wrong thing. They have cloned the FogBugz application itself, but they haven't cloned any of our knowledge of how bug tracking works, how the software development process works. They haven't got a website that has a million unique visitors per month. They don't have any of that kind of stuff. So realistically we are just not that worried about people cloning the actual software.
I mean, you can if you want to. You are welcome to go to the Copilot website, go to FAQ page, you can download all the source code, and you can build a service just like Copilot yourself. That will take you a few weeks and then you are going to have to get people to find out about it and provide them with a high level of support. By the time you have done all that, you realize that you are not making quite as much money as we are. [laughs] We are also probably not offering you a...

Bob: Or you may, as you had hoped, ripped off somebody's code. You know, I kind of wonder here the lesson you pass on to micro-ISVs is not to be as paranoid and obsessed if their applications get cracked or people copy their code. They need to focus on the non-code parts of what they are doing.

Joel: Yes. I don't know what the ratio is right now, software developers to non-software developers at a company like Microsoft. In the years that I worked in Microsoft many, many years ago, I believed that it was about 10:1 non-coders to coders. Maybe it was 5:1. But that number is only getting increased. So, when you think about it, in a functioning software company, probably 80% of their effort, maybe 80% of their spending is devoted to things other than creating the code, the bits that run on people's computers. That is really important to keep in mind, that this is not the be all and everything else is actually a little bit more important.

Bob: It sounds like you have been getting to the real point there, is that for a micro-ISV which is a one to five people self-funded effort, the majority of their efforts, the majority of their time ought to be spent on things other than the code base.

Joel: Probably about half of it, at least. In the start-up phases, somebody has to figuring where the customers are going to come from and how to get the customers. Otherwise it is just not going to work. You are writing code in a garage and doing nothing else, the code will never - nobody will ever find out about the code. Unless of course you invent the code that cures cancer and that would be great. People then probably would beat a path to your garage. But that happens about two out of three times.
Even there are two or three times in the history of software, Google maybe. But even in the early days of Google, I am sure they were out there trying to get people to find out about their product and try it out. So it is the marketing, it is the awareness, then it is the support for your customers that makes them elated and makes them tell other people about the product. All of those things are really the crucial component. And the software, not so much.

Bob: OK. Let me ask you, first there was CityDesk which was a VB6 application for design and templating websites. And if I understand correctly, what happened is FogBugz grew out of your in-house efforts to support that product.

Joel: Well actually, no. CityDesk was second. Here is the history. The history is that there was a vision. The original vision for the software at Fog Creek was a complete software management system that would have a client component, a server component and a workflow component. The workflow component was going to be FogBugz. Basically this way of telling people they need to work on something in the content management system, whether there is bug in the system, or a page that needs to be fixed, and all of the workflow. The workflow engine you might imagine around, say, journalists working on putting a website together.
The client component was CityDesk. It was going to be Windows based because the idea was people knew how to use wordprocessors. That provided theoretically a vastly superior and richer interface than a big old edit box on a web page. Turns out not to be true. The server component never shipped. It never became a product. What really happened is that FogBugz shipped first because we had it first and it actually grew and was very, very popular. Interestingly the people who rejoin software are the most likely people who need or use or want, bug tracking or project management and all the things that FogBugz does well. So that kind of became a hit on the strength of the fact that there was an audience that we had, both at fogcreek and joelonsoftware, we had this audience, of people that theoretically would be interested in FogBugz.
But that audience wasn't that interested in content management. Content management from various reasons I have discovered is not actually a good product category. So that sort of failed. So CityDesk is now, I would say, highly de-emphasized, We are not really developing it anymore but we continue to support it, because we are fanatical about support. Fronts fine on this stuff. But we are not really going to continue developing that because it is too small a market compare to other products.

Bob: Is this a statement more about how things worked out for Fog Creek or is it a statement that you are really weighing on the desktop versus the web-app argument here?

Joel: I am willing to weigh in on the desktop versus web-app argument here. I don't think there is pretty much anything left that needs to be a desktop app. Unless you need to interface with hardware that you don't have access to through the web. Even then most people will build web applications that talk to a very small proprietary component, that is the...

Bob: I understand. Your post's headline for this is, "Joel says desktop is dead"?

Joel: Yeah. I think so. [laughs] I very much changed my opinion just because we saw that people weren't that interested in the issue. Some people were and there is definitely a community of people that love the CityDesk idea of desktop-based content management. We kept saying nobody wants to edit in a big old textbox and use that as a day-to-day editor. It is so awful compared to Microsoft Word, or compared to the rich GUI desktop experience. Then we saw that most people are perfectly happy to use web-based email. Almost everyone is completely happy using web-based email as their primary email interface. Even people who have Exchange server and Outlook available to them are more than happy to use GMail and often prefer it.
So it has finally gone into my head that all the things that I consider to be part of the superior desktop experience are just not that important to the mass audience.

Bob: Hmm. I quite disagree with you, but I have to say that you have got a lot more experience with this than I do.

Joel: I will think long before I am happy to go wrong again. I will probably flip-flop on this particular issue couple of more times. Right now I really can't see building anything other than as a web-based app. Look at CityDesk, for example. it is all driven through the web, but there does have to be a Windows-based component to it - sorry, a desktop-based component to it, we have not only Windows now. Similarly Skype needs something on the client. But I am pretty sure that if you actually look at Skype - and I don't quite know how it is architected - but I am pretty sure that there is HTML as a pretty significant component of the technology that they used to build their desktop app. Even if you are building a desktop app - or look at QuickBooks, the quintessential desktop app, large swathes of that now are implemented in the form of HTML that is hosted by IE inside QuickBooks.

Bob: So maybe that this is really not the argument any more about having a desktop app that doesn't communicate through the Internet. Any application has got to be Internet-connected and Internet-centric.

Joel: Yes, almost any - except for very specific vertical needs - that's true. The way you can see that is think about word-processing, and how much of your word-processing you do in your email program, whatever that may be. How much of that you do in your blogging program, whatever that may be, and where is it actually that you have to bust out Word for Windows, and actually type a letter because you need to print something to send to the local division of jurors to try to get out of jury duty, or something, that doesn't have email yet.

Michael: The interesting thing to that, to take your discussion, is that when most people use web-based things, the underlying technology in the browser is still actually using either the rich textbox function that's built in to the OS, or the runtime library or they are actually sometimes using Microsoft Word components under the hood, without actually busting out Word as a separate application. I think more and more - just to add my 2c of this discussion, that all of the things are indeed becoming hosting containers. Part of my evangelism program is to release the whole project glide path and as part of that, not only are there inside Visual Studio, now there are custom dialog boxes, now there are a variety of web browser components used in critical places both for local content as well as content on the web. So it is becoming more and more blurred.
But as you said, we can have the discussion about whether the desktop is dead or not long into the night. But it is interesting to hear your opinion on that.

Joel: It is a little bit premature to say quite that. What I would say, however, is that if anybody came up to me and said they were going to build an application of a particular sort and I could not really see any need for it to do anything, maybe let's say, hardware specific or performance specific that really needed to be a desktop application, I don't see any reason it shouldn't be built as a web application at this point. Something like, let's say you are going to build QuickBooks today, you would definitely build that as a web application. There is no question that the benefits that you get for having the web application greatly outweigh the slightly reduced quality of these interfaces that you can build. Which is increasingly less and less true thanks to Ajax and so on and so forth. It's not really true any more that you can't build a web...

Bob: Yes. But I think it is going to be a long, long time down the road before we see Photoshop as a web service.

Joel: Well, but don't forget that... Photoshop, maybe. Then again, what 80% of people do with pictures is going to be scaling and rotating and fixing colours and stuff like that. Applications like Flickr or Picassa, that can actually do really neat things with those photos. I guess this podcast is a desktop app, right. Applications that - it is not so interesting to say what you are doing in Photoshop, it is more interesting how you are getting those digital pictures out and distributing to your friends, A couple of short editing stages between the camera and putting it up on the web, and those are the kind of things that can be done easily with web applications and probably relatively elegantly. A full application for a designer who sits there all day long manipulating digital images, I am sure Photoshop still has a space on the desktop.

Bob: When you look at the most successful web applications, a big component of that success is the online communities that have sprung up around the applications. As a matter of fact some of these applications are nothing but the community. I guess what I should ask you is, if you are going to start out from tomorrow as a micro-ISV, you can pick the proverbial graphics, photography application you talked about...

Joel: Yeah...

Bob: How much time and effort would you put into building the community, versus just building the code base?

Joel: That's a good question. The community may be... Well, the community will create itself as long as you get the parameters right. And as long as you've done the right things so as not to drive people away, the community will probably build itself, if the chemistry is created correctly. So, there it's just a matter of fine tuning it and hitting it off.
You may... The answer to that question sort of depends on how you plan to market your product. Community is often used as a way to distribute and market a product. Take Slicker for example, where its community features were pretty much crucial to ensure that there would be a reason for people to tell other people about Slicker , and, thus, market it in that that way.
In our case, in the case of, for example, FogBugz, have have more of a broadcast thing with Joel on Software than a community thing. Although there are discussion forums, probably only five percent of the people that ever pass through Joel on Software will stop by the discussion forum and the community features. Mostly, it's just kind of a broadcast media sort of thing. And that's okay, too.
So the real question is "how are people going to find out about your product and tell other people about your product?", and a community is one way of building that into your product itself. Making your product what we used to call viral, giving it some reason for people to tell other people about it. There are ways of doing that without necessarily building it into your product. If your product is remarkable in the Seth Godon sense, remarkable meaning it's the kind of thing you might want to remark about because it's interesting in some particular way, then people talk about it even if it doesn't have its own community mechanism built in. If you already have a platform or a gigantic marketing infrastructure like Microsoft then it's a lot less important to try to build communities.

Bob: Well, let me ask you a favorite question of mine, which is should micro-ISVs blog and if so, when and why?

Joel: That's a good question. I used to sort of say, I mean - there's no question that I blog to joelonsoftware - I used to deny that it was a blog. It's not really a blog it's more of a place where... There's no question that through that I've managed to build up an audience who also then hear about FogBuggs and Copilot and buy those products, or at least check them out.
Really, my entire goal with it was an educational one as there's certain things I have learned about software development and I wanted to spread the word. Even from the most selfish perspective so that I never again have to take a job at a company that doesn't know how to do these things.
Right. But more importantly joelonsoftware definitely predated Fog Creek.
And I was writing those articles long before FogBuggs or Copilot.
There's this sort of skeptical view that I'm just doing this in order to sell the products and that can be fairly trivially disproven by the fact that I was doing joelonsoftware before I was trying to sell products.
One of the books came out - "UI for Programmers" - actually predated selling any products. To answer your question, though, should people blog, it sort of depends. It's been very successful for me and it's been very successful for other companies I can think of like 37 Singles.
On the other hand I've seen an awful lot of blogs come across as either tone deaf or not authentic. A good example might be Jonathan Schwartz where there's a strong feeling that everything is censored by a PR department very heavily and everything is a little bit too mark on happy smiley. It doesn't sound like something Jonathan Schwartz would necessarily say. Those are probably not very helpful.
There are also people who if you're a micro-ISV and you're just sort of a really good developer and you craft view beautiful software it may be you're maybe not such a good writer and blogging might be out waste of time. If you're not going to get a readership you should probably have a blog at least to keep people up to date on what you're doing. If you're not going to really have something important to say and that people want to read independent of what you're working on and write it well, then you're not that likely to build up a body and it's not going to be a good marketing mechanism for you.

Bob: OK, Michael any last questions?

Michael: Yeah, Joel I would say that as part of what we are trying to do with the micro-ISV show to help micro-ISV's figure out what it is they need to be doing to be successful. I liked your comment about how we need to be spending 50% or even more of their time at least post development cycle thinking about their business. If you could pick one tip based on your experience in going from zero to hero, what would be the thing you would tell yourself from five years ago if you could give yourself a piece of advice now to be the one thing not to miss - the one thing you should do.

Joel: Can I have two things?

Bob: You can have two things.

Joel: The number one thing is a micro-ISV shouldn't be one person, it should be two people at the very least and one of them should have the business and marketing and sales skills experience. The other one should have the tech skills and the programming and the inventing the product type of skills. That kind of partnership is far more likely to be successful than the individual working alone just because people don't usually have both of those skill sets and so they really need to all be covered.
Or if you have only the sales and marketing you're not going to be to be successful because you won't have a good product and if you don't have product development skills you won't be successful because no one will hear about you and the business side won't really work. Having two people, I feel, is crucial just to validate your idea, almost to keep each other motivated, bounce ideas off each other and so on - that sort of thing.
The first part is the minimum size for a micro-ISV that can go anywhere beyond a fun project.
The second part, and Bob alluded to this earlier, which is my prototypical example of the photo gallery which is probably nine million micro-ISVs have made an application where it's like "Hey, everybody's got these digital cameras my application lets you upload all your pictures and put them on the web and make web galleries." There have been about a million of these and a very tiny number of them have been successful and the vast majority of them have been instant flops. For some reason this is an incredibly appealing idea for software developers to do, maybe because they feel like they know how to do everything, all the steps they're going to need to do to write the code to make this work, but for some reason they never really make it work.
But what I've always told these people time and time again, and they never listen to me, is instead of making the generic "upload your pictures application" take a very, very small niche audience - wedding photographers - and make the ultimate application for wedding photographers. Find out exactly what wedding photographers need. There's a lot of money around wedding photographers, they get paid an awful lot of money, and figure out exactly what their workflow is. If you need to find wedding photographers because they're in the yellow pages and there are directories of these things. Call them all and find out what they want and try to sell them your solution.
And so what I always tell micro-ISVs is, and that's just an illustrative picture, try to narrow your potential audience almost as much as possible to get started. In order to bootstrap you're going to have to find a very small initial audience you can serve extremely well of people who all speak to each other. One you can find all in one place, where there's money being spent because you're going to need to get a part of it for this thing to work. And once you find that very narrow niche, that's the way you get bootstrapped and you can think about crossing the chasm as Jeffrey Morris says into other kinds of industries and other kinds of larger markets. But you really need to pick something vertical to start with.

Bob: OK I think that's it for today's show.

Joel: Great.

Michael: All right Joel, thank you very much for coming on the micro-ISV show and if people want to go and find out more about you and your products and so forth what's the best web address for them to go to.

Joel: Tell them to go to joelonsoftware.com. That's my personal web page and there's links to all kinds of groovy stuff down the side. If it's your first time at joelonsoftware you can start with the little sidebar and just read through that; there's links to all kinds of past stuff and that will bring you up to date. On the main section of joelonsoftware are things that I post about once a week.

Michael: All right. Sounds great, all right. Thank you very much Joel Spolsky for coming on the micro-ISV show today and as always the views expressed by our guests are not necessarily those of the Microsoft Corporation or the hosts but they are respected views of our respected guests and we enjoy bringing them to you. Bob, do you have any closing words?

Bob: If people are out there listening to this podcast know of someone that we should interview please contact me or Michael at our respective. Email and let us know we really are looking for people out there to interview that can bring value to the micro-ISV community.

Michael: Thank you Bob through joining the show as a co-host. I think this show is a great opening for our new venture and I'm looking forward to future shows. As always check back here next week for our next edition of the micro-ISV show here at channel9.msdn.com.
[music]