Slashdot Mirror
Upside on CoSource's Leap of Faith
Chris Fischer writes "Here's a great article on UpsideToday about CoSource.com, 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. "
I patented the idea of collaboratively funding open source software development through e-commerce.
(heh)
Warning: Travoltus has obtained the Rampant and Uncontrollable Patenting of Everything I See Patent.
--- Grow a pair, liberals... stop letting the Republicans bully you!
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!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
system.
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.
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.
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?
And finally,
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.
-Denor
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.
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.)
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.
Lando
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.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
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?
only the pronoid survive..
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."
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."
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.
Mojotoad
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
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.
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 http://www.fi.muni.cz/~kas/vgetty/. 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.
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.
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.)
+&x
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.
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.