There's no shortage of documents out there detailing how to sell free software to suits, but they all seem to assume that I'm either selling software or am a consultant of some type.
I work for a manufacturer. We don't sell software.
We sell rather expensive furniture. Our parent company sells plumbing products and engines and other seemingly unrelated things. It doesn't make sense for me to go up to the person I've got to convince to let me free the software I've written and claim that it wouldn't cut into our revenue stream.
Obviously the key point is to emphasize that by freeing some of the software we've written, we can cut our software costs. Anything that encodes business logic that we need to keep close to our vest stays close. But how does one address the very valid point that we could be helping cut our competition's costs as well, especially if the embryonic development investment is largely in-house?
Success stories and solid reassurances would go a long way, here, I think. Any ideas, opinions, etc.?
all of your systems and processes, even proprietary ones, are built upon previous works
you can rape and pillage the tree of knowledge, or contribute to its growth and tend to its prosperity first, for it is the only part of the physical universe that could be said to truly exist
excepting actual data, most development efforts benefit the creator far more by releasing them to the community (with appropriate timing and adequate resources) than if not released
the benefit, as you say, is shared software development, and therefore marginalized cost
however some (not insignificant) hidden value is realized in the opinions and trust of your clients, employees, shareholders, competitors and public at large - who are the true marketing department of any established brand, as described by clue train
releasing software does not present a competitive threat in and of itself at all, but does help to balance markets with more competition... in non-technical fields such as yours, this would minimize barriers to entry not associated with the specific field of business
The Free Software movement aims to defeat proprietary software, these who restrict other people to use their software in certain ways, not allowing modification and redistribution.
If you don't distribute the software you wrote (like your in-house code), then the issue of free vs. proprietary software don't rise.
You don't have to distribute, but it is nice if you do it in a Free way.
I've been thinking about reasons for business end-users to use free software for a while but I've never written them down before. I hope these help you (I can provide links to reports and articles that are the base for each one of the reasons):
Have I missed something ?
You may want to subscribe to the Free Software Business mailing list. It's probably the best place to get insightful comments about these issues.
grant, I do see your point, but there is always going to be business logic that we will be holding close. One of the great freedoms of free software derived from using copyright is that we can keep our in-house mods in-house. I don't plan on exposing how certain aspects of our internal business work to competitors. The suits and I agree on that point.
atai, this isn't a question of whether to release it free or not. It's a question of releasing it in the first place. Since we don't sell software or anything associated with software, it would be the epitome of silliness to release it to make it proprietary. No, I want to release some of the stuff we've written, because I think it would be useful as free software to others who will come this way someday.
My personal belief is that the most valuable free software is that which is written and maintained by those who need it, and can form a similar community around it. That's what I'm aiming to do. I need this software. I think others may too. I want to share it with them.
jneves, isn't that list really more about using free software (which we're already doing), rather than releasing in-house stuff as free software? I already contribute to existing projects in a small way, and we definitely use free software here. I don't need to do any selling there.
I'm beginning to wonder if I have a really radical idea on my hands here :-)
I think your main selling point is the potential for cost reduction in further development. You should be able to make the case that further enhancements, bug fixes, etc. will be cheaper by allowing the community of users to assist with the development. This will, of course, be offset by the inevitable feature requests and increased bug reports from users who want to use the product in a slightly different way from the way your company is using it. Another selling point is that there will be users/contributors who will have novel ideas that either boost the effectiveness of the product or add significant feature enhancements that increase the value of the product.
Open source software's most useful feature is its ability to give the community an influence over business. If you were to release software as open source with the sole function of staggering your competitors then that would twist the former statement to giving the business an influence over community. If you write software that you wish to use as an edge over competitors then propriety is the way to go. However if you want to write software that is efficiently open to the community that will use it then open source is idealistic. In short open source software alone is not a commercial marketing tool. This point is exclamated in the situation where your business is not in the software industry, but in the manufacturing sector. What I mean is that your competitor does not rely on selling software for financial gains. The main use of open source does not implement the traditional competitive definition. Open source provides an alternative to competition between two businesses whose whole concern is to make money and not create the most useful software. This alternative is for competition between communities of software uses who request their own desired software enhancements. The users hold the influence on where the software industry should improve to meet the demands of the community.
What kind of software are you considering releasing--or can you tell us that? Different applications give different economic affordances. We might be able to make more specific, convincing arguments if we knew what the software does.
On the other hand, please don't tell us unless you can get explicit permission to do so. You could get yourself in a great deal of trouble, and possibly cause a legal attack on Advogato.
How much will a bug cost your company?
I think this is the way to sell the idea of distributing your internal software developments. For some minor costs in time, you can potentially get lot's of eyes to examine your code.
The other thing to thing about is the potential PR benefits of providing something to the community. Since you have something that you can't sell, it "costs" you very little to distribute it. It will help the company in hiring as well, establishing a name among computer-savvy types. There are people that consider the ability to get paid to work on "free" software a benefit.
Too bad distributing open-source software isn't tax-deductible.
- Booker C. Bense
methodMatthew, I still have to disagree. I think there may be a fundamental misunderstanding here. I say "business logic" and "close to the vest", and several people think "1-click" and the like, or so it seems to me. This is nothing of the kind. I'm really trying to think of a clear example but it's escaping me at the moment.
Actually, some items that I wouldn't necessarily release may fall under another category entirely: those that have absolutely no use outside our walls. (How many things have you observed at a particular company and said, "there's no way anyone else would want to do it that way?" Every company has those.) I think the community would be better-served by a more generalized product rather than something that strictly encodes what we do here.
Well, there's a few things, actually. Nobody will get into trouble for any of this:
A packaging system for Solaris, along the lines of the OpenBSD ports system, except it creates Solaris packages and uses tools already found in Solaris. I can see this being very valuable, as free software for Solaris as found on the 'net is exclusively source tarballs and dead-end binary packages.
A couple nice little Zope components that I created to fulfill a few specific needs on our intranet site.
A platform for RF barcode terminals that aims to replace a proprietary system we currently use. This is where some of the business logic comes in; I'd want to release the platform but pick-and-choose from our actual implementation.
Those are the biggies.
Sorry to be a kill joy, but manufacturing is exactly the sort of industry that free (beer) software can help but itself doesn't seem likely to be much of a source of free code. The fact that the software (and possibly even the process) is secondary to the finished product makes it this way. Lets say I make widgets, very finely made aluminum widgets in fact, and the very expensive milling machine that turns them out is run by an equally expensive custom application running on a somewhat expensive proprietary OS. If I can move away from the proprietary OS, I get a small win, save money and can undercut competitors or I can churn these wider margins back into the company.
If I have my in-house programmers write a customized CNC system that runs on a free OS, I may have a competitive advantage and wouldn't want to give it up. I know that there are others who could use it and one of them might be able to undercut my prices because they won't have to pay for its development. If I adopt the free is better mantra and turn out the in-house software, how do I guarantee that later customizations get back to me? I can't, GPL or not, because it's not about software, it's about the finished product.
One possibility, is that I simply don't care about my competitors- I might be too big, have strong brand recognition, or fit a niche market- but I really have it in for the folks who sold me a bill of goods with that proprietary software and want to knock their legs out from under them by taking away their bread and butter product. Bingo. I've just guaranteed that they can't charge anyone as much as they charged me because a free alternative exists.
- technik
technik there is one fault with your one possible competitor attack. If you are a company big enough to put time and money into a product that is better then a competitor's product then you are a company who would be wasting time and money creating software that will be free in the end instead of publishing it as propriety software in your sector and earning more revenue. Supposing that you do publish the software free despite the risk there is a problem facing your company. You created free software using money that could have been used to create propriety software. The net affect is that you publish the software free and the community receives the fruits of your development effort. Part of this community is your competitor and your competitor may be obliged to climb onto the free platform you spent your money on in order to eliminate that very same competitor...
Hi, matt,
Thanks for the info. I would argue that none of these items will convey any significant advantage to your competitors. Even if they are also using Solaris or Zope, the most they'll gain is a certain amount of sysadmin time. Likewise, if they're using barcode scanners, they'll gain some licensing fees. While those gains do translate into some amount of money, they don't give your competitors a leg up in terms of core competence.
Only if you had made some sort of software that allowed them to make better and/or cheaper furniture would I be worried. In that case, they could make each unit cheaper, allowing for reductions in prices and thereby undercutting you. On the other hand, reductions in general operating expenses will probably not affect their pricing at all. If you divide the reduction by the price volume of units they sell, you'll probably end up with fractions of a penny per unit.
Since the costs are negligible, you can argue that the benefits of freeing the software outweigh them, using all the good points other Advogators have made.
I have several sysadmin friends who would love to have a ports-like system for handling software installs on their solaris hosts. Assuming there is enough demand, you might find a reasonable solaris "ports tree" would grow up from the release of such a system.
Very few companies out there even look at sourceforge to see if useful tools are available. Chances are your competitors won't even know of your software's existence, even if you announce it.
On the off chance that they do find your software and start using it, they will put themselves in a position of always being slightly behind you.
I have released free software with the official blessing of a non-software company. An essay I wrote to help convince them is Free Software: Solving the Buy/Build Dilemma.
An example of a similar setup is Alladin Ghostscript (they continue to develop and improve ghostscript in great ways and relicense their code under the GPL after a time delay).
For the Solaris ports system and the Zope components, I think the easiest way to go is suggesting very practically that you've written these things as ways to make your job more efficient, but not to make the company more efficient. Thus, as it's your responsibility to ensure you are being efficient in doing the tasks assigned to you, you should be given some leeway in deciding how to do this.
Clearly a Solaris ports system and Zope components are only there secondarily to help you solve some primary problem, like maintaining the Solaris network and intranet. It's not inconsistent to let you deal with how you solve those problems yourself, such as by choosing an already free software package or--by extension--sharing these utilities with other developers that can help you improve it.
Unlike the tired and unconvincing argument that sharing the code reduces developer costs, instead you're asking just for some freedom to attack the problem in the best way you know how. Moreover, this is the same magnitude as going to conventions or training seminars as it is similarly cross-professional, not cross-industry. It's only the cross-industry software that is of concern, like the barcode scanner.
Releasing cross-industry software becomes a strategic decision, not just a troop-level tactical decision like a Zope component. I would hold off shooting for the moon on the barcode scanner, personally.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank