Slashdot Mirror

I'm probably out of date, but I thought that was collab.net's and SourceXchange's purpose: bring together people who want code and have money with people who can make code and want money.

I'd think that it'd be easy to make the RFP there, then send a note to the developers/project mailing list steering them towards it.

No?

--j

That was tried, and failed but it needs to be dusted off and tried again.

What the article does not point out is that SourceXchange has closed shop, and CoSource development is economically unsustainable. The problem in both cases is that people will not pay for open source development.

SourceXchange allowed programmers to negotiate the price of the software, with the result that no one was willing to meet these development costs. I am not aware of a single project that was sucessfully negotiated through SourceXchange.

CoSource is even worse, it allows people to request whatever projects for whatever amount of money they wish. The result is that most requests have zero dollars and zero cents committed. That's right, they expect someone to develop software for them without ever receiving a cent. Other projects have commitments of up to $300. There is no way you can develop a full-featured application for a total cost of $300.

Closed-source works because people are willing to fund closed-source shops with millions in investment cash. Until the same thing happens to open-source development, it will be playing catch-up to closed source applications.

For every small company that can't make money writing GPL software, there are 500 that can make money by using it. It saves a lot of money at my work that I can use perl for my scripting, apache for my webserver, and php for additional web stuff.

Perl is under the artistic license, lately dual licensed with the GPL. Apache is under an extended BSD license. PHP is under an extended BSD license. 0.5 out of 3 isn't so bad (though the available artistic licensing of perl makes the GPL fairly irrelevant.)

I can get these items at no cost and I don't have to worry about them ever disappearing off the face of the earth, while MS can do what they please. So tell me again how this benefits MS and how this is killing companies?

I'm going to take these in opposite orders:

How does the availability of free, copylefted software kill companies?

There are two sides to this, both of which are results of economic changes. The first is that some types of software becomes available at close to zero cost along with the benefit of the ability do easy codechanges, outcompeting higher priced proprietary software. This is good; the workforce and capital of the companies are redirected to other places where they can contribute more to society.

Then there is the second, dark side: Copylefted software block economic models which give groups of end-users choice and tweaking for their needs. In a proprietary environment, a development company can do changes to source code as an investment, based on how many more people they expect to be buying the software based on the changes they do. For a copylefted product, the changes needs to be paid for by the first comer(s).

This is easier to see in a scenario description. There are two cases here: Market dominated by proprietary or BSDLed software, and market dominated by GPLed software. BSDLed/proprietary are fairly equal for this scenario; either the company has the maintained codebase available for proprietary use because it is being maintained due to market income, or it has the codebase it can use available due to open source maintenance. (Codebases can also be available with royalties due to commercial licensing; this gives similar cases with more complications.)

Let's set the cost of developing the codebase in the first place at $500,000,-. Let's further say that a particular new feature has a value of $100 for 1000 users, and that the cost of developing the feature is $10,000,-.

In a proprietary or BSDLed environment, this means that the company can develop the feature and sell it for anywhere below $100,000,-, while still both giving value to each customer. $90,000,- is available as cost/benefit difference, and up to this amount can be taken out as profit by the comapny while still adding value to society. This is enough available profit that it is reasonable to take the intial risk. Thus, the customers get their feature and the company get profit and everybody is better off (likely also the open source codebase, due to the distiction between strategic and tactical changes[1].)

Now for the GPLed case. There isn't a codebase available for the company to do properiary changes to, ao it has to develop that before going on to the profit side. Whoops, there was a $500,000,- cut of their $90,000,- potential profit - that's a $410,000,- loss. No way they are going to give those users the feature.

Well, what about the users themselves? Can't they just pay for the change to be incorporated into the GPLed codebase?

For each individual user, this is a loss. Paying directly to have the feature incorporated is a 100x cost increase compared to the benefit gotten back - not interesting.

Paying as a group is theoretically possible, but fraught with problems[2]. First, you need to get hold of the people in the group and get them to agree about what they need, and agree to pay for something they haven't seen, and which they will get no matter if *they as single entities* pay or not. Second, the cost of development will likely be higher. The developer in the proprietary example gets his profit from a fairly large benefit margin and can thus absorb risk directly; when working on the open source codebase, the risk adjusted cost of development will be higher, perhaps $15,000,-. Add $5,000,- in solicitation costs, and you're up to $20,000,- - still a lot less than the benefit marigin, but it needs a lot of contributors to get going.

