Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Experiment: MindShareWare

By Speare in MLP
Mon Jun 25, 2001 at 07:18:39 AM EST
Tags: Software (all tags)
Software

I've put together the skeleton of a community-coding project called MindShareWare, which aims to close the loop between software author and software user. The users can request the features for a bounty fee, and the authors can find new spare-time projects for a few bucks each. Will this work? How would you improve on the idea?

(Yes, this is shameless self-promotional mindless link propagation.)


In the process of setting up a not-work-related domain, I finally started dusting off a lot of ideas that I'd been leaving on the shelf. Things that wouldn't go together with my company's strategic focus.

One of these ideas was that of MindShareWare, a sort of writing-code-for-the-fun-of-it community effort. Why must the software authors all choose the features? Why not let the users ask for what they'd like to see?

There are a lot of reasons to write software yourself. However, there are just as many reasons to let someone else write it, if only you could find someone interested in the task. Linux is a good example of that: it's the most self-assembled large project out there, but the non-programmer users still outnumber the developers by a hefty margin.

Read through the site. If you want someone to write a little Java tool, submit a project and put a price on it. If you want to develop one of the listed projects, the site will tell you how to get started. Learn from other people how to write good (or bad) code. Refine your craft, or get someone else to develop the projects you don't have time or energy or skill to tackle. Share minds, share software.

