http://qs321.pair.com?node_id=207421

"Funding Open Source" has probably been hashed out elsewhere. But I want your current opinions.
Update: i.e. Would "bounty-hunters" be attracted to this scheme? Else ______?

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... :-)

Replies are listed 'Best First'.
•Re: Funding Open Source / bounty-hunting...
by merlyn (Sage) on Oct 23, 2002 at 22:19 UTC
    I just heard Eric Raymond address that very subject rather well on this most recent Linux Lunacy Geek Cruise. If I'm not mistaken, his words are on his site.

    If it's not anything in there (and this is costing 30 cents a minute from the ship so I must be brief), then the bottom line is:

    The real money in software is not in locking up access to the software -- it's in making the software completely ubiquitous and then charging for support.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      Well, I hate to be obvious, but I'm with merlyn on this one. Support is the big money maker. Low cost of entry is often what gets a software package in the door.

      I can:

      • A) Offer you a site license for $10,000 -or-
      • B) Give you the program, charge $5,000 to set it up and $10,000 yearly to support it.

      Folks who don't need support will use it of course, and if it is OSS, contribute code. Think about this: People in your industry, familiar with their workflow and processes, working to make a better product. (Not to mention the name recognition should you seek another job in that industry...)

      Making money is one of those Tao of Steve things many times. Actively pursuing money will cause it to run from you. Bheold the great DobbsHead and recieve thy fair dose of slack my friend.

      Come to think of it, it's a shame that Linus didn't just "Bounty Hunt" out portions of the Linux kernel and try to sell it for $60. Oh wait, BeOS tried that....

      The annals of software companies are littered with the corpses of those who came before and focused on the money for their products, not the acceptance of their products. When Wolf3D (That's 3D?? HaHaHa...) went the shareware route, most game companies thought it was suicide for ID. Those companies are pretty much out of buisness now.

      I'm pulling reciepts now, and 4 scripts that I offer for free on my website netted me $12,000 last year in support and configuration. Oddly enough, I made $1,650 supporting Matt Wright's "Formmail.pl" script.

      Think about it.
      ~Hammy

Re: Funding Open Source / bounty-hunting...
by trs80 (Priest) on Oct 23, 2002 at 21:59 UTC
    I would venture to say that most "bounty hunters" would not be interested in this. I would suggest you make your idea into a CPAN module and then ask for assistance. If nothing else you need to have it in a module form that people can build from or you really don't offer an abstacted enough component to compete in the manner you are suggesting. I am not a lawyer, but I think your idea would be protected by the License you choose to release it under so you have control over who can or can't bundle it for commerical applications. If you chose a route other then CPAN then you might want to contact ActiveState or another commerical Perl company and see they are interested in the product/idea that you have.
Re: Funding Open Source / bounty-hunting...
by Dragonfly (Priest) on Oct 24, 2002 at 06:19 UTC
    I do think that there is a chance that you're on to something that many people could benefit from. If you have the modules ready to roll, put them on CPAN, by all means. Choose carefully which license your software is under. And then, encourage two groups to download your software; first, the users, which you can show how nice your software works and how much it can help them with their work. Then, show another group, the group of programmers you know and respect, and have them download the software and make improvements to the software.

    As far as the money thing goes; some programmers won't charge you for development they do on GPL licensed software, if they feel it is for a good cause. However, if you start charging money for the software, they may feel like they are entitled to some of the profit from this, which is something you need to discuss *before* it gets to that point, preferably. You could divvy it up with the theoretical 1,000,000 points, with points divvied out to programmers who make contributions, and then allocate profit according to the point system.

    Or, another way to approach the financial side of this, is not to charge for the software at all, but charge for the support for the software. If it is good and modular code, you could perhaps have certain custom extensions pre-written that aren't available on CPAN, but you would be happy to deploy for the company in question, for a price of course. This keeps the core programming group out of the loop, however, which may or may not be a good thing, I guess.

    Anyway, I look forward to seeing what results from this endeavor! Good luck to you sir.