[1] Development projects will usually include both strategic changes (those changes done to get revenue from customers by sales) and tactial changes (changes done to support the strategic changes, but without direct value in and of themselves.) Giving tactical changes back to the open source project one is branched off makes commercial sense; it decreases merge costs when updating from the free codebase, and increase employee happiness.

[2] Yes, I know about the Free Software Bazar, (no offers since august; no offers claimed since september 1999), SourceXchange (does not do pooling; seems to work for company-sponsored offers) and CoSource (does pooling; has transcated a total of $17252 since august 1999, with $9678 going to a single project. This is about two months of paid developer time at consultancy rates, total.)

How does this benefit MS?

MS has a number of codebases they are effectively guaranteed revenue from. Their market share is larger than the competitors in most areas. They've already sunk the development costs incurred so far. With GPLed software driving prices for alternatives towards zero, it gets harder for proprietary competitors to make a profit, and MS can stand the price war WRT development quite a bit longer than them (due to having a large number of copies to spread the development costs on.)

This is likely to effectively squeeze competitors out of the market, until you get to a point where you're only left with two forces: Open Source alternatives and MS. If the Open Source alternative is GPLed, MS can raise the prise almost as far as they want for those that don't get the features they need from the Open Source codebase - creating a new proprietary competitor will be too expensive.

I'm not certain this is going to happen, but the possibility is distinctly there.

