Fog Creek Software
Discussion Board




Franchising Your Code

In this thread, http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=27673&ixReplies=5 , Wayne suggests porting FogBUGZ to Perl to make it platform agnostic and increase its platform availability.  Joel replies that the cost/benefit analysis doesn't support the effort (as he's said many times before in his explanations of why he doesn't port to Macs).  This makes perfect business sense.

However, that doesn't mean a deal can't be made: franchise the code.  Give someone like Wayne access to the code with an NDA, and let him port it; in exchange, Wayne gets his port and a residual percentage of sales of the product for that platform.  Joel gets to specify in the contract functional and code quality to ensure that the FogBUGZ name isn't damaged by a bad port.  There's no cost to Joel except the administration of the deal, and he receives a slightly diminished share of the profits on a product he wasn't going to develop anyway.

It's not as simple as agreeing to something over email, but I don't see why it isn't doable.

Justin Johnson
Monday, February 03, 2003

OK, I didn't actually say we wouldn't do it, I just said that it required some kind of cost/benefit analysis, as opposed to being just "pure goodness" as Wayne presented it. Programmers are apt to present their pet technical ideas as being Pure Goodness, but when I don't hear even the faintest hint of the COST of doing their pet technical projects, that's obviously the first question I'm going to ask.

Let's say that we decide that a port has cost X, and is worth nX (some factor of X). Obviously if n is less than 1, you don't do it, because it's a loss of money. That part is easy.

But what if n>1... now do we do it? Actually, no. Because there are lots of things you can invest your money (and time) in doing. So you want to choose the items with the highest return on investment. Maybe we'd rather develop a new application rather than spend time porting FogBUGZ to another platform. Maybe not. In any case any company always has a lot of opportunities any of which might or might not make money, with various probabilities, and you have to choose the ones that are the best use of limited investments, in time or money.

Joel Spolsky
Monday, February 03, 2003

But that's the point: the cost/benefit analysis is different for you and our hypothetical Wayne. Wayne values a port more than you do, and your cost is much, much lower, including your attention, which isn't distracted by a project you wouldn't pursue yourself.

I actually don't care about a port of FogBUGZ.  I'm more interested in the idea of franchising code. It strikes me as a good business model for a small software house to expand its market without tying up resources or growing the office.

Justin Johnson
Monday, February 03, 2003

And Joel is completely correct here - you do have to choose your investments wisely. My thinking was that if Joel was going to port to MySQL on the Windows platform, he must have realized that MySQL is a poor database on that platform - performance and stability of MySQL under Windows continues to be an issue to this day. I say this as someone who administers very large MySQL and SQL Server databases - MySQL is not a very good solution on the WIndows platform.

To support MySQL with FogBUGZ is to accept the performance and stability issues with MySQL under Windows, and to incur the additional cost of supporting FogBUGZ users who decide to use MySQL under Windows. Alternatively, FogBUGZ could provide ODBC connectivity to a MySQL database running on a *nix machine, which is an ever greater pain - more hand holding for FogCreek = more $ spent on user support. The other alternative is to offer MySQL compatibility with FogBUGZ but not support it - in my mind, this is never a good idea with a commercial software package (though some might disagree with me).

The other solution to this is to make the application platform agnostic, which would allow better interoperation between MySQL and the application. The cost to port could be framed as a refactoring of the code for the next release of FogBUGZ. Once the code is platform agnostic, FogBUGZ can be marketed to a larger audience.

I am not a Linux zealot - I was actually one of the first adaptors of CityDesk, and have advised a couple of my clients to purchase the software (which they have). I am a firm believer in using the right tool for the right job. Perhaps my line of thinking was different than Joel's, but hey, there's room for everyone here ;-)

Wayne Earl
Monday, February 03, 2003

It also seems that franchising code is relatively risk-free for the franchiser, given a solid contract:  if the port is bad, it doesn't get released under the franchise name, in which case the only money lost is some time and lawyer's fees (and there's a crappy competitor out there, next to which the franchiser's product looks good).  If the franchisee releases the code under the franchise name without meeting the conditions of the contract, there's clear-cut grounds for a lawsuit.  If the port is good but doesn't sell well, there's very minimal overhead for the franchiser to bear, since the sales of the port are incremental for the product overall.

These aren't trivial concerns, but they're relatively minor compared to the larger market concerns any manufacturer has when releasing products.

Justin Johnson
Monday, February 03, 2003

"It also seems that franchising code is relatively risk-free for the franchiser...."

which is the reason Microsoft ate up so many smaller companies for dinner!

Prakash S
Monday, February 03, 2003

Justin Johnson wrote, "If the port is good but doesn't sell well, there's very minimal overhead for the franchiser to bear, since the sales of the port are incremental for the product overall."

Well, I can see some customer relation problems here.

Customers who purchased the Mac or Linux version of FogBUGZ are going to expect an upgrade or bug patch when the Windows version gets upgraded or patched.  However, because initial sales of FogBUGZ on the Mac were poor -- Wayne (having fullfilled the original contract) is no longer interested in doing business with Joel. 


Tuesday, February 04, 2003

There's a couple ways around that.  First, franchising is a long-term business relationship, so Wayne's continued receipt of residuals could be contractually tied to his continuing to port the product and provide fixes, upgrades, and new features that are in the standard version in a timely manner.  Or, simply sell the port at a slight discount with the disclaimer that it's not as well-supported as the original, or that it may be discontinued.  If the port's sales are bad, then you're pissing off a very small customer base, which is probably a valid business decision.

There's an upside for the franchiser here: if the port sells well, it may become financially sound to buy the franchisee out and bring the product in-house.

Justin Johnson
Tuesday, February 04, 2003

Contract or not, if I'm a small software company my main concern in trying to create this type of relationship would be "Do I trust that Hypothetical Wayne won't take my IP and screw me?"

Steve H
Tuesday, February 04, 2003

If you are going to make the effort, look for ways to leverage your effort to increase n such as Python - wxPython.

wxWindows could have been used up front but I agree with Joel regarding being more productive with what you know and actually releasing something on your target platform.

I still can't imagine anyone moving on this without a solid analysis of the relevant market (potential value of n) and an understanding of the financial risks.

fool for python
Tuesday, February 04, 2003

*  Recent Topics

*  Fog Creek Home