Actually, tight times can be a help in surfacing pain within departments that used to just pass on their costs to others. With others not so willing to accept those costs, my software helps avoid the costs in the first place.

Now to answer your actual question. ... similar companies focus on what they do better than others, and so no two look alike. ... identifying common needs (is) hard ...

But wouldn't access to a decent accounting package, for example, be useful across the board, e.g. (OT) Perl Open Source accounting packages? Or an EMR system as mentioned in a previous node?

companies have to get past the free rider problem.

This is fundamental. (I considered including "Belling the Cat" as part of this node's subject.) In several agriculture-type industries, businesses pay a sort of tax collectively that funds ad-campaigns (Drink milk, Drink orange juice, "pork, the other white meat") that benefits them collectively. I would think that SOMEHOW there's a way to break through to more corporate decision-makers that funding open-source groups, however minutely, would serve their long-term interest. Hmm, just as public radio annoys enough people for long enough to collect money for the next six months, code-developers of the world could unite and build in slow-down mechanisms that kick in simultaneously until the corporate leaders pay up their open-source subscriptions! :-)

There will be customers who look at what you have, copy the specs, then write their version in house.

Yup. Any suggestions for getting them into the "buy" category instead of the "make"? They won't want to maintain/develop forever when their "competitive advantage" lies elsewhere, so this should help make "write their version" == "don't go there". That's where my query on "organizational license" comes from--might price of an organizational license be an issue that keeps this task from being assigned in-house?

And by the way, "organizational license" is another issue I wonder about: I'm assuming that organizations have methods of sharing tools they have developed internally thoughout their "organization." Or should I assume they are dis-organized and plan on selling multiple "site" licenses to an organization? (Or: sell organizational licenses to four different departments of BigCompany Inc. before they realize they only need one. :-) Part of the negotiations, I know...

Good luck. If this flops, then this too was practice.

Thanks. Gaining actual development experience certainly was another design goal of this project. :-)

If you believe that your product saves money, then you have a chance. If you want to sell at price points like $20,000/year then you had damned well be able to walk in and convince them that they can replace at least one person, probably 2. You also want a pitch where you come to the point very fast - you will be talking to busy people who don't know you from Adam.

But saving money is not as easy as it looks. Take a good accounting system. It intersects the business at a lot of points. This makes it not generic. A few years ago O'Reilly needed to replace theirs. They got a few other publishers to cooperate to create an open source one. I don't know how that went, but I do know it was harder than they expected. Besides, big businesses like having ERP systems be expensive, it is a barrier to entry for potential competitors.

The free rider problem is only partly solvable. You have to convince each participant that their value from participating justifies their work. If nobody can be found for whom that is true, then you have a bigger problem. See The Tragedy of the Commons. And no, annoyware and open source don't really mix.

About buy versus make, the price point will affect this. Also who you deal with. As for best pricing strategies, I don't have relevant experience. Sorry. Nor is this a good place to find that.