The short answer is that smaller organizations are not set up to cooperate that way.

Each has an IT department that is (choose three) small, overworked, understaffed, underskilled, a fiefdom, an empire, disregarded, a nest of BOFH, a money pit, an unrecognised profit center.

Prerogatives are jealously guarded. Contact between departments is discouraged to avoid personnel raids. The parent organizations are apt to be in competition with each other.

After Compline,
Zaxo

Seriously, the secret is to know your customer.

I am expecting to market this to smaller organizations first, approaching larger ones when I show it working.

Once you have this document, you are in a much stronger position to do business. Also, this will have helped focus you on precisely what you are intending to deliver. There have been many instances of people becoming over enthusiastic and unrealistic - then getting totally stitched up by the customer or their lawyers.

Why don't (or do?) hospitals, local governments, law enforcement groups, etc., with smaller user populations individually, band together and collectively ante up a couple of bucks each to have the $25,000 to pay for packages that they would own and use as they see fit?

As zaxo has said, you may find yourself in competition with an IT department, however this need not be the case. If there is an IT department, they need to become your friends if you intend to make any headway.

Another important point is to establish the right contact, at the right level in the customer's hierarchy to act as a sponsor. If you approach somebody too junior, your sale will be lost in the mire of internal politics. Too senior - you just won't get the opening.

In terms of hospitals etc. clubbing together for procurement. This actually happens I believe, but you need to understand their meta-infrastructure, and work out at what level (county, state, federal, etc.) these recommendations are made.

My $0.02. I'm glad to be able to share some experience, as I am working for a consultancy, and some of our clients include local government and national health service.

So, you are putting together a personal "time management" package. I hope for your sake that you are not intending to make a living off this package. </sarcasm>

Well actually, yeah! But it's not time mgt and the software is something of a "monkey's paw", since it catalyzes a process that requires additional hw/sw/services. (It has to do with transcription of dictated text, content eminently suitable to manipulation by Perl. :-) And I'm expecting that people in a position similar to me can resell my package to lead to further sales for themselves.

Unless you are intending to produce this code as open source, ..., I would recommend not writing a single line of code until you have confirmed interest from some prospective customers.

Are you saying that open source implies I will be tossing away any financial benefit so that I don't have to worry about making money from my project -or- are you saying that open source can help tap into this large market of prospective customers such that it would be a smart way to release? I'm a bit stuck at this point since, having developed in Perl, my code will be visible in one way or another to those that insist on looking. But do I use this fact as a feature--"open source by choice"--or do I fight this fact with sanctions in my license agreement against peeking? I've invested a lot in getting my software to its current state and I need to generate a return.

I'm concerned about WHEN my application will attract competition from more capable developers (much less an independent open source project! :-) and so I want to build market share and reseller allegiance as quickly as possible, ideally improving the software along the way based on appropriate feedback. Thus improved, I could handle competition much better. Would open-sourcing this to get feedback from developers help or hurt, and would anyone even contribute if their suggestions go into a product that benefits me financially? (Though I'd be all too happy to pay for software advances that make the product sell better.)

Do your market research first. ... There have been many instances of people becoming over enthusiastic and unrealistic.

Well I'm prone to that :-), but I've also been involved in this application area for a couple of years and seen users and pilots fail for lack of what I'm now supplying. (My opinion, anyway.) I've been getting some usability feedback over the summer from some prospective users (pro AND con) and I think I'm on track.

In terms of hospitals etc. clubbing together for procurement. This actually happens I believe, but you need to understand their meta-infrastructure, and work out at what level (county, state, federal, etc.) these recommendations are made.

From my perspective, I'd just as soon each one acts independently and buys separate rights to the software. It just seems to me that they would save themselves a whole lot of money in the first place if they missioned someone to develop such a package for their collective benefit. Electronic Medical Records systems (EMR) come to mind as naturals for such attention. If a hospital put in their two cents for such a system, and something credible developed, they wouldn't even have to implement it--just use it for leverage in paying for their first-choice package!

As for governments, might there even be legislation in the U.S. which discourages/forbids governments from colluding with each other in areas where the private sector can be expected to provide? Such would seem like an irresponsible use of my tax dollars, at least where software development is concerned.

... the software is something of a "monkey's paw", since it catalyzes a process that requires additional hw/sw/services.

Nice trick if you can pull it off. It depends on how canny your target audience is. Selling consultancy on the back of a loss leading software package is standard practice, and justifies how many of us can spend work time on open source projects.

Would open-sourcing this to get feedback from developers help or hurt, and would anyone even contribute if their suggestions go into a product that benefits me financially?

That depends precisely on the kind of licence you issue with the software. It is worth looking at existing licence templates, such as the GNU General Public Licence, and the Artistic Licence - and others.

In terms of your dilemma - to open source or not to open source, this is a question of the tanstaafl argument. If you want to charge for your software, people working for you will expect to be paid.

As for governments, might there even be legislation in the U.S. which discourages/forbids governments from colluding with each other in areas where the private sector can be expected to provide?