Of course, it's just a VERY preliminary site, so I have to keep it simple. If it catches on, I'll branch out to new technologies and new license arrangements, of course, but for now I'm limiting it to two big caveats:

  • Public Domain original code only, and
  • 100% Sun Java 2 code only
  • It's not a competition, and the tiny starter bounties (~US$20) for projects isn't at all intended to be a "working wage." This is all for learning, for spare time interests, for fun.

    I want to hear YOUR take on it. What would you change, and would you ever take part in such a project?

    Sponsors

    Voxel dot net
    o Managed Hosting
    o VoxCAST Content Delivery
    o Raw Infrastructure

    Login

    Poll
    What's your MindShareWare idea?
    o I've got a project idea 2%
    o I've got some spare time 19%
    o I don't touch Java 60%
    o throw new NonSequiturException(); 17%

    Votes: 41
    Results | Other Polls

    Related Links
    o MindShareW are
    o Also by Speare


    Display: Sort:
    Experiment: MindShareWare | 15 comments (15 topical, editorial, 0 hidden)
    good idea (4.33 / 3) (#1)
    by Delirium on Sun Jun 24, 2001 at 04:35:03 PM EST

    I like this idea, because it allows users to steer project development in some sort of reasonable way. Up until now all I've seen is "well if you want a feature that's not here, I'll be happy to implement it for you at my normal contract wages of $50/hour." Well obviously no user is going to pay you $200 to add some features to your Napster-clone, but they might well pay you $10 or $20.

    Multiple Bids (5.00 / 2) (#5)
    by SEWilco on Sun Jun 24, 2001 at 05:14:47 PM EST

    Multiple bids should be encouraged. If many people think a certain feature is worth $10, encourage them all to increase the total by that much so as to increase the bounty on the most desirable items.

    [ Parent ]
    Java? (4.40 / 5) (#2)
    by J'raxis on Sun Jun 24, 2001 at 04:50:20 PM EST

    Why just Java? This is just going to limit the amount of people who want to get involved in it. (I, for one, despise Java -- all the inconveniences of a compiled language combined with all the inefficiencies of an interpreted language.) Why not have sections devoted to the most common programming and/or scripting languages?

    -- The C Raxis

    [ J’raxis·Com | Liberty in your lifetime ]

    a tough choice... (4.00 / 1) (#3)
    by Speare on Sun Jun 24, 2001 at 04:58:53 PM EST

    Why just Java? ... Why not have sections devoted to the most common programming and/or scripting languages?

    A tough choice indeed! I agree that there are detractions from Java, and from any other language out there, for that matter.

    The initial site just supports Java. I would love to branch out into other languages, especially if other people get into the concept. I personally am more competent in C++ and Perl than in Java, but work professionally and personally with all three.

    For two reasons, I kept to Java: (1) I don't want to put together all the extra tables and indexing and organization on the website for multiple technologies YET, and (2) I had three minor personal projects I could seed the pot with, that I wanted done in Java.


    [ e d @ h a l l e y . c c ]
    [ Parent ]
    Why specify a language at all? (3.00 / 1) (#10)
    by hulver on Mon Jun 25, 2001 at 06:48:54 AM EST

    I want you to screw this screw into this piece of wood, here is a hammer to do it with.

    Why not just let people post what they want, and let the coder specify what language they are going to do it in when they submit their proposal. If somebody says "I want a plugin for XMMS" and the coder says "here, I'll do it an Java" then he's not going to get paid.



    --
    HuSi!
    [ Parent ]

    Code reuse (4.50 / 2) (#11)
    by nicksand on Mon Jun 25, 2001 at 07:54:48 AM EST

    By specifying a specific language code reuse becomes significantly easier. Its always easier to get code written in the same language to integrate than it is to get two foreign languages to work together.

    Java is particularly nice for code reuse because it encourages object-oriented design methods (data-hiding, abstraction, etc) and because of the giant set of fully standardized libraries which come with the SDK. The STL (C++) doesn't approach the sheer variety of services which the Java libraries offer.

    I think projects should be specified with what languages (either a particular one or a set) they should be written in, unless the author truley doesn't care. Otherwise, you'll end up getting submissions in obscure languages like Haskell.

    [ Parent ]

    Sounds a lot like the ill-fated SourceXchange (4.20 / 5) (#4)
    by Trepalium on Sun Jun 24, 2001 at 04:59:12 PM EST

    It seems that it'll be fairly difficult for such a site to remain self-sufficient since it's unlikely that very high bids will ever be made, or you'll have to take a very large amount of the money for administrative fees. While it isn't a bad idea, it will not be easy to make it work.

    Not really (4.50 / 2) (#7)
    by John Milton on Sun Jun 24, 2001 at 06:39:14 PM EST

    I'm sure you won't see phenomenal bids, but it could be very profitable with mulitple bids. Someone asks for a certain feature. They offer $10 to see it done. A lot of other people like the idea so they each offer $10. It's really a good idea.


    "When we consider that woman are treated as property, it is degrading to women that we should Treat our children as property to be disposed of as we see fit." -Elizabeth Cady Stanton


    [ Parent ]
    Classic Jewish Tale (4.33 / 12) (#6)
    by QuantumG on Sun Jun 24, 2001 at 05:15:52 PM EST

    There once was a taylor who moved to the South and opened a store. The Klu Klux Klan got wind of this and sent some children to yell nasty names and curses outside his story. The taylor saw that these children would drive away his business so he quickly dashed outside and said to the children "I will give each of you a quarter to keep swearing at my store." The children happily agreed and took the money. The next day they came back and the taylor said "oh, I'm afraid the quaters were just for yesterday, today I will only give you a dime each." The children were a little upset but they took the money and kept swearing. The next day the taylor only offered them a nickle each, half the children left but the other half were happy to swear at his store for a nickle. The next day even more children gave up because the taylor would only pay them a penny each and on the last day none of the children would swear at his store because the taylor refused to pay them at all.

    Gun fire is the sound of freedom.
    Compare/Contrast Other Free Software Funding Ideas (5.00 / 3) (#8)
    by mlinksva on Sun Jun 24, 2001 at 11:41:55 PM EST

    The Free Software Bazaar run by Axel Boldt may have been similar, unfortunately it seems to have disappeared.

    Chirstopher B. Browne mentions a number of related ideas in chapter 4 of his Linux and Decentralized Development.

    Chris Rasch has an interesting and sophisticated idea in The Wall Street Performer Protocol: Software Completion Bonds To Fund Open Source Software Development, recently published in First Monday.

    There are also of course a number of project-for-hire websites, eLance comes to mind.

    The Free Software Business mailing list would be a good place to announce get feedback on your service.
    --
    imagoodbitizen adobe unisys badcitizens

    Not a bad idea (4.00 / 1) (#9)
    by cthugha on Mon Jun 25, 2001 at 12:26:30 AM EST

    At least, that's what I think based on very little knowledge of other attempts at this sort of thing. There are two potential difficulties that need to be overcome:

    • Making it profitable, or at the very least sustainable. There are two ways to do it. Either charge a commission on top of the fee for each project, or demand the cash up front (or before the start of the project proper) and try to earn money off the interest it earns in the bank, or judiciously invest it, until it's time to pay the developers.
    • Legal enforceability of undertakings. Contracts, basically. No-one's going to cough up a fistful of dollars without some guarantee that they're going to get what they paid for. I have some ideas on how to make this work, but basically you need a contract with the client, and contracts with the developers so that both you and the client can "point the legal bone" if somebody fails to fulfil their obligations. Of course, this raises issues related to establishing and proving the identity of the people you're dealing with. Get professional legal advice before going ahead.

    Add project hosting and developer resources, and you might have a goer.



    Small potatoes (none / 0) (#14)
    by markpasc on Wed Jul 04, 2001 at 10:06:24 PM EST

    What set MindShareWare apart in my mind when I saw it was its simplicity, part of that being small sums for small projects. The starting projects are gears to plug into a larger machine--I certainly doubt anyone'll find it interesting or worthwhile to play around with an icon field widget by its lonesome. I haven't minded tinkering for basically a weekend to come up with what I've written.

    The small amounts of money (no "fistful of dollars") and work involved sets the bar for sustainability relatively low, and anyone who would want a formal contract for such a small investment on both sides is missing the spirit of the thing. If there were a time budget involved, things would need nailed down more. The qualities setting MindShareWare apart from the other mentioned programming-bounty works is precisely that openness and looseness.

    [ Parent ]
    Thought about that after I posted (4.00 / 1) (#15)
    by cthugha on Sat Jul 07, 2001 at 06:03:38 AM EST

    Yeah, I suppose it wouldn't matter that much for a small site, although the original idea started me on a train of thought that led to bigger things.

    However, you might find that if you have an individual offering even a small amount of money for a project (say $150), that amount of money is quite important to them, and they might want some guarantee that you're little guild (for want of a better word) will pull through, or refund them if it doesn't. Neighbours do fall out even over such small things. You may also run into problems if you start doing work for community organizations (probably the kind of clients most likely to turn to you, IMO, given that individuals don't need custom software solutions, and large commercial orgs will turn elsewhere).

    It's something you should think about, at any rate.



    [ Parent ]
    Different? (none / 0) (#12)
    by interiot on Tue Jun 26, 2001 at 11:53:33 AM EST

    What makes this different from the many other open source matchmakers?

    SourceXchange (none / 0) (#13)
    by mbrubeck on Tue Jun 26, 2001 at 06:08:45 PM EST

    Most importantly, what makes it different from SourceXchange? SourceXchange was almost exactly like your MindShareWare proposal (aside from the Java requirement), and in fact was one of the most visible and well-known of these services. Until three months ago, when it shut down because "it simply did not achieve the volume of business necessary to maintain the site and evolve the offering to meet the needs of sponsors and developers."

    [ Parent ]
    Experiment: MindShareWare | 15 comments (15 topical, 0 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!