Ask YC: Is distributing your source code a stupid idea?

Open Source (or available source) and business is a tricky combination. We (Virtualmin, Inc.) are predominantly an Open Source based company, though we also have some proprietary products--but even the proprietary products include all of the source in a non-obfuscated form. We have not had significant problems with folks absconding with our source...but we have such a strong brand and awareness of our product and Open Source projects that we aren't afraid of someone launching a competitor based on our code.<p>That said, I suspect you won't gain much by distributing source in a wholly proprietary product. Customers might occasionally find a bug or two, and might have some interest in modifications...but you can solve the former by fixing problems quickly, and the latter by providing an API. So, while your particular fears are unfounded. Why would someone steal your code, when there is probably better-documented Open Source software to do roughly the same things from a developer perspective? Where proprietary software can win is on usability, UI, support, and sometimes more rapid innovation if the field doesn't have thousands of developers.<p>As slashcom mentioned, you need to be very clear about the terms of use of your software if you include source, and if you mention inclusion of source code on the website as a feature. Like izak30, your customers may wrongly assume you're talking about Open Source software. We still get occasional users who find ways to misunderstand our license terms because we offer an Open Source version of our product.<p>Good luck, whatever you decide.

It depends on your market. Some markets would consider source-availability an advantage; most wouldn't. Are your competitors making source available? If you have no competitors (which I really doubt) find a comparable product selling into the same market.<p>A related issue is license enforcement. Lots of shrinkwrap (meaning, not hosted by the copyright holder) software incorporates licensing code to discourage installing the software on multiple servers without paying for it. Again, this decision must be made with sensitivity to your specific market. If your competitors don't protect their code, you shouldn't either.<p>Obviously, all licensing code relies on security through obscurity. If you offer customers the source, and choose to enforce licensing, you have an interesting technical challenge on your hands.<p>The only positive I can see to source-availability is a hedge against your company going out of business. A technically proficient customer such as an ISP can then continue to maintain their instance.<p>A big negative, both for you and for corporate customers, is that customer employees may modify the code, leaving it in support limbo.<p>I recommend laser-like focus on the market you plan to serve. Incidentally, such a focus may cause you to reconsider your $30 price point.

You could make it available upon request, see the reasons for the request, then decide to remove the option if people aren't taking it for the right reasons.<p>My guess is that few would ask, but those who would are the ones that could help you improve the program. People trying to take your market won't beat you just by tweaking your source and selling it.<p><p>I've been thinking about a related idea: opening the security code, at the very least. <p>How do you make the security of a web app public so that smart people know about it, but control it so that if not enough people are looking, exploiters see the holes first?<p>I think it's the kind of thing you wait to do when you're bigger, but we don't see much openness on web security like we do for most FOSS.

&#62; The application is meant for anyone with a shared hosting account or VPS...<p>FWIW, I'd never allow installation of a non-"open source" app on our servers. I put "open source" in quotes since our definitions might differ. You can release a commercial product with source available for your customers to see but the product can be under a non-open source labs certified license. Providing the source, in your case, doesn't mean your customers can give the thing away or show the source to someone else. Just specify it in contract.<p>If there was absolutely no way that we can have the source and the app does something absolutely amazing so we must have it, then we'd install it on a separate slice away from all other apps. I'm not saying that open source apps are somehow safer but at least with open source apps I can go in and try to see what it's doing and what the quality of the code is.<p>But seriosuly, why worry about source? Rely on social contract, copyright and legal contracts to enforce your ownership. If someone wants to copy your app, they'll find a way no matter what. When people deploy their web apps, they allow anyone to see their source (JS, CSS, HTML) anyway.<p>Another option is to obfuscate but that doesn't solve much.

A lot of companies have to deal with this. vBulletin and Red Hat both immediately come to mind. I don't see how it would set you back. You know all the people you give the source code to, so you know who to go to about leaks. And most clients won't care about the source code anyway. What's most important is that you be clear about the terms under which your code is released.<p>Probably should consult a copyright lawyer.

What makes you want to sell individual copies rather than collect a monthly fee by providing it as a hosted service? If it has to be hosted anyway, and unless it's going to be tightly integrated with the buyer's website/server, selling a hosted service might make a lot more sense since you can collect $x/month instead of $30 just once. And you keep your source code, and releasing updates is far simpler.

The scary thing about giving away your code is certainly this: You put in months, maybe years of development and now a competitor of yours just grabs your code, puts in slight modifications and starts to sell. You, as you don't have the money, cannot file a lawsuit (if your competitor would be google or M$ for example).<p>But: being into software development for more than 25 years now, I can honestly say: if a piece of code is longer than 300 lines, it is easier and faster to rewrite it yourself instead of trying to understand and modify someone elses code. <p>That said: generally I would not say its bad to open source your code. On the other hand, if you really have something in it that nobody else has and that makes your app better than others, keep THAT part for yourself, at least for a while.<p>See Apple. Aqua is closed, darwin is open. Good example, IMHO.

You can open-source it and insist upon them registering their site with you. If you happen to Google a non-authorized use of your software, you can quickly check it against your customer database before sending a nasty e-mail.

I think the answer will depend on a clear definition of your goals, such as your revenue goals, how you see people using your software (and what you want to allow them to do with it) and exit strategy.<p>You may just want to build a good API to make it easy for hackers to customize and extend if you decide not to release the source.

What are you trying to achieve by releasing the source code? Improved quality, by having it scrutinized by lots of other coders/hackers/devs (if you are lucky and release it under GPL).<p>Good will and Trust?<p>Perception of "more for the buck"?

I think your agreement should say that they have access to the source code if they want it. However, they must not resell any modifications and may submit their modifications to you for a discount.

Make it available to customers, even users that don't read source code will get a "warm and fuzzy" knowing that other users can and may have.

it depends on what terms it's given under.<p>probably if you distribute it with scary language about "intellectual property" and derivative works anyone with half a brain would avoid even looking at the code much less reusing it in a new product in order to avoid the possibility of a lawsuit.<p>(IANAL.)