I admit my ignorance about the American due process when it comes to government procurement. The situation in the UK is quite different, as authorities do tend to work together, at least in principle, in the collective aim of saving money.

You have produced a user productivity application without talking to actual potential users, and without a real client in sight. You now expect to be able to sell this to real companies in a year where they are heavily focussed on cutting costs? Medicine is your target, and that is in worse shape than most.

Pardon me, but working without feedback like this is like trying to thread a needle without looking! Or like trying to walk without an inner ear. Theory says that you can do it, but examples are hard to find.

But if you have a product that will be appreciated by users, then learn something about negotiation before trying to sell it. Getting To Yes is good. Decide on a strategy. This year that strategy had better be, "Here is how you will save money." Be prepared to justify savings. Showing how to replace people is ideal. Start with companies that you don't expect to sell to. Use them as practice before going where you don't want to screw up.

That was general advice. Now to answer your actual question.

Companies compete by specializing. Superficially similar companies focus on what they do better than others, and so no two look alike. This makes identifying common needs hard, and the more it is integrated into how they work, the harder it becomes. Also companies have to get past the free rider problem. You also face both issues. Changes that one customer wants will make it worse for another. There will be customers who look at what you have, copy the specs, then write their version in house.

Good luck. If this flops, then this too was practice. The lesson is to get feedback before developing. If you can keep getting up and learn each time, you will succeed eventually.

You now expect to be able to sell this to real companies in a year where they are heavily focussed on cutting costs? Medicine is your target, and that is in worse shape than most.

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.

Creating the software is a piece of cake compared to training people to use it, maintaining it and extending it for new/modified uses over its lifetime. I'd imagine the lifetime would be fairly long (~10 years?) for an institution like a hospital. Software companies are -- or should be :-) -- built to handle situations like this. A lone consultant isn't.

Chris
M-x auto-bs-mode

Creating the software is a piece of cake compared to training people to use it, maintaining it and extending it for new/modified uses over its lifetime.

So are you saying that the source code itself is a side issue, i.e. I benefit by putting code in the sunshine for anyone's review, and organizations that plan to compete with the software don't care about access to the source code since they'll start from scratch anyway? Will they really? I suppose that organizations that plan to compete will have their own challenge if their "non-open source" stuff is not far spiffier.

With regard to the resellers I hope to sign up, I guess ultimately they don't care where the code comes from as long as it works and as long as it catalyzes the additional sales/services opportunities that will be part of their offerings. For them do I cast open source as "reliability insurance?"

Should I maintain the trappings of traditional software packages of installation keys for demo versions and serial number keys for production versions? Obviously the wrapper enforcing the key can be deleted but that would violate the license agreement, wouldn't it? :-)

Does 'open source' code present far different issues for maintenance? What about proliferating versions?

My main point was that many times issues of training, maintenance and feature enhancements aren't considered when you look at a problem and say, "That's not so hard." I know I've been guilty of that false hubris in the past.

Whether open source is appropriate in this case is another issue. If you're creating a framework that provides some basic functionality that others can customize (like a specialized application server), then open source can be a good idea. (IME open source software works best when it's infrastructure.)

This is particularly true for attracting VARs. The permanent availability of the framework can be a strong argument for a VAR to invest the time and resources necessary to learn the framework and possibly adapt existing software to fit in or use it.

Regarding installation keys: beats me, although I doubt people will miss them :-)

Chris
M-x auto-bs-mode

As a consumer, BigCompany Inc. faces a "make" or "buy" decision: If they mission a Perl programmer to do what I have done. . .

In my experience, most companies don't work that way. Either they buy the product, buy the competitor's product, or decide not to buy because the products don't really meet their current needs or fit in their current budget.

Big Company Inc. tries to stay focused. Developing personal productivity software isn't staying focused unless Big Company Inc. happens to be a software developer that is already in or wants to enter that market.

Big Company Inc. is also going to try to look at the long term. Commercial software has fewer long-term downsides such as support and maintenance. Proprietary software has fewer upsides such as the ability to hire people with prior experience using it.

Buying software is low risk, developing it isn't. What you did relatively cheaply on your own would probably cost Big Company Inc. a lot more and would probably take a lot longer. Most companies do not have the resources in-house and, even if they do, those resources are probably tasked to other projects.

Would they hire a contractor? Contractors are pretty expensive. Even researching the possibility could be costly. Quality and timeliness would still be a crapshoot. No, they probably would not hire a contractor unless they felt your product didn't fully meet their needs. You might try to capitalize on situations like that before they get that far. Leverage your existing product by offering customized solutions based on it, for a premium of course.

-sauoq
"My two cents aren't worth a dime.";

Ahh, I can use the riskiness of "make" to my advantage.

To what extent does the availability of source code for my product affect their risk? I would think that "availability" would greatly clear up their risks, emboldening them to take on such a task.

"The devil they know vs the devil they don't know" wouldn't be an issue any more....

Or is the reverse more likely, that with source code available, it is even less risky to "buy" because they can make/recommend/negotiate changes that expressly meet their needs?