8 ms·

On Releasing Your Company's Software as Open Source

jacquesm 17y ago
I read this article as a series of thinly veiled reasons that should discourage people from open sourcing anything corporate. Here is the abstract: - it will take some effort to release an in house package to the community - you may have to get approval from legal and that is no fun way to spend an afternoon If that hasn't discouraged you from this path of folly then: - you may have to do some cleanup work before a release - If you should decide against all odds that 'Yes' you do want to release your in house code you must be a bit of 'arrogant', after all who are you to think that others will value your code. Really, I find the tone of this article hard to stomach. Not a single positive aspect of releasing your code as open source is high-lit, not even for contrast purposes. Let's have some balance here: Releasing corporate open source is great because: - you will potentially have a lot more eyes looking through your source code, fixing bugs and cleaning things - you may find that some of the contributions parallel your own in house needs effectively reducing your own development cost - if you should decide you want to 'clean up' your code before releasing it you are likely to end up with better abstraction, in fact, you should probably have worked along those lines all the time. - if you take from the open source community (the example is in house extensions to a framework) and you think there might be a general use case for that code then it won't cost you a lot to put it out there, not compared to the time you originally saved by basing your code on open source development in the first place. Take a lot, give back a little seems to be a pretty good deal.
- russell 17y ago
  "You might have to cleanup your code," sounds like sufficient reason to release to open source. Your company will benefit even if no one else picks it up.
  - russell 17y ago
    EDIT: so now I've actually read the article. The point about legal vetting is valid. Rather than having each piece of code approved, there should be a policy some thing like, improvements to existing open source are OK, general interest utilities are OK. Core business functionality or software with significant money making potential for your company need approval.
    - jacquesm 17y ago
      Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. A policy is made before the work starts, not at the time you think you may want to open source something (though that probably will happen plenty of times). It's a great way to be confronted with the need for such a policy though. To use the fact that you need approval from legal as a reason to forego open sourcing anything is nonsense. You need approval from legal for any kind of action that you do on behalf of the company you work for that interacts with the outside world, including opening up source code. If only to make sure you do not inadvertently expose the company to a liability or give your competitors access to the software that gives you an edge. Nobody ever suggested that would be a good idea. Even google doesn't do that, ask them to release their GFS implementation and we'll see what comes back.
      - antonovka 17y ago
        Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. Yes -- the policy we have is roughly: MIT/BSD/Apache: OK for any purpose -- Note the license requirements in the project's top-level LICENSE file. LGPL - Only as a library, and only for non-statically-linked projects. GPL/MPL/Copyleft - Only for system utilities, not to be integrated into any existing code base under any circumstances. We'll still contribute GPL licensed code back to projects. On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects.
shykes 17y ago
I'm curious. Has anybody here released open-source code as part of a clear business strategy? Other than selling support and maintenance for it.
- bjelkeman-again 17y ago
  Yes. Examples? How about Automattic, Inc., the folks behind Wordpress? But maybe one can define what they do as "support and maintenance". Or IBM, they sell hardware, (among other things) but with open-source operating systems on it. They contribute to the development of this software. We, Akvo Foundation, also release open-source code of our products but may not qualify in your normal definition of "business". http://akvo.org/ http://akvo.org/ Akvo is a non-profit foundation, but one which has as one of its goals to be able to self sustainable on the charges for running some of our services. We are what some people call a "social enterprise". So some of the main differences between us and a "standard" company is: - some of our investors don't expect to get paid back in money, but rather in increased efficiency / improvements / new ways of doing business, within the sector we are working in, water and sanitation development aid (we also have investors who expect some ROI in the form of cash). - we can't turn a profit, but neither should we run at a loss.
- DarkShikari 17y ago
  http://developers.facebook.com/opensource.php http://developers.facebook.com/opensource.php
  - shykes 17y ago
    Thanks for the reference, but I meant someone on this forum. I was hoping someone directly involved in such a decision would share insights. Was there a specific business objective? If so, was it a success? Or was it a more general statement on the company's values? As hackers with an entrepreneurial mindset, we might face the question of whether or not to open-source some of our work. The question is: when we make that decision, which hat are we wearing?
- ZeroGravitas 17y ago
  I was watching a interview with the guy that suggested the idea with On2 to release their VP3 codec as the basis for Ogg Theora. He used the descriptive term "scorched earth" as one reason for doing so: http://en.wikipedia.org/wiki/Scorched_earth http://en.wikipedia.org/wiki/Scorched_earth In other words, you can undermine your competitors by having a free version. An open source version takes this one step further.
andrewljohnson 17y ago
The article is trite and uninformed.

I read this article as a series of thinly veiled reasons that should discourage people from open sourcing anything corporate. Here is the abstract: - it will take some effort to release an in house package to the community - you may have to get approval from legal and that is no fun way to spend an afternoon If that hasn't discouraged you from this path of folly then: - you may have to do some cleanup work before a release - If you should decide against all odds that 'Yes' you do want to release your in house code you must be a bit of 'arrogant', after all who are you to think that others will value your code. Really, I find the tone of this article hard to stomach. Not a single positive aspect of releasing your code as open source is high-lit, not even for contrast purposes. Let's have some balance here: Releasing corporate open source is great because: - you will potentially have a lot more eyes looking through your source code, fixing bugs and cleaning things - you may find that some of the contributions parallel your own in house needs effectively reducing your own development cost - if you should decide you want to 'clean up' your code before releasing it you are likely to end up with better abstraction, in fact, you should probably have worked along those lines all the time. - if you take from the open source community (the example is in house extensions to a framework) and you think there might be a general use case for that code then it won't cost you a lot to put it out there, not compared to the time you originally saved by basing your code on open source development in the first place. Take a lot, give back a little seems to be a pretty good deal.

russell 17y ago
"You might have to cleanup your code," sounds like sufficient reason to release to open source. Your company will benefit even if no one else picks it up.
- russell 17y ago
  EDIT: so now I've actually read the article. The point about legal vetting is valid. Rather than having each piece of code approved, there should be a policy some thing like, improvements to existing open source are OK, general interest utilities are OK. Core business functionality or software with significant money making potential for your company need approval.
  - jacquesm 17y ago
    Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. A policy is made before the work starts, not at the time you think you may want to open source something (though that probably will happen plenty of times). It's a great way to be confronted with the need for such a policy though. To use the fact that you need approval from legal as a reason to forego open sourcing anything is nonsense. You need approval from legal for any kind of action that you do on behalf of the company you work for that interacts with the outside world, including opening up source code. If only to make sure you do not inadvertently expose the company to a liability or give your competitors access to the software that gives you an edge. Nobody ever suggested that would be a good idea. Even google doesn't do that, ask them to release their GFS implementation and we'll see what comes back.
    - antonovka 17y ago
      Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. Yes -- the policy we have is roughly: MIT/BSD/Apache: OK for any purpose -- Note the license requirements in the project's top-level LICENSE file. LGPL - Only as a library, and only for non-statically-linked projects. GPL/MPL/Copyleft - Only for system utilities, not to be integrated into any existing code base under any circumstances. We'll still contribute GPL licensed code back to projects. On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects.

shykes 17y ago

I'm curious. Has anybody here released open-source code as part of a clear business strategy? Other than selling support and maintenance for it.

bjelkeman-again 17y ago
Yes. Examples? How about Automattic, Inc., the folks behind Wordpress? But maybe one can define what they do as "support and maintenance". Or IBM, they sell hardware, (among other things) but with open-source operating systems on it. They contribute to the development of this software. We, Akvo Foundation, also release open-source code of our products but may not qualify in your normal definition of "business". http://akvo.org/ http://akvo.org/ Akvo is a non-profit foundation, but one which has as one of its goals to be able to self sustainable on the charges for running some of our services. We are what some people call a "social enterprise". So some of the main differences between us and a "standard" company is: - some of our investors don't expect to get paid back in money, but rather in increased efficiency / improvements / new ways of doing business, within the sector we are working in, water and sanitation development aid (we also have investors who expect some ROI in the form of cash). - we can't turn a profit, but neither should we run at a loss.
DarkShikari 17y ago
http://developers.facebook.com/opensource.php http://developers.facebook.com/opensource.php
- shykes 17y ago
  Thanks for the reference, but I meant someone on this forum. I was hoping someone directly involved in such a decision would share insights. Was there a specific business objective? If so, was it a success? Or was it a more general statement on the company's values? As hackers with an entrepreneurial mindset, we might face the question of whether or not to open-source some of our work. The question is: when we make that decision, which hat are we wearing?
ZeroGravitas 17y ago
I was watching a interview with the guy that suggested the idea with On2 to release their VP3 codec as the basis for Ogg Theora. He used the descriptive term "scorched earth" as one reason for doing so: http://en.wikipedia.org/wiki/Scorched_earth http://en.wikipedia.org/wiki/Scorched_earth In other words, you can undermine your competitors by having a free version. An open source version takes this one step further.

andrewljohnson 17y ago

The article is trite and uninformed.