This meditation splits from an earlier meditation <snip>. Now my focus shifts to: finding other "little red hens" interested in doing up-front work to reap rewards later on. A leaf of node "software collectives" considers developers' interest in open source projects whose output is sold (not free). I'm thinking of my specific application and offer parameters for discussion, but I hope the content is applicable beyond my example. (duh.)

The free rider problem is only partly solvable. You have to convince each participant that their value from participating justifies their work.

This leads to another challenge I face. I have this crystal of a program. It answers a need within an industry I'm familiar with that no one else answers. Not that my method is patentable, it's just that others haven't used the confluence of Perl and certain sw/hw technologies that pervade my industry to address a critical aspect of the industry's workflow. This particular methodology has productivity implications for users beyond my core industry and can be a building block for further software enhancements (these being useful ingredients for open source per lachoy.) And while the methodology might have its place for personal use, I forsee its main deployment as a business application, and therefore amidst users more likely to care about following the software's license agreement.

I can think of all sorts of things to add to my crystal. I can think of lots of ways to rearrange the innards of my crystal. But the opportunity demands that I use my time doing more than creep features into the code, especially since I'm not super-fluent in Perl's subtle aspects that can make the code a 'standard'. I'll need help.

My fantasy is that, by being first to market with a credible first-step solution and having a feasible system of achieving sales to a core set of clients, I can grow the crystal into a standard that's easier for others just to use rather than compete with. The package feeds on itself and soon forgets the puny part that I contributed, replacing it with Much Better Stuff. Now, how to realize the fantasy (besides just "wake up!"? :-)

Brainstorming time:
1. Do it myself.
Pro: Focused effort. Feeds my ego.
Con: Too little too late, needs-of-the-business go unmet, bankruptcy follows.

2. Hire programmer(s).
Pro: Gets the job done sooner. (Maybe. Hopefully.)
Con: Requires cash up front.

3. Display the source to others, incorporate suggestions into the code.
Pro: Hopefully better stuff than I could write, leaves me time to develop the business, cheap.
Con: Good Luck. (Oh, and gives would-be competitors that much more info to plan their own projects.)

4. Pay a bounty (perhaps "shares"* of a revenue stream) for changes incorporated into the software. Specify the sections where I know I want improvement. (Carve the whole thing into "please-make-me-better" chunks.) Incorporate suggestions I never would have dreamed of.
Pro: Similar to 3 (and 1 and 2 for that matter! :-) Puts off payments till later, when the cash flows.
Con: How to reasonably reward/pay for "this change" vs. "that." Requires trust that funds will really flow (which in turn requires good management, marketing, distribution, etc.).

Does such blending of "open source" development and licensed-to-bill ever happen? Examples? If the problem is interesting enough, would a parallel "free" effort emerge or might financial temptations as above keep buying off would-be developers?

* More fantasy: Start with an imaginary pile of 1,000,000 shares. Allocate in miserly fashion, revisit allocation-fairness with periodic "significance reviews." (via peer review/voting? :-)

And yes, this is an MLM scheme in which you have a friend who has a friend who has a friend who knows some Perl... :-)