Eivind (in most cases in favour of the BSD license, if that wasn't clear ;)

• cosource
• source exchange
• the free software bazaar

theres a few more that I can't think of.

Plus, if you want more ideas, I bet I can think of one every 15 minutes for an entire night. I'll meet you at the local watering hole. You buy.

Click here for $50!

You may want to find out what the current status is.

sourcexchange seems to be thinking in this way. They advertise here on /. trying to get ODD developers.

www.sourcexchange.com
www.cosource.com
The Free Software Bazaar

Let me know if you see any more. This could soon be my only source of income.

• Public vs. private licensure. You brought up the idea of a "General Public Music" somewhat facetiously, but it's a non-trivial point that you missed there. Linux (and the majority of non-Linux software included in the average distribution) are freely (as in speech) licensed, under the GPL, BSD, or some similar license. None of the big open source licenses prohibit redistribution of licensed software, and the GPL expressly allows redistribution for a fee. That means that by the time the distro gets to it, they implicitly have permission to redistribute, something record companies can't say until they have a contract.
• Non-exclusivity. During a contract dispute with their lable, the pop act XTC refrained from recording any new material, because they knew that whatever they recorded would be the property of their label. They were essentially forced to sit on their hands until their label blinked. Because free software developers don't have exclusive relationships with distributions (unlike musicians with record labels), a distribution can't leverage any pressure on the developer beyond refusing to include his software.

Finally, I have to take exception to your comment about distributions giving lip service to "giving back to the community." Recording artists enter into deals with record companies because they think that they will make money off of it. No one gets into writing free software for the purpose of making money off the deal - those who do deserve what they get (with the notable exception of services like SourceXchange). The way in which distrubtions usually give back to the community is in funding development in areas where Linux is lacking, and by encouraging employees to continue to devleop for the platform.

So, in short, don't look your gift-culture in the mouth. Beyond the utterly superficial, I don't see any similarity between record companies and Linux distros.

No one [...] will enter a field where the prospects of earning a decent living are substantially lower than in other fields.

Being able to earn a living is not necessarily dependent upon the ability to own IP. At the risk of repeating what others have said over and over, it's all about services. Look at sourceXchange, CoSource, and the other similar sites popping up these days. They work precisely because the value is in the ability to code, not the the produced software. Besides, most people who produce IP never see big returns from their work anyway. They exchange their IP production services for a steady paycheck.

The basic point behind all of this is that the value of the IP being copied outweighs the cost of copying it. That balance is only going to tip further as bandwidth increases and storage gets cheaper. Interests that make money selling IP will continue to put in technical countermeasures and legal deterrents, but they're fighting a losing battle. In an economic sense, information really does want to be free.

You didn't say whether you planned to develop the software using only internal people and then release it, or whether you wanted to co-develop with some independent developers from the very beginning. This can make a big difference. If you develop everything internally and then release the software then you'll face the problem of interesting people in working on something that they didn't have any part in creating, and which appears on the surface to be a company-specific project of limited general interest. On the other hand, if you try and bring people in earlier on then you'll be in a situation where you won't have anything yet that runs and is usable.

If you develop the software totally in-house and then release it, this is to some degree comparable to projects like Mozilla. In the Mozilla project the original Netscape developers started out as the designated "module owners" responsible for particular portions of the code, and then as non-Netscape contributors came on board they first contributed patches that were checked in by others, then they could get check-in access themselves (with their code being reviewed by module owners or others) and then finally they had the opportunity to become module owners themselves for particular components. So except for people in your company everybody else starts out "on the outside looking in"; this is unavoidable under this model, and has the effect of stretching out the period before the project is seen as a true open public effort (mostly) independent of your company. (Again, Mozilla is the classic case of this.)

So there are some good reasons to try to get other people outside your company involved relatively early on. Then they can participate as code contributors and module owners for whatever part of the project interests them. As for exercising overall control, you can have a single person overseeing the project or you can try and do a committee-style structure like the Apache folks did.

(The Apache project is one of the most formal ones in terms of their internal organization, and it's probably worth you're checking out what they did with the Apache Software Foundation. Also check out Brian Behlendorf's chapter in the "Open Sources" book, particularly the "Bootstrapping" section, for some information on the types of people you'll need in the course of the project, either from your company or from somewhere else.)

If you want to get people involved early on then you'll need to find people who are motivated to participate at the design stage. You might try looking for existing open source projects that are related to the problem space that your planned software addresses; those projects might have existing software you can reuse, and even more important may have people interested in participating in your project starting at the ground floor. (Even if you develop the software internally you're going to want to do this sort of "market study" anyway, because there's no point in doing work and then finding out that someone else has created a project that duplicates yours and prevents your project attracting developers.)

Another option is actually contracting with independent developers to work on the project in the early development phases, either to supplement your own developers or even to totally outsource the work. (For example, this is what Galactic Marketing did with the open source workflow project they're doing.) Even if you contract work out there's nothing to stop you from running the project "in the open" so others can check it out and provide useful feedback (as indeed happened with the Galactic Marketing project); whether you host the project yourself or somewhere else, you want to have some level of public access so interested observers have an entry point into the project.

That's all the comments I have time for now; good luck with your project!

Also check out www.vovida.com (I work there) who have put out several open source stacks for VoIP and a software phone that uses SIP and runs on Linux with a Quicknet phonejack card. Vovida has also sponsored a project to create an open source client like you want. It is at http://sourceforge.net/project/?group_id=5560 and the RFP is at http://www.sourcexchange.com/ProjectDetail?project ID=20

CoSource and sourceXchange have been mildy successful in promoting a sort of auction style commercial OSS development model. Ultimately, what kind of success do you think these sites will have. What changes do they need to make to become the next Ebay? Can you give an example of one more type of business model in which a web community will work together in the spirit of the open source movement?

A million dollar software project can be broken into a series of different projects, each just large enough that it can be spec'd out with a reasonable set of milestones (almost always less than 15-20). Software development schedules always change based on inherent risk, so you probably shouldn't spec out a 500 milestone project. And the Sponsor always has to be someone who can check the Developer's work - so this isn't exactly "put $15K in, get good solid code out overnight" kind of thing.

I would think that if you were the project manager for a 15 person software development project, you could probably parallelize 10-15 sub-projects in sourceXchange (or less if you have multiple developers per project), all working on different things. Of course it's not always nice and parallelizable, sometimes there's only work for a few at a time - but the beauty of this model is that you don't have to pay for 15 full time developers during those periods.

There's another thing a developer can do - be a Sponsor on a project where the person actually paying is upstream, and only knows their need, not how to define a solution. In other words, let's say you (average Slashdot reader) know of someone who has a need for some sort of development (say a Linux driver for the CCD camera in the Sony Vaio Picturebook) and is willing to pay to have it developed, yet doesn't know enough about Linux kernel internals to write a spec or approve milestones. You would do it, if fact you know how you'd do it, but you don't have nearly enough time. This model lets you be the "sponsor", acting as a subcontractor to this other someone who needs the driver written, who specifies (generally) what to build and how, and then outsources that actual development through sourceXchange, passing along the cost (plus an amount for your own time and effort) to the original customer.

There's lots of flexibility in the system.

Thanks.

Brian

-ryan

-ryan

"Any way you look at it, all the information that a person accumulates in a lifetime is just a drop in the bucket."

There are a lot of facets to what makes open source work.. one of the key elements is for developers to 'scratch an itch'..
I'm not sure exactly how paying someone fits in, but you could in effect scratch your own itch and set up a contract at source exchange
that suits your personal application desires. Who knows..

Regards,
Ivar

There are a lot of things that people are doing to make open-source systems simpler and more powerful. Go to a site like sourcexchange or cosource that lists things that people would like to have done, find (or add) something that you would *love* to see done, and sign up as a sponsor.

Yes. Open source projects I'm familiar with are very responsive too ( asking for sensible things does help ). But I feel very uneasy when I see users believing that those developers have any obligations towards them.

Many of those developers are happy to add some features from their users' wishlists. But it's important to point clearly that they do that just because they feel like it, not because they should.

If you ( or me or whoever ) really want/need a feature implemented you can:

Fund the development total or partially ( there're companies trying to make some bucks on commisions for contacting pools of prospective contractors willing to pay for the work, with programmers that can do the work and later give their contribution back to the community ).

Get your software from a distributor and ask for the feature to them. Most of the commercial ones are willing to (or at least should be) add some value to the product they are releasing.

Do it yourself ( aka Use the Source, Luke ).

Wait until someone decide to do it, for fun or whatever. But in that case, remember: They don't owe you anything, so you're not entitled to command anything, just ask politely and hope to have luck with your request ;).

Try looking at CoSource. I've been able to develop GPLed code and be paid for it
(well, actually I think the check is still in the post, as I haven't got it yet, but I digress).
There's quite a bit of cash floating about and CoSource has a few ideas on how to
make cash from software you are already developing, so I'd urge you to take a look.

Another avenue is sourceXchange, who cater for the corporate taste; but you
will have to convince a reasonably sized company to sponsor you.

Savant

That's why I went straight to places such as cosource , and source exchange which seemed to employ the idea of Bazaar as mentioned in ESR's papers. However, the lack of interest turned me down a bit. I found some projects that I could do, but the payback seemed so unpromising contrasted to the amount of work awaiting that I had to hesitate.

Is the Bazaar really working only for the most famous, like Miguel de Icaza [who came up as the lead coder of the better Windows look-alike, no flames :), ah and a half-functional spreadsheet app ;) ], or ESR because he thought open source was a jolly good idea, and as the maintainer of slightly arrogant "Jargon File"? Just being skeptical here.

It might just be that it's not OSS and Bazaar which ESR takes it to be, but rather voluntarily and charity work for the benefit of all as RMS puts it. Then, we wouldn't be hoping for wealth or fame some developers and some advocates did get. We would simply not be asking for it.

Of course, let's be skeptical about this, too. I'm personally unaware of anyone who would like to write an OS as an Anonymous Coward. That's where being impersonal starts to break. People deserve some sort of credit for what they've done.

To sum up, there's a sort of uncertainty about the success of true "Bazaar" like communitys. We're going to have to see if "sponsors" and "developers" are really going to be matched. If it turns out to be like that, I'm going to be among the happy ones. However, the "free software" approach may be more realistic, and asking for companies and people to join the cause of "free software" may be the right way to earn from software as we like it.

Since HP released the stuff under the GPL and LGPL licenses, if HP chooses NOT to incorporate bug fixes or contributions from others, anyone is free to take the code and in the much cherished tradition of open source, fork it.

HP is probably trying to cash in on the "open source" phenomenon but not only in the sense of publicity. They need the developers badly if this is going to go anywhere. The fact that they are willing to devote 5+ of their engineers time and commit over US$40,000 to initial e-speak projects on SourcExchange says a lot.

This isn't a case of a PR machine exploiting the words "open source" without the vaguest notion of what it is. It is a company taking tentative steps and testing out a new way of doing business, of achieving things. We should give them our welcome and support.

It is nice to see HP putting their time, money and marketing muscle behind something open source. Hopefully, theirs will be a positive experience for all, rather than scaring a lot of developers/companies away.

Note that HP has a bunch of RFPs on Source Exchange that are related to E-speak.

In fact defending everyone's freedom BUT the freedom of developers to charge for the work they have undertaken,

OSS relies on people's good nature to get software written.

In fact there are at least two websites set up to match developers with people who will pay them to write OSS - CoSource and SourceXchange.

There are a lot of programmers out there like me that don't care about GPL or "Free" software, but use it because its a cool environment and it provides a level playing field that isn't inundated and overwhelmingly dominated by Microsoft.

Umm... yes, it is a level playing field. But have you ever stopped to think why it is so? Could it possibly be because of GPL and other free software licenses? If people don't care about freedom, how long will it stay that way?

And anyway, writing Open Source software doesn't exclude the possibility of making money. I know many people who are doing it as their job.

(and check out SourceXchange for another way to make money with Open Source).

/Bergie

--

I appreciate all the comments that have been posted, particularly those from Frank Warmerdam and _Dodger. BTW, I'm the Brian involved with sXc, under my posting identity on /..

Most of the points I was going to make have been made; particularly the point about the fact that we are not a bounty system, but a project-based system, which means that the developer and sponsor agree to work together at the beginning, rather than the end, of the development cycle, and that the developer is paid according to a series of milestones in the project. This is the only sane way to do larger projects, and I think it addresses some of the original essay's author's comments.

Also, since announcing sXc, the single most often asked question, one way or another, is, "can developers (or anyone else) propose projects that can get funded". As time has gone on, we've realized this could actually be a much more effective way of generating funded RFP's - rather than trying to guess which companies would have projects they'd want to fund, we'd look at projects that the developers have identified as crucial, and try and figure out who we could convince to fund them. In our old thinking, this was the tail wagging the dog, but we now see this as really the dog wagging its tail.

And of course, long-term, the real funds for projects will come from the end-users who aggregate their funds for projects. Think about this - a conservative estimate on the size of the Linux user base is 12 million users. Imagine if each of them were to contribute $40 towards the evolution & development of Linux-related software (the kernel, utilities, graphical apps, etc) over the course of a year. That would be $480 million dollars available for projects!

Finally... keep in mind that there is tremendous flexibility for what can constitute a "milestone" in a project, and what a project itself can fund. It can be source code, but it can also be documentation, test suites, UI/installation, quality assurance... all those things that tranditionally haven't been done by developers because, frankly, they're usually pretty boring to do. We can also have projects for which each milestone is simply a marker in time: for example, let's say the project is "to monitor and maintain the 3C509 network card driver family in *BSD over the next 6 months". Let's say each milestone was simply that every two weeks, developer would report to sponsor what they did to fulfill that directive. Maybe there was a kernel change that mandated a patch; maybe there was a new model of a card released; maybe there was a new bug posted that needed addressing. This is a much looser kind of project, but it could be exactly what is needed to help make sure that card family doesn't suffer from bitrot long-term.

At any rate, this is definitely a new space that CoSource, sXc, and other efforts are entering, and we're going to make mistakes no doubt - but every day I get more optimistic that this is actually going to work. =)

Thanks for the comments, all.

Brian

p.s. - the first draft of the sXc developer agreement is now online. Comments welcome..

It was, indeed, a well considered essay. However, I'm forced to disagree on a number of points.

Why assume greed?
Money hasn't been the motivator so far; why assume that once someone's thrown some cash into a bucket that this event is going to transform the community? It seems more likely that teams of college kids will band together to make enough money for a party/trip/whatever, or that LUG programming SIGs will look to this as a way to earn funding for the group. Some programmers may have a go at making this pay the bills; perhaps it will work. I don't think we're all going to drop what we're doing and become bounty coders.

What about peer review?
Both sourceXchange and CoSource have made peer review an integral part of the process -- and a bar that must be cleared before getting paid. I don't think that it would make good business sense for them to lower that bar any further than the project sponsor(s) want it to be set.

Inspired Annoyance
If people were already getting interested, there'd be no need for a bounty; in effect, these companies are saying, "We'll pay more if someone can do something which would benefit us in a timeframe we can accept." This doesn't mean that spare-time hackers like myself will flock to it because it's a paid project -- you might well find that the money convinces someone who was already a bit interested in the project's aims to rearrange their priorities in order to get paid to scratch their itch.

It's Still Open Source!
My final, and strongest, point: no matter what, the end result is open source. If you think the code's sloppy, pitch in and fix it; if there's not enough art in the crafted code, show them what Michaelangelo could have done with a keyboard. You've got the choice...and in the meantime, we've got the code.

I'd probably ramble more, but I've got to go to work. You get the idea.

--j

This might be a good project to try out on sourceXchange (once it is launched). If US$20k isn't enough, then perhaps if many more people put in about US$20 each, it would be plenty.

John Hebert
"John Hebert"