Become a fan of Slashdot on Facebook


Forgot your password?
The Almighty Buck

Upside on CoSource's Leap of Faith 82

Chris Fischer writes "Here's a great article on UpsideToday about, entitled CoSource's Leap of Faith: Bridging the gap between open source and the free market. This positive article offers insight into what CoSource is about, what they've been doing, and their goals for the future. "
This discussion has been archived. No new comments can be posted.

Upside on CoSource's Leap of Faith

Comments Filter:
  • by Travoltus ( 110240 ) on Wednesday December 08, 1999 @10:40AM (#1474428) Journal

    I patented the idea of collaboratively funding open source software development through e-commerce.


    Warning: Travoltus has obtained the Rampant and Uncontrollable Patenting of Everything I See Patent.
  • classic... I write "this post _is_ off topic", referring to the original post (marked "flamebait"), and _my_ post gets marked as off topic. Once a post has taken a discussion thread off of a main topic, subsequent replies to the now-off-topic-topic should not also be marked off-topic. Dammit. And that original post should have been marked as off-topic, not flamebait. Meta-Moderators, give me justice!
  • by jd ( 1658 ) <{moc.oohay} {ta} {kapimi}> on Wednesday December 08, 1999 @10:54AM (#1474431) Homepage Journal
    First, there's an excellent article on which documents a psychology study on how much of a dis-incentive "incentives" are. If this report is anything like accurate, it blows the entire basis of CoSource out of the water.

    However, it's not all doom and gloom on the horizon for this pet project. IMHO, there -are- sectors of the programming market which coders are not efficient at getting to, through volunteer work alone. The key word here is "efficient" - coders can do ANYTHING, given enough time. Even write document, and add comments! It depends on how long you are prepared to wait, though. It can be better to pay some pleb to do all the grunge work, instead.

    Second, throwing money at a project doesn't make any difference -unless- it's: (a) targetted, (b) a useful amount, and (c) spent flexibly, AS NEEDED, rather than at some accountant's whim.

    Open Source doesn't need money. Money needs Open Source, though, and Open Source -can- be encouraged to take advantage of any resource.

    As Humpty Dumpty said to Alice, "It's a case of who's master, that's all."

    P.S. Talking of commercial minds and Open Source, the source code for Ian Bell & David Braben's "Elite" has been posted on Ian Bell's homepage. Now, -there- is a project that deserves money & programmers!

  • by Chalst ( 57653 ) on Wednesday December 08, 1999 @10:54AM (#1474432) Homepage Journal
    It seems to me that the main difficulty is deciding whether code
    satifies the requirements of the contracting party. I remember this
    issue being hashed out in previous slashdot discussions, and I don't
    recall ever seeing a good system proposed. How does one arbitrate a
    dispute where the programmer maintains his code is up to scratch and
    the contractor says it is not? If one doesn't get this right then
    opportunists could potentially swamp any good work done under the

    An idea that doesn't solve the problem, but at least has the
    potential to limit abuse is to associate with each coder and
    contractor an `employment profile' which lists the contracts offered,
    code supplied and any disputes that may arise. Coders and contractors
    with a long history will build up trust, and so not suffer by
    association with opportunists.

  • by Anonymous Coward
    This may work for people who live in areas with low salaries, like the Russian guy.
    But for a lot of people in the Western countries the sums payed are just not enough to interest them. Except of course if somebody already wanted to do a project even without getting payed.

    In any case, I do not really see that this will have a big impact. It's a nice idea, but not more than that.
  • OK, personally I think that comment should have either been left alone, or moderated up as "Funny." (Although I didn't feel quite so strongly as to waste a moderator point on it :-)

    But, if you feel the need to moderate it down, then PLEASE use an appropriate reason. That post was clearly "Offtopic", or even just "Overrated." I honestly cannot see how anyone could read that post and consider it "Flamebait."

    (I'll now go beat myself about the head with a hammer as punishment for getting sucked into the whole "bitching about moderation" thing.)

  • Reading the article, I have gotten the impression that if a non-developer wants something fixed, only-then they would pay the developers to fix it.

    The article said that without an initiative, independant developers are lazy.

    What happened to the motivation of coding just for the self-pride in "I did this"?

    It seems that a move towards this "co source" idea would make current open-source developers become more lazy unless they get their monetary incentive to fix a bug. I can see developers finding bugs, and just leaving them as if they don't exist, until someone is willing to pay them to fix it.

    Now.. the idea of making money is good for most people, but bridging open source with commercial is bad.

    There are other ways open-source developers can make money coding.. possibly work for a company that develops open source products and gets payed in tech support (such as Red Hat)..

    Maybe this is a hidden ploy by M$ to crash down linux from behind.
  • Yes, but I have recently purchased the Copyrights to all of the legal forms that you will be needing when you file your patents.

    When can I expect to recieve your payment?

    (If you're really planning to patent everything you see we could probably work out some sort of bulk purchase discount on the forms you will be needing.)

  • by Anonymous Coward
    The article's here:
  • I think that the model for developement that CoSource can become a very viable template for *small-scale* open-source projects. It's really great for bringing together users who want a specific application built and developers who can receive financial compensation for their work, as well as contributing the code back to the public by open-sourcing it.
    The economics of open source software in general can be fairly accurately modeled as a "public good", or to use economic jargon, a product with zero marginal production cost. Much like building a dam or interstate highway system, developing software takes a great deal of work; at the same time, once the product becomes open source, people who did not directly pay to have the product constructed can still use it. Now this is a good thing, as it wouldn't make sense to restrict use of a public good when the ammount is practically unlimited.

    CoSource allows people who have a pressing need for a product to explicitly finance the construction of the good, while benefiting every other use of open-source software at the same time. As good as this is, I can't help but think that CoSource is not neccesarily the best model for large-scale distributed developement of an application over a long period of time for the following reasons:

    -The model does not faciliate interaction between developers in a public forum (as in a mailing list or newsgroup)
    -There is no official or centralized location for users to report bugs to
    -There is no method for coordinating the work of different groups that could potentially be working on similar projects
    -Oversight is limited in that I don't see any real mechanism to *force* a recalcitrant developer to fix a problem
    -The model does not facilitate the dialogue between users and developers that is particularly helpful in refining an open-source project
    -The model implicitly precludes long-term projects (ie. we met the objective to the letter, and now let's get our money and stop)

    I don't think that CoSource can work for something like Apache or Mozilla, but it does have a lot of potential for less ambitious projects, such as a mail client or an addition to existing open-source software.

    Flames? Think I'm a karma whore?
  • Personally, if I'm going to contribute to Open Source (and, one day, I will) I'm going to do it for a specific set of reasons, which are:
    • There's a feature I want that the program in question doesn't have,
    • There's a bug I don't want that the program in question does have,
      And finally,
    • I use an open-source OS with a rather large number of open source tools. While I'm not obligated by law to give anyone anything for this, I'd like to give back to the people that gave to me.

    For me, money's not an object. I'm most likely to give back to something that I use a lot. I'm not so great with the kernel, but maybe I could add something to WindowMaker. If there's a project I want to be involved in, getting involved is as easy as looking at the TODO list and going out and doing it.

    Of course, I am not everyone. For those who will get paid nearly three times their monthly income for a project, this is a godsend. For others who just like the extra cash, it's not too bad either.

    Because of this, I don't think offering money will affect the general direction of open source at all. People who were writing code because they wanted to will keep doing it, and people who were writing code for money will keep doing it.
  • [yes, it's bad form to reply to your own comment]
    I also meant to add that the market system upon which the existence of CoSource is predicated is less than optimally efficient in the case of externalities, whether positive or negative, such as that presented by open-source software. The free market cannot acheive maximal allocative efficiency because the cost of the goods produced and the cost for producing the goods does not neccesarily correlate with the benefits and/or hinderances obtained by purchasing the product.

    Flames? Think I'm a karma whore?
  • It seems that a move towards this "co source" idea would make current open-source developers become more lazy
    I don't think so, mainly because co-source will never represent more than a tiny fraction of open source programmers. What it will do is to help those programmers (like our Russian chum) who wouldn't ordinarily be able to afford such largesse, while most (western) programmers will go about their business as normal.

    If a programme develops bugs, the developer isn't going to hang around waiting for someone to pay them to fix it. Once word gets around that a fixable bug has been extant for a certain time, people will just stop using the software. Or, more likely, someone else'll take over the code.
  • Personaly I feel the overall aims of cosource are a good one, I'm total advocate of open source and I'm also a total advocate of me having stack loads of cash. Exactly how the two can be made to work together is a different matter but I'm working on my own ideas.

    The writer (or the people the writer is quoteing, it's not all that clear) claims "Without some system of monetary incentives, crucial gaps in the open source landscape -- such as applications and user documentation -- would never get filled.", this is not enirely true. The various documentation projects on linux may not be a shining example but a quick look at Apache [] will show you how it can be done. Not only do the programmers contribute documentation but many of the supporters who are not programmers feel that this is the way they can contribute.

    After looking at the cosource website I get the feeling that it's more the article writers objections to open source rather than those of cosource that is showing through

    The idea behind this seems to be to find one or more people in group 'A' who need something, then find one or more programmers in group 'B' who feel like writeing it and get 'A' to give 'B' some cash. Good plan in the long run, i'll be watching this site carefully in the future.

    The biggest problem with this is the commercial notion of reward, I do things for free that would cause me to laugh if anyone offered me less than several thousand to do. An example of this from the CoSource site is " Request: 3-D modeller with cartoon mode, First, I want an open source 3-D modeller with skeletal animation for X (or crossplatform GUI lib). This may or may not already exist, and building on an existing modeller to add skeletal animation etc is of course OK. But a cartoon rendering mode should be added [snip]" and the grand sum offered for this? $200, I guess the point is that if enough people offerd $200 then the project would get financed. However I'm already working with some other people on a project along these lines, I would not however want to get involved with anything like this unless the cash amount was really significant.

  • I think this is a great idea for a number of reasons which I have listed below:
    1. Pumping a little money into OpenSource may be just the edge to give most projects a little polish. Giving developers an *excuse* to expend for commercial tools (example: photoshop, CodeWarrior for linux etc...)
    2. Just becuase money might be involved doesnt mean ppl will do it for solely for money. It would be pointless to program opensource exclusively for money, commercial outfits pay far more in comparision.
    3. This monetary incentive might allow some developers to cut some hours from regular (e.g. commercial) work and spend that time on opensource projects.
    4. I highly doubt that the quality of opensource would go down. There are still two factors that govern the quality of opensource projects. One is that most programmers have hubris, and their code is going to evaluated by their peers. Two is that opensource projects are rarely done by one person.

    This is the one concern that I have. Would this interfere with the GPL licensing in anyway, and what about project deadlines? Opensource usually doesnt have project deadlines. Would this allow penalize developers who dont *ship* on time. Lets hope it doesnt become just another boring job.

    One last note. I am constantly surprised by the quality, and vitality of many opensource projects :)
    Keep up the good work.

  • Forget the money; Cosource is a good place to share ideas. I wanted my voice modem to answer my phone, take a voice message, and email it to me at over my DSL line. Cosource gave me a forum to share the idea, and lo and behold, it eventually reached a programmer who both likes it and is willing to do the work. The program [] is now being written under the GPL for linux. This is great! (Also, I wouldn't have known where to best share such an idea before Cosource. It way beats asking your officemates.)
  • aha! the most interesting part of the article. soon we will have more bangalore-type enclaves within the third world where people are doing development at a third of the salary of U.S.-based engineers. Of course for projects which are not as clearly spec'd out these guys won't be as userful but i definitely expect basic programming to begin to get farmed out more and more...
  • Perhaps such (inevitable) disputes should have their own section on the site. Developers and users would be motivated to go there out of boredom and morbid interest. Once there, they would be encouraged to look at the facts and send opinions about what remains to be done, if anything.
  • Look, I sure don't know what the whining is about.

    It's probably mostly about the fact that it's been a really long day and I'm in a crappy mood. :-)

    It still seems to me, though, that if we're going to have different moderation categories, folks should make a reasonable attempt to apply them appropriately.

    The other thing about moderation that annoys me is that a lot of topics now contain more posts bitching about moderation than commenting on the story. And here I am contributing to that. Hmm... I'll shut up now.

  • I noticed a lot of people saying this is a bad thing. The point out that most of the development is done by people that are not interested in the money and therefore if money is offered these people will back off of development.

    Personally, I think this is bogus. I'm working into development under the Linux platform after several years working on the operations and management side of the business. I've decided that I want to do developement that is what I enjoy.

    So does that mean I am taking work on Co-Source? No, I look through the lists and see if there is anything I've produced or could produce quickly that would allow me to make a few bucks, but what I am using it for is small portions of code that I need developed to go into my bigger application.

    Not sure if that is too clear, let me give a further example. I have a project I am currently working on that requires some Windoze coding. I do not know enough about Windoze in order to do the work myself, though I know that the actual implementation of the code would not be very difficult. My project requires this code, so I have a couple of choices. I can open the project prematurely and hope to attract a windows programer, ala netscape, or I can hire a windows programer to write the code for me. Now, the chief problem with both methods is exposure. How many windows developers do you think read freshmeat? I would say few. So I see this as a way of giving a few bucks to a program to create a basic design which I can build apon. Further, if the programer is really interested in the larger project I am working on, he can join the group after he develops his small bit of code.

    Co-Source is more than anything like a discussion group where people can talk about what kind of things they would like to see. If someone has to make a choice between doing some extra work to make some money, or working on a open source project for a little cash this method offers incentive or at least tips the scales in our favor.

    Furthermore, say I have a neat idea. I don't have the knowledge to implement or to have it developed myself. But if I post the idea and others like the idea as well, they can help me pay for it.

    Collective bargaining, seems to me I've heard that phrase before. Now whether you like unions or not, the fact is collective bargaining gives a group of people more power than any single person.

    Ok summary. I think that for a lot of the small developers out there either commercial or open source, myself being the latter, can use this method to get pieces of code done. Also this is a site where people can interact with each other to help out a developer financially without having to finance the whole project themselves.

    Look, if I want a network driver supported by Linux it would cost me a lot to hire someone to have it done. I could wait for someone to do the work and I might even notice when the work was done if I watched the news groups. But if I can post the request and put in 20 dollars and 50 other people like the request and put in 20 dollars each. The developer gets enough to feed himself this week and Linux gets a new driver.

    If you think this is a bad thing, that's fine with me, but personally I think this is a good idea.


    PS. I like cosource much better than SourceXchange because it empowers the comunitee to make small donations to developers and push our own ajenda. SourceXchange is for the big boys to push their ajenda because there is only 1 sponsor for a given project. But both will produce GPL code for the entire communitee to use and I fail to see that as a bad thing.
  • First, there's an excellent article on which documents a psychology study on how much of a dis-incentive "incentives" are.

    GNU reports a trivial observation: that people doing something for the love of it do better than people who are just doing it for the money. Yay rah. If we use this as our mantra, then instead of hiring people to clean toilets, we should just ask for people who just love cleaning toilets to do it for us. It isn't going to work, is it? Even if there were sufficient numbers of people who actually enjoy cleaning toilets, those people have to make a living, so instead of dropping into our bathrooms, they'd have to get another job to make a living.

    I enjoy programming, or at least some aspects of it. But in the meantime, I've got to eat. So unless there's some other way to get me what I need to live on, I'll need to trade a huge hunk of my free time for a salary. Fortunately I still get to do something I usually enjoy doing, and thus will do more than necessary for the paycheck; unfortunately, the people paying the salary may find that they need to do things like close the source I create in order for them to make a living.
  • You know, back in the day this was actually a pretty common thing. My boss was telling me some story of how 20 years ago, if you needed a specific program, you'd call up a company, they'd write you the code that you specifically needed, you paid them for it, and they gave you the code. The code was yours. If you wanted them to fix a bug, you'd pay them again. Is this really any different?
  • Wow, that was pretty original. Hey, while we're at it, I've patented all sarcastic responses to stupid uncreative posts by retards.

    Can we just give the "I patented X" theme a rest? It was only funny the first couple of times... Now it's about as welcome as "Imagine a Beowulf cluster of those!"


    "You can't shake the Devil's hand and say you're only kidding."

  • Look at it this way:

    Open Source developers use Open Source code. They give back to the community by writing more code - often to solve problems they need solved.

    Non-programmers also use Open Source code. CoSource potentially offers a way for non-programmers to give back to the community by sponsoring development of more code - generally to solve problems they need solved.

    It fixes an asymmetry in the Open Source model, one that (I speculate here) could potentially do a lot to expand Open Source's appeal as a general model beyond the programmer community.
  • A better system than CodeSource (IMHO):

    1. Customers who need software post requirements to a web application.

    2. Developers submit a proposal with features and milestones and a bid, potentially leveraging the fact that multiple customers have similar requirements. The bid is to a pool, not an individual customer. Customers save money dividing the cost equally. The proposal does not have to meet all the requirements- as long as the proposal is accepted by the pool of customers.

    3. During the project, some respected third party reviewer elected by the pool and approved by the developer is responsible for ensuring that the developer has lived up to the milestones they have stated in the proposal.

    4. After the pooled work is done, customers can re-pool to complete additional requirements not met by the original proposal.

    If 50 customers wanted a GUI admin interface for Apache, $500.00 apiece results in $25,000.00 pooled to develop the code.

    I find the reverse auction approach to be too top-down to attract good developers into this model. Top-down work is easy to come by at high rates for good developers- why should the subject themselves to this model.

    Letting developers propose the scope of the project they are willing to work on puts the developer in the driver's seat, which is a more coveted position, and is more likely to be preferred by developers to top-down contractor work, which is one of the primary ways that open source developers make a living.

  • only the pronoid [] survive..
  • The company I work for writes Mortgage Origination software for lending-banks in the US. They've been doing it since 1978 (Wang Minicomputers ) and so they still work "old-style".

    If one of our customers needs a feature, they call us up and we quote them a price. Each customer has their own seperate system of code. If a feature is good for everyone, it get's moved into the generic system, and everyone get's it on their next update.

    Personally, I think it's extra effort and more complexity, but my boss has been doing it this way longer than I've been on this planet, so I let it be. Still, it's an interesting concept.


    "You can't shake the Devil's hand and say you're only kidding."

  • My boss is looking to retire and in a very real sense, he *is* the company. There's a bazillion lines of old Wang-Basic2 code that no one but him understands.

    What he's been trying to set up, is having our major customers (a number of lending-banks) pool their resources and buy out the company. Then they could hire a team of programmers to go through the code and document it (if at all possible). Otherwise, when he retires, the company ends and all the banks are left with unsupported software.

    It's an interesting idea to have individual customers pay a certain amount to get a desired whole... Almost like Schnier's street-performer protocol, eh?


    "You can't shake the Devil's hand and say you're only kidding."

  • I would tend to agree that these incentive programs don't really lead to getting more code written. The reason why open source rocks is because the person who writes it actually cares about the quality of every line (or they should anyway...), not because they are getting paid to create something that adheres to some design specification with X% acceptable error rate.
    I have a bit of experience with CoSource's rival, sourceXchange, which is where i base my opinion on projects of this nature. There are differences between the 2 (sourceXchange seems to just have projects from HP for instance) but the concept is the same. I submitted a proposal for a project at sourceXchange, there was a few respones i got back from HP about it for a while, then the whole sourceXchange site just sort of went into sleep mode for a month or 2, or something. I had read quite a bit of HP's documentation on the software the sourceXchange project was to be based on, and it was fairly interesting. Interesting enough, that if it wasn't for the "incentive" of $20K for the person who got the contract i would have probably just written it and submitted it to the public. I just sort of forgot about sourceXchange after months of no visible activity on their site, then suddenly i got several emails saying that they were going to finally award the contract. I went back over all my notes, submitted another proposal to take into account the changed time schedule--then heard nothing. A few weeks later the entire sourceXchange site has a totally new "look", complete with a new list of projects! What the hell happened to the old ones that everybody put proposals in for? They just disappeared, nobody got them. I wouldn't be so pissed about it if they hadn't told me a couple of weeks before that they were going to assign the projects.
    I wouldn't be pissed at all if they had said, "Hey, can somebody write some software for us in their spare time? We can't pay you but we'll credit you as the author." I, or somebody else, if interested would just write the damn thing.

    Documentation is another issue though (and i mean more than a cryptic message commented out in your code, real documentation like a user manual or API reference), i think that would have a much higher chance of success in this incentive model than software.
  • Two things.

    First, I hope these "judges" police extreme code sniping in cases where the sponsors are unaware of an existing partial solution. If a 90% solution already exists from thousands of man-hours, is the lucky sot who comes along and spends five hours implementing the final feature they need deserving of the entire reward? I don't know. Part of me says "the original developers should have been quicker on their feet if they wanted compensation", and the other says "but it doesn't seem fair".

    Second, I think the author touches on an excellent point regarding how this method of code economics bridges entire global markets. There is a world of coders out there that will work for sums that a coder in the states or Europe would not touch (at least in cases where financial gain is the main incentive). This will persist until there is an equalized global economy -- sites like CoSource are conduits that bore straight through economic dams.

    I'm all in favor of that. Pay rates will shift on both sides of the equation, and once equalized, coders will have to compete based on quality. That's a good thing.

  • If I may be so bold, what was the bit of software they wanted written?
  • This is great! I've heard about this for a while but seeing it in action is awesome. We'll have to wait a while to see how it pans out, but it looks good.

    This is where you go to have your itch scratched. Or where you go to get paid for scratching someone else's itch.

    Peruse the listings and you'll see small projects, large projects, KDE enhancements and Gnome enhancements, drivers and filters and full blown applications. Even if you can't program you can get paid for writing documentation.

    The economy is changing and we are witnessing the birth of a new paradigm. Free Marketeer suits meet collectivist radicals and put laissez faire anarcho-socialism into practice.
  • by Frater 219 ( 1455 ) on Wednesday December 08, 1999 @12:12PM (#1474464) Journal
    Free software doesn't need to be made into a part of the free market -- it already is a part of the free market. The "freedom" of the free market is non-coercion: a free economy is the opposite of a command economy, in which economic activity is controlled through the use of force by the government.

    You can have a free market without money exchanging hands: for instance, a barter economy or a gift economy. Provided that the economic acts of individuals -- the creation and exchange of wealth -- are not restricted "from above" by a government or similar entity, the market is free.

    Already free software is competitive against proprietary software in the marketplace: consider the case of Apache vs. MS-IIS for instance. Is a user's choice of Apache over IIS a choice made in a free market? Of course it is. It is a choice made, after all, without coercion. The user picks the Web server s/he will use on the basis of price and performance (with the latter including support, stability, &c. as well as speed). This is economically a free-market decision.

    So why in the world would someone characterize the CoSource effort as moving free software into the free market if in fact free software already is part of the free market? I'd say it was out of fear of free software -- the old misguided Red-baiting, in other words. Unfortunate, that.
  • Then you're part of the problem. The categories, as you may notice, are listed by *name*, not by *quantity*. If moderation were that simple, don't you think there would just be options for (-1, +1, +2), &c.? Those categories are there because that is how the system works. Too many /.ers are moderating that have no idea what "troll" or "flamebait" means.

    OTOH, I'm all for having two sorts of moderation: One for classification, and one for level. IOW, having a drop-down box as I mentioned above, with numbers, and another with category. I've seen a lot of posts that are really funny, but by rights should be mod'ed down. I'd also like to see it listed something like (Score:5, Funny*2, Informative, Insightful) so that we know *all* the moderation, not just one of the categories chosen.
  • I wrote:
    First, I hope these "judges" police extreme code sniping in cases where the sponsors are unaware of an existing partial solution. If a 90% solution already exists from thousands of man-hours, is the lucky sot who comes along and spends five hours implementing the final feature they need deserving of the entire reward? I don't know. Part of me says "the original developers should have been quicker on their feet if they wanted compensation", and the other says "but it doesn't seem fair".

    I should add, that this could be considered a necessary evil. On the one hand, code sniping could occur, but on the other it would be excellent preventative medicine for extorters sitting on known bugs in their code.
  • I think this is a great idea. Linux, and most open source software is built by and for computer geeks. That is, it's the kind of software that if it didn't exist, a developer would write or buy for internal use. This is a vast oversimplification, of course, but it's true to a degree. It's not that programmers only write programming applications, but that when you're considering a project, you probably aren't going to get involved in a project that you wouldn't use.

    Can you see an open source "Print Shop"-like program? Sure, you can say "But we have TeX, print shop is inferior." Yes, it is, but Print Shop is usable by grandma who wants to create birthday cards for the kids, while the Gimp and LaTeX really aren't.

    I don't think Cosource would actually generate low end consumer software like this, but there would be more software in that direction -- usable by people who aren't computer geeks. Some examples of what I think could come out of this:

    Tools for graphics professionals. We have the Gimp (which I must admit I haven't used), but it would be great to have a good vector drawing program, good animation programs, and stuff like that. How about a rendering package that doesn't cost thousands of dollars? The cost to develop these (time-wise) may be too high for people to do it for their own use, or just for fun, but maybe there are people out there who would sponser it.

    Handicapped accessibility software -- like rendering software, the cost to develop is high for the number of people who would actually use it. There's a number of foundations and charities out there who would put up money to getting free software to make it easier for e.g. the blind to use computers.

    Software drivers -- maybe internal development works too, but maybe it could be done cheaper in open source. Or perhaps the company doesn't want to develop drivers for X high-end sound card, but there are people out there who have the card, and want to use it, but don't have the skills to write a driver.

    Niche apps -- companies that make VR glasses can't sell many of them if there isn't software to use them. On the other hand, an app isn't likely tied to a single system, so it might make sense for makers of VR equipment to support a project to develop some sort of VR chat software. There are probably other similar cases, but VR is the one that came to mind.

    I'm a big believer in the power of the free market. Ronald Coase got a nobel prize for demonstrating that one of the limiters on the free market is the cost of making transactions. Cosource provides a system for allowing some of these transactions, so is a definite plus.

  • by Anonymous Coward
    The basic model of CoSource isn't terrible, the idea of bringing together people who need certain software and OS developers is a good idea, but the implementation is just ridiculous. Has anyone taken a look at the ridiculous amounts being posted on their website?

    If you really need something added to wine, contact one of the Wine developers and offer to contract it. It's that simple. There's no need for a middle-man. But you aren't going to get highly skilled programmers for pennies an hour.

    Pooling requests would be reasonable, since that would get the money amount up, but CoSource doesn't seem to be focused on that.

    There's this ridiculous idea in parts of the media that things like Linux, Apache, gcc are written by part-time hobbyists. That's absurd of course. Some of the best programmers around work on these projects, and the idea that they can be hired at $5-an-hour is a bit insulting.

    Personally, I found the line about offering $1000 to enhance kdevelop kinda sleazy. Why not GIVE the money to the kdevelop team, you just got a complete IDE for free.

  • They wanted Java RMI code to work with the HP e-speak product.
  • As evidenced by the work of all of the Opensource programmers working for the likes of Transmeta, RedHat or Corel, 'greasing-the-wheels' with a little cash works great! We have new, open-source installers, Wine is going much faster than anticipated, kernel development is at an all time high in terms of quality, polish and development speed, etc..

    The best part? It doesn't matter one lick to the GPL, although Stallman might have a few words about it.
  • by Arandir ( 19206 ) on Wednesday December 08, 1999 @12:25PM (#1474471) Homepage Journal
    "First, there's an excellent article on which documents a psychology study on how much of a dis-incentive "incentives" are."

    That's one report stacked up against thousands. It's also contrary to reality. What exactly do you do to acquire money to exchange for food, clothing, shelter, bigger monitors and ethernet cards? It's all incentives whether it's labeled as money or not. If you employer pays you little but you greatly enjoy your job, you may decide to stay. But if someone offers you more money for doing to same work across the street, you'll certainly think about it.

    Hackers like to hack. Give a hacker the choice of programming for $75,000+ a year, or waiting tables for $12,000 a year, and you'll see how powerful incentive is. Now give them CoSource and the opportunity to pick and choose the projects they're interested in and odds are they'll jump all over it.
  • The thing these contracting models promote is single purpose utilities to perform a specific function for one company. You won't see any more of the Microsoft Office, SoftImage, monoliths of C++ coding and bottomless pits of features. There are really two groups of users: ones who like bottomless pits of features and ones who want single purpose utilities but the question remains of who there are more of.
  • This does indeed sound like a good resource to share ideas, which is what open source needs. They ought to make a seperate section for coders working for free who can "bid" on a project not for cash, but simply to let others know that they have started something like this or to recruit other developers. It might help reduce redundant projects. In an idealized state it would allow developers who are working on similar projects, unbeknownst to each other to pool their resources, check out each others' code, and say "oh wow, this guy accomplished this much better than I did, but I have this functionality which I could add in to what he's doing". Also it would be good for budding programmers like me who want to get involved in developing OSS but don't really have a project of their own that they want to work on. If sites like cosource have this kind of dual functionality, then they will be promoting open source in general and not just the compensation of developers for a few projects.
  • Your problem is really trivial to solve - vgetty does this type of thing. If you're looking for an easy interface so you can program it, Perl's your tool. Take a look at Modem::Vgetty at Believe it or not, included in the tarball is a ~20 line script that will e-mail an audio file phone message to you. This is the typical problem with CoSource. It's not a list of problems that need to be solved, it's a list of problems whose posters don't know the answers. Anyone that thinks this kind of "contract work" is going to help the community is mistaken.
  • But usually customers really don't know what they want until they see it. Sure, we can all say we want an Excel-compatible spreadsheet for Linux or an open-source spreadsheet, but no customer had the foresight to request a spreadsheet in the first place.

    So, in the real world, some developer with an idea has to take the risk of six months to a year unpaid labor to implement her vision. Maybe people will care and maybe the idea is garbage. Look at how many games don't even make back their development costs.

    Even if she posts her idea, how many companies will take the risk of funding the idea? I'd guess not many want to take that risk. Companies would much rather wait to see the final product. So the developer will take the risk, not the customer.

    But if the developer takes the risk herself, how will she recoup her costs? Remember, we're talking about people who program for food, not students or people on grants. Also, if the probability of success is 10%, she'd need get 10x her opportunity cost for a success to break even.

    I've rambled, but my point is that both CodeSource and your amendments neglect the added cost of the risk of software development. And, in your example, $25k pays for about 3 months of development time assuming no risk. It's not a good deal.
    Scott Ferguson

  • The sourceXchange people just sent out a letter on their developer list explaining their activities, it starts out:

    "A lot has happened since we last communicated; that's our fault, as we've been waiting for just the right moment to contact you again. That time is now."

    Mighty funny how this got sent out 2 hours after I put my other message up, but maybe i'm just reading too much into it. A company based on Open Source software development reading the comments on an article about their arch rival on /., the place most likely to catch the eyeballs of OSS developers--no, that doesn't really sound that likely.

    Well, they're trying anyway...
  • But for a lot of people in the Western countries the sums payed are just not enough to interest them

    I disagree. I make a decent living, but I sure wouldn't mind a few hundred bucks to finally buy my Lego Mindstorms or a new Athlon.

    I'm surely not going to quit my day job for these projects, but for people who *enjoy* coding in their spare time, why not get a little extra spending cash

  • The CGI Resource has a similar project going for this. Every so often I get emailed a list of the new CGI toys that developers have released as well as some of the CGI Apps that people want developed and how much they are willing to pay for them.

    Here is an extract from the mailing list from []:

    Programs and Scripts: Perl: Searching: Searching the Web:
    MP3 Search
    Version: 1.0 - Released: 11/29/99 - Free - Unix
    This script searches 14 of the most popular MP3 search engines.
    It's easy to set up, and it should bring you quite a lot of visitors.

    Programs and Scripts: Remotely Hosted: Postcards: Post Cards
    Released: 12/3/99 - Free
    A free, remotely hosted post card script. You can customize the look to fit your site and even upload images and midi files for users to choose from.

    Script Installer
    Company: M. Samuel
    Description: I'm trying to develop a network of websites, and I need a script installer for CGI script instalations in two locations that I have now, and three that I will be developing later this year, and early next year. Please contact me for more information.
    Requirements: Experience with Perl, C++ and Java. Must be comfortable with NT and Unix based servers

  • I agree. That was by far the most interesting part of the article. And I wouldn't personally bet on the U.S. being able to maintain a creative lead either. I am sure that there is plenty of talent world-wide that would be willing to work for less than your average U.S. based engineer.

    In the past one of the things that has held up our less fortunate brethren is the lack of state of the art hardware, but that too could soon become a thing of the past. First of all, the price for an entry level system has dropped through the floor. And secondly, with the increasing reach of the Internet it is no longer necessary to have physical access to the hardware that you are programming. Any 386 will run vi acceptably. Add a modem, some tools like CVS, and ssh access to a fast machine somewhere and you are in business.

    We live in interesting times.
  • by Wah ( 30840 ) on Wednesday December 08, 1999 @02:41PM (#1474481) Homepage Journal
    So why in the world would someone characterize the CoSource effort as moving free software into the free market if in fact free software already is part of the free market?

    To get non-developers involved. There are a lot more people that use software than create it. It's moving the demand for new or special software away from only the developers and adding end users into the mix.
    Basically, trying to create an environment where a clueless end user can say "Here's $500, Scratch my itch for me." And hopefull the "free market" (via CoSource) will end up with someone who can and is willing.

    CoSource is a way to move free software DEVELOPEMENT into a more market driven (vs itch-driven) model. (and if you don't like it, don't use it, flaming me is useless.)
  • Unless you've missed the whole point of Free Software, the stuff that's released is for everyone's use. If I'm pissed that three people write me thank you notes for my software but the fourth goes out and makes a couple hundred bucks off of it, I have no one to complain to but myself. After all, I'm the one who released it under a free license to begin with. If you don't want people making money off of your code, then don't Open Source it!

    It makes no sense to tell people they can do whatever they want with your software, then turn around and shout 'exploitation' because they did what you said."

    No need to call the Fairness Police.
  • According to the article:

    "Cosource developers must wait until the end of the project for a third-party referee to approve the work before receiving full payment for their work. "
  • I didn't ask "Why should CoSource exist?". Its existence is obviously valuable. I asked rather "Why is CoSource being characterized as moving free software into the free market?"

    I believe that there exists an attitude, which I called "Red-baiting" above, which roughly claims that if there isn't money involved in a particular activity, that activity must be socialist, and therefore not a part of the free market. I think that the Red-baiting attitude is erroneous, and I think that the idea "CoSource is moving free software into the free market" is an example of the Red-baiting attitude, and is also erroneous.

    I reiterate: Free software is already in the free market, because it consists of voluntary rather than compulsory economic action. CoSource is a good thing; however, it cannot move something to the free market which already was in the free market.

    Or, in the popular jargon of a few years ago: Don't call it a comeback; we've been here for years -- but CoSource is welcome to join the party.
  • Yes, I understand your point. I was not trying to take issue with Open Source -- I was merely wondering about the dynamics of implementing something like CoSource. Though tracking down contributers is a horrible task, it would be nice if CoSource took it upon themselves to trickle down the monetary benefits.

    Two problems, though: 1) CoSource probably would never do such a thing, merely because it is such a potentially complex task, and 2) perhaps this will change, but so far the amounts of money do not "trickle" very well!

    At this point, you probably stand to make more from the generosity of companies such as Red Hat and VA Linux.

    And, of course, none of this is relevant to coding for the sake of coding.

  • Great, I'll forward your reference to the developer, which will hopefully help him fulfill the request. (The request includes a few trimmings like an rpm or debian package, a /etc configuration file, etc.) Slashdot is a pretty good place to share ideas too, and in this case I'm really glad I asked. Thanks!

    Anyone that thinks this kind of "contract work" is going to help the community is mistaken.

    I don't know about the community in general, but I think I will quite soon be happy with a working phone to email answering machine. Things that are trvial for some people are harder for others. I don't know how to program in perl, for example.

  • This problem exists with all software projects, in fact with all engineering projects.

    The only way I have seen it dealt with is by having a clear requirements document. These can only be generated by an iterative series of attempts. Sites like CoSource should consider a process like this:

    All parties agree that any disputes will be definitively resolved by a panel of experienced open-source people - NOT in the courts

    'Sponsor' submits reqs doc for developers to view

    Developers ask for clarification of requirements, and suggest changes

    'Sponsor' clarifies document, accepts changes etc (note - the 'sponsor' owns the document - only they can make changes)

    Lather. Rinse. Repeat

    A developer says 'OK, I can work with that.' I'll deliver by date X.'

    The 'sponsor' says 'Go for it'

    The project is marked as 'Work in Progress with developer {name}'

    Developer starts work, and, if needed (and it will be on a significant piece of work) sends prototypes to 'Sponsor'

    Developer says 'I've fulfilled the requirements - now pay me'

    'Sponsor' pays up

    Disputes are initially handled by referring to the requirements document.

    Remaining disputes go to the panel of 'experts', and all adjudications are published promptly (within a week of complaint?)

    I know this seems a bit formal, but it is the only way I know of delivering good software on time and keeping everybody happy. I've tried other ways, and they just don't work.

  • CoSource officially launched this week. Before was only a "Beta".

    I more or less followed CoSource more closely than you followed SourceXchange. I was afraid they were going to do the same as you described for SourceXchange. However, they started out with a "testing" period, where they said projects and proposals wouldn't be honoured. They ended up carrying over the test-projects over to the live test, as the quality of the project proposals was so high.

    A bunch of projects are already finished, and the project mentioned in the article is pretty close. (I'll have to pay!)

    And about Incentives not working, with Cosource, you as a "consumer" can tell the developpers where your priorities are. That means that small (or large) amounts of money will change hands for a change or the list of priorities.

    In the case of the CMYK project, I just don't have the time right now, and Andrew does.

  • Sites like CoSource should consider a process like this: .....

    Well said! That's exactly how CoSource works.

  • I think you hit the "nail", so to speak, right on the head.
  • If a 90% solution already exists from thousands of man-hours, is the lucky sot who comes along and spends five hours implementing the final feature they need deserving of the entire reward?

    This is what CoSource is all about: You can pay someone to go that last mile.

    The trick is that anyone is free to remark: "But this is already implemented ".

    So, a developer who submits a proposal pricing for the whole work, will get under-bid by someone who knows that 90% is already done....


  • At the moment my job is writing bespoke programs for estimating jobs in the print industry. This involves going to a customer, finding out what they want and programming a solution just for them. If they then have any problems or additional requirements, we can fix or add those as and when they want them.
  • Since CoSources idea is -old- and has been implemented on quite a few other sites (see below) for -ages- I wonder about the reason for this "sudden" hype about CoSource, Cosource, CoSource, CoSource...

    Is CoSource part of the Andover empire and needs to be pushed? Or is the OS community now also entering the Microsoftish-brainwash-type-oh-we-have-just-(re)di scovered-fire-revolution-marketing?

    Check the Free Software Bazaar for a reference
    example, open since Sept,98, (without that fancy bloatware look):

  • It seems to me that all of these "solutions" do expand the potential for Open Source -- anything that puts more of it on more of corporate America's machines should be viewed as good. But there's a lot of round hole, square peg going on. The history is clearly: I code because this is something I want or need. Witness the comments. Kickrudder is a consulting firm that works for the developers. Completely upside down. What interests you? Great, we'll find it a home. Or maybe not, but that's the aim. Work at what you want, when you want, where you want. If you don't throw up at the idea of money for effort, and you're really good, this "anti-company" might be OK. Own a piece of the iceberg. email:
  • You know, back in the day this was actually a pretty common thing.

    Er, I was doing this as recently as two years ago, and I still know many programmers that make a living this way :) All in all though, this programming style tends to be bad for the programmer. Example: I wrote an inter-office communications program for a local government (DA's) office two years ago for $60,000 (Voicemail/PBX interface, email, network fax, and a bunch of real-time collaboration tools all rolled into one). Today, that same program is in use in about 50 state, county, and local government offices across the US. By my calculations, with a little marketing that program could have made me $750k to 1m+ in the last couple years! But since the client got the rights, they now control its distribution and I don't see a dime off of new installations outside of tech support fees ($150 a pop).

    To any newbie programmers thinking of going this route in your career, make sure you maintain some source rights to the programs you're writing! Whether you want to GPL it, publicly release it yourself, or just re-use some of the source later, you'll be happier in the long run if you stick to your guns and walk away from contracts that claim full source ownership. Nothing sucks more than writing an awesome program and then being legally banned from even using it.
  • I like the idea behind Co-Source a lot, but....
    What happens to a developer who has an itch, and wants to write some software, but decides, "hey, I can put this up at co-source and see if I can get some money for it to boot!" So, the developer enters a request, then a proposal and sits back to wait for money commitments.

    Meanwhile, he isn't doing any coding......

    Soon, if money isn't forthcoming for his project, he has to decide between swallowing his pride and going ahead with coding it "for nothing", or continuing to wait.

    I guess it's worrisome that we might lose the give-and-get spirit of open source, and become a give-only-if-you-get type thing.
  • I don't think so, mainly because co-source will never represent more than a tiny fraction of open source programmers

    Hmmmm, that just seems short-sighted. We'll never need more than 640k either..... we'd never sell more than 2-3 computers..... linux will never challenge Windows on the desktop....etc, etc..

    If it's successfull, and many open-source programmers start taking in money for their pet projects, they will most likey be more inclined to get funding for all their other work too, and other programmers are gonna start saying, "well, if they get paid for doing that, I should get paid for doing this!"

    If it's successful, you can't say it will never get big.
  • If a company has patented an idea or something of that nature, and someone takes that idea and creates an opensource software. The company in most cases don't bother to sue the individual, since the work is opensource, and the individual is not making money. But when a developer gets paid, wouldn't that be asking for trouble?

    If I develop an opensource program now using GIFs, I probably will not into trouble for using the "LZW"? Algorithm or whatever it was that they copyrighted about it, because I am not making money. But now, I probably would.

    What if users requested tools specifically for something authoritiy views as bad? What if users where the ones who requested a tool as napster. Wouldn't authority have much reason to go after him for creating "evil" tools for money?

    This is a great idea, but yet, I believe developers have to be careful. Very careful.
  • This is great for coders in third world countries!
    Just think about, I will not put in 30 days to get $500 for a project. Whereas some poor guy in india, will. $500 converted over there is probably what $20,000 is to me over in US. Now, such a project is a bargain for people in places where the dollar is worth more.

  • my beowulf cluster of hot grits can petrify any GNU out there.
  • If it's successful, you can't say it will never get big.
    I'm not saying it won't be big; it could well be huge. But have a look at freshmeat and see how many programmers there are who work on one programme only; a programme that they wrote for themselves, but that found a wider audience. A lot of these people would have no interest in working on someone else's code, and have no need of someone working on theirs (outside normal open sourcy-type work). I'd guess that these people are -- and will remain -- in the majority.
  • The GPL does not prevent you from selling GPL'd software.

    Go ask Cygnus who made their first millions selling GNU's stuff. They made their next millions with their own GPL's software which they sold. Their latest millions came when Redhat bought them with billions gained through selling CD's with substantials amounts of GPL'd software.

    Or go ask Larry Wall. He released Perl under a GPL/Artistic combination. O'Reilly came along and made money off of it by selling books and CD's. They made enough money off of Perl that they had the hubris to hire Larry Wall!
  • Actually I recall a serious thread some time back on the premise of patenting the process of obtaining a patent....
  • Because as it stands, KDevelop did not suite
    my needs. KDevelop was missing 1 feature which
    made it unusable for my purposes. This is very
    much the problem mentioned earlier about 90%
    of the work being done. I am extremely grateful
    that the KDevelop team produced all the work
    it did. However, paying money to the KDevelop
    project won't do me any good (outside of giving me a warm feeling for supporting OpenSource).

    I openly invited any of the core KDE developers
    to take the project. None did. Lineo didn't have time to do the project itself. This is merely another form of contract work, and CoSource allowed me to find and pay a contractor for something that was important to me.

    I'm not sure what is sleazy about that. The feature that we are funding will be GPL, and it
    should benefit many others besides Lineo. I
    don't see the downside of this for anyone. Nor
    any "unfairness" (that isn't inherently present
    in OpenSource development, because some make
    money and the original authors often don't).
  • As far as I can tell, it is a three-tier system;
    1. Members - can propose and pay for projects
    2. Developers - can propose solutions to the project, and their asking price
    3. Authorities - Handle the above question by brokering the exchange - they get to decide if a project meets the spec or not.


To do two things at once is to do neither. -- Publilius Syrus