views:

647

answers:

7

We are currently considering licensing options and releasing our app as open source is one of the options on the table, but we have some concerns about forks and a few other issues as well. If you've been involved with the licensing of a software your company has produced, what were the considerations that ultimately made you accept or reject an open source license? Also, as a programmer, are you more or less likely to use open source tools in your work and why?

+5  A: 

Who will get the biggest advantage, you or your competitors? If you are in a competetive industry, releasing your IP as open source could give other companies what they need to beat you. On the other hand, open-sourcing your code might mean you will get the help you need to finish something and get it production-ready, when you couldn't have done it yourself.

Every software product usually has some unique core code that sets it apart, makes it unique. Don't give that away. But a huge part of your codebase is probably plumbing code that everybody uses, and you just want it to work. Section that stuff off and let others help with it, or find an existing open source project that's already handling that functionality and contribute to it.

Eric Z Beard
+9  A: 

I highly recommend the book "Intellectual Property and Open Source: A practical guide to protecting code" by Van Lindberg. It has answers to a lot of questions like this and does a really good job of explaining how and why open source does or does not work in most situation.

Nick Gerakines
Thanks, we'll check it out.
VirtuosiMedia
A: 

You should be aware that "Open Source" means different things depending on who you ask.

To some people "open" covers the license as well. To others, it doesn't. For example, some companies release the source to their applications, but they don't grant you a license to modify it.

ilitirit
+11  A: 

Joel wrote a good post that I believe is relevant here.

If your application is your core business, then it probably doesn't make sense to make it open source.

If, however, the application is secondary to your core business, say it uses a service you provide and that service is your core business, or it controls a specific piece of hardware, and that hardware is your core product, then it probably does make sense to open source it because you are commoditizing the things that make use of your core product. If more people have access to the software, then more people will be encouraged to use it, and you may even find people finding new uses for your product, porting the app to other platforms etc.

It all depends on where you make your money. If you make money by selling this application, don't open source it. If the application allows people to make use of the product you do make money from, then do open source it.

SpoonMeiser
+1 - Excellent Joel article
Dana Holt
+1  A: 

What is your product? Are there competitors? Have you done your homework on who your target market is and why? In other words, what is the "value" of your software? If you don't know what it is worth or who your target market is, then what licensing model you release it under is the least of your worries.

Can I recommend a book that made a difference for me after I tried licensing my software for profit and failed miserably? http://www.amazon.com/Crossing-Chasm-Marketing-High-Tech-Mainstream/dp/0066620023

Unless you have something extremely unique, that can reach a broad audience willing to pay for it and you have a marketing budget 10x more than what it took for you to develop it, then perhaps you might be able to sell the app. However, if your IP is in “how” the app can be applied, then open sourcing it and charging for how to use it may make more sense.

Btw, my latest software venture is open source: http://www.codeplex.com/gsb and that is going better than my first attempt at getting people to pay for the software.

A: 

I've worked on a fair few line-of-business applications and have generally thought that the sum total value of the source code for anyone outside of the very small circle of business users that the application was essential for would be zero. Maybe less than zero.
As far as value to the 'community' goes... it's cost you time to work through the code to find that there's nothing all that useful in there.
I'd want anything that was made available open source to be useful to people. Are they going to extend it? Are they going to learn from it?

Hamish Smith
A: 

"what were the considerations that ultimately made you accept or reject an open source license?"

The reason for accepting a license is (1) it works, and (2) there's a known exposure, usually zero. Since you're not paying anything, the license terms are usually very favorable.

[Most CIO's will balk at the "Who Do We Sue?" question. I don't understand that. You do QA on open source the same as in-house source. You don't sue yourself when you screw up.]

The fork "issue" isn't very interesting. You use an open source component because (1) it works and (2) you have the source. Once you have the source, the project that created it can crash ad burn. You have the source.

"Also, as a programmer, are you more or less likely to use open source tools in your work and why?"

Use open source all the time. Can't imagine working any other way.

Why? It works. I have the source.

I've struggled with legal issues surrounding code escrow and trying to work with the crap that was escrowed as part of legal proceedings. I prefer to have the actual complete source.

The biggest issue isn't project forks, license terms, or programmer acceptance. It's Quality Assurance. You have to have actual testing for all components, open and closed. Failure to test open source products is a fatal mistake. Open source is just source, you still test it, you still evaluate for fitness for purpose.

When the project upgrades, you have to independently evaluate each release for overall basic functionality, quality and compatibility. Open source isn't free. It's a cost transfer -- from vendor organization to your organization. Hopefully, you can do it more cheaply than a vendor could.

The second big issue is Configuration Management. In some cases, you can't manage to use open source components. If you're not very good at QA and configuration management, you may find the open source is impossible for you to manage. You may need to have a vendor handle configuration management and support for you.

S.Lott
Read the question again. The forking concern is that others will fork from the software the questioner would be providing, not that they are concerned with projects they rely on forking. There is a reasonable concern there for their company, or at least the company's suits.
Chris Charabaruk
How is a fork from your project a concern? You offered your code. The project forked. What have you lost? Your stuff works. You have the source.
S.Lott