views:

152

answers:

1

I hatched as a software developer in a proprietary world dominated by large corporations with closed source software - it wasn't questioned. As my career grew, the Internet became more and more of a presence and I was exposed to more and more open source software.

Looking back at most of the libraries, I am not talking about application level code, and utilities we wrote for my employers, there is very little of it that was directly a competitive advantage, and even less intrinsically represented what you would consider intellectual property. More and more of those libraries, frameworks and utilities have open source equivalents. It is now common for myself and developers I work with to first look for existing libraries before embarking on implementing such code.

That much has already changed. Many of those libraries might have withered as open source for lack of maintenance, and my employers wouldn't have suffered if they did. If they flourished or at least attracted submissions, then those employers would have benefited - which is happening at my current employer.

Now, looking at what is ahead of us I am starting to think that for a large portion of the libraries and frameworks that we will write, we should be creating them from with the assumption that they'll be made open source. That for libraries, utilities and frameworks this should be the base case, rather than the assumption that they'll be closed and that you'll have to then work to make them open - which it turns out is often much more work after the fact (getting approval, performing the reviews and cleanup).

With the base case being open-source, I think there would be benefits:

  • Developers, knowing that the code will be visible by peers and prospective future employers will likely be more disciplined about documentation, testing and design, thus making the code itself better. Just knowing that the world will be able to see your code will likely change the corners you're willing to cut. This should benefit the organization sponsoring the development.
  • Individual developers will have larger bodies of libraries and re-usable code to leverage in all of their projects, though this is a benefit to the individual developer more than the sponsoring organizations
  • Organizations would more effectively spread out the costs of development, this is a core premise of open source to begin with, though if open was the base case, it would be significantly more widespread
  • It currently attracts a certain kind of developer to the organization
  • It does not guarantee, but it provides the ability for prospective developers to enter the interviewing process being already familiar with the tools and source code the company is actually using

It feels like this is a trend, at least at the library and framework level - not at the application level in my opinion. This is a varied community, what is your opinion?

+1  A: 

I think that open-sourcing code is always a good thing (as long as it doesn't get in the way of profits, if it's code for which profiteering can/will be done). One of the biggest benefits of open-source I've seen is if a user wants a feature implemented, they can do it themselves. It gives customers an element of pride in it as well - if you helped make something, why use something else?

From a business point of view, here are some techniques to get money while still getting the benefit of open-source:

  • If you worry about competitors using your code, write a custom license that allows you but no one else to reuse the code in a proprietary application. For instance, you could license under GPLv3, but with extra clauses that allow you to use it as if under the terms of the LGPL, and that allow the code to be integrated with other GPL products (so that they can be mixed, an important part of OSS). This allows you to profit but not your competitors, while the community benefits.
  • Dual licensing is similar to point #1, but it makes it difficult for you to use code submitted by users (because it will be bound by the OSS license and that alone). You could also hybridize the approach, which would be useful if you intend to sell the library commercially.
  • Rather than selling just code, sell other property. I know of one game that has been successful (as far as a niche indie game, anyway) by open-sourcing the code but selling the graphics and levelsets.
coppro