The important thing is to break down larger projects into smaller components. Cosourcing works best for modules that can be worked on independently, and many efforts can be going on in parallel by different people/groups.
For example, We won't have a single project called "KDE" on Cosource.com. What we will have is a folder called "KDE", with lots of different projects in it, like "Add a CTERM(Rate, FutureVal, PresentVal) spreadsheet function to KSpread".
Thanks for your questions. We don't have a FAQ up yet, sorry. (I'm a lazy Perl programmer, and I'm trying to write the FAQ in XML, and spit out the pages from that -- not done yet).
Will Cosource.com only use the GPL licensing model? No, we'll provide a menu of licenses for the developer to choose from. The sponsors can then reject bids that use licenses they aren't happy with. We'll accept requests to have new licenses added to that menu.
What do we do about non-monetary compensation? Cosource.com will only handle monetary compensation when it launches (because we are aggregating many sponsors, rather than a single sponsor per project). If you want a machine instead of cash, sourceXchange is the one for you, at least initially.
How to we make money? We mark up the developer's bids, much like a retailer.
I'm not sure how sourceXchange is handling this --probably selected by the developer as a part of their RFP.
With Cosource.com, the developer places a bid to win the project. That bid includes their price, their schedule, their peer reviewer, and their license.
Project sponsors get to look at and accept/reject each bid. The first bid to gather enough sponsors to pay the price is assigned the project.
The license is not a text field.. it is a menu of radio buttons of standards licenses like GPL, MPL, etc. with links for everyone to go read the full license text on the home site.
I'd love to heard any comments you have on the way we're doing this. We expect that it'll take a good bit of fine-tuning to get this right so we're balancing the needs of sponsors, developers, and the Open Source community at large.
Obviously we haven't made this clear enough (our upcoming FAQ will speak to more cases) -- Cosource.com is designed to do just what you're asking for: Either an initial sponsor or a developer posts a project, and we start gathering sponsors for that project.
We handle the developer-initiated case, and we certainly handle the multiple sponsors -- that's our primary focus! This logic for the site is implemented in Perl (mySQL database).
Slashdot Mirror
The important thing is to break down larger projects into smaller components. Cosourcing works best for modules that can be worked on independently, and many efforts can be going on in parallel by different people/groups.
For example, We won't have a single project called "KDE" on Cosource.com. What we will have is a folder called "KDE", with lots of different projects in it, like "Add a CTERM(Rate, FutureVal, PresentVal) spreadsheet function to KSpread".
Thanks,
Bernie Thompson
Cosource.com
Thanks for your questions. We don't have a FAQ up yet, sorry. (I'm a lazy Perl programmer, and I'm trying to write the FAQ in XML, and spit out the pages from that -- not done yet).
Will Cosource.com only use the GPL licensing model? No, we'll provide a menu of licenses for the developer to choose from. The sponsors can then reject bids that use licenses they aren't happy with. We'll accept requests to have new licenses added to that menu.
What do we do about non-monetary compensation? Cosource.com will only handle monetary compensation when it launches (because we are aggregating many sponsors, rather than a single sponsor per project). If you want a machine instead of cash, sourceXchange is the one for you, at least initially.
How to we make money? We mark up the developer's bids, much like a retailer.
Thanks,
Bernie Thompson
Cosource.com
I'm not sure how sourceXchange is handling this --probably selected by the developer as a part of their RFP.
With Cosource.com, the developer places a bid to win the project. That bid includes their price, their schedule, their peer reviewer, and their license.
Project sponsors get to look at and accept/reject each bid. The first bid to gather enough sponsors to pay the price is assigned the project.
The license is not a text field.. it is a menu of radio buttons of standards licenses like GPL, MPL, etc. with links for everyone to go read the full license text on the home site.
I'd love to heard any comments you have on the way we're doing this. We expect that it'll take a good bit of fine-tuning to get this right so we're balancing the needs of sponsors, developers, and the Open Source community at large.
Bernie Thompson
Cosource.com
Hi Ed,
Obviously we haven't made this clear enough (our upcoming FAQ will speak to more cases) -- Cosource.com is designed to do just what you're asking for: Either an initial sponsor or a developer posts a project, and we start gathering sponsors for that project.
We handle the developer-initiated case, and we certainly handle the multiple sponsors -- that's our primary focus! This logic for the site is implemented in Perl (mySQL database).
Join our beta program and check it out...
Cheers,
Bernie Thompson
Cosource.com