It's an Industry! Part 2:
A Conversation with Brian Behlendorf of sourceXchange and Wayne Caccomo of Hewlett-Packard


May, 1999

Part 1: Introduction

Part 3: A conversation with Bernie Thompson of CoSource.com


On Friday, May 14, I talked with Brian Behlendorf of O'Reilly Associates and Wayne Caccomo of Hewlett-Packard about souceXchange, the new O'Reilly enterprise that began as an idea at Hewlett-Packard and quickly became the adopted brianchild of O'Reilly.

Brian, best known for his work as the leader in developing Apache (which serves up the majority of the world's Web pages), is heading up the whole sourceXchange effort.

The conversation was just before Linux Expo, where sourceXchange was officially announced. At the time I knew a little about CoSource.com, a similar effort by Bernie Thompson, who frequently writes for Linux Journal. Afterwards I called and spoke to Bernie as well. That conversation comprises Part 3 of this series.

— Doc Searls, 20 May, 1999


Doc Searls: So what are we talking about here?

Brian Behlendorf:: We are announcing sourceXchange — a new electronic marketplace and coordination center for open source software development. We think it has the potential to impact the future of OS software development in a big way. This is something that people have thought about and tried to do before; but generally geared more toward the bounty system—

Doc Searls: — Which is what?

Brian Behlendorf:: Which is where Party A will pay $10,000 to the first person to write X. What we have with sourceXchange is a bit more fair for developers and a bit more scalable as well.

Doc Searls: How does it work?

Brian Behlendorf:: It's an intermediary or broker between what we call sponsors on one hand and developers on the other. Sponsors can be IP vendors: large companies like H-P, Sun, IBM, DEC or whomever. They can also be government institutions, people who work for the larger e-commerce sites, or ISPs. There is a huge body of companies out there who have needs for open source software and the resources to pay the talent, but have lacked a way to pull it all together. That's what we're giving them.

The type of developers we are talking about are the people doing open source today, and who would like to get paid for some of it. We're also talking about professional developers who haven't been able to work as much in open source software as they would like, because they need to work for a living and that kind of thing. And we're also talking about college students who need to pay tuition. A lot of really good development that takes place within open source comes from bright and motivated young people.

And what we've come up with is a process that brings these two sides together in an environment that works to each other's advantage.

Doc Searls: Where did this idea first come up?

Brian Behlendorf: H-P had been working on the idea of creating a more efficient means for them to be able to have the kind of relationship with others in the open source community as they have with The Puffin Group, for example.

Wayne Caccamo: Here's how it went. Our corporate IT department came up with the idea of an intermediary that would work to shield us from the complexities of our own contracting process. We wanted to get work done and hire contractors to do it; but we found the process both very complex and time-consuming. We faced a number of internal requirements about the contracting process, plus
"Anywhere there is a need, and people have a financial interest in meeting that need, this will help one side find the other." — Brian Behlendorf
government regulations. It was just real difficult.

So we came up with this idea for an intermediary that would act as a single interface point for us — an entity would then be responsible for dealing with the issues, and dealing with the contractors for us. So our relationship would be with a single entity instead of a myriad of contractors: of open source developers.

On the marketing side, we thought it would be a great way to extend our software development resources and budget with a fairly simple and compelling option for outsourcing certain types of software development projects. At the same time we anticipated that over time, as this becomes an increasingly viable and deployed option, we will focus our own resources on the kind of development projects that we need to keep internally as H-P intellectual property. But those are beside the point here. What we wanted to deal with are the many things that simply don't need to be done internally, and might be better done externally. We thought we needed an outside mechanism that will allow us to quickly and easily engage with developers. So that's how the idea was born.

Doc Searls: On the demand side.

Wayne Caccamo: Yes. What we're looking at, from an IT vendor's standpoint, is not only access to a great pool of talent, but a way to augment our resources that gives us a time-to-market advantage — and also a mechanism for making development more predictable. We are faced many times with decisions about whether or not to develop something internally, and open source is an increasingly attractive option. So the question became, can we rely on open source? What's the timetable? How can this work in a way that's predictable?

And that's the biggest excuse for not using open source – that it's not predictable. SourceXchange makes it a lot more predictable. All you have to do is fill out an online RFP form, submit it to meet our timeframe requirements, and let the market take care of the rest.

Doc Searls: There is also the promise of compensation involved. That makes things a lot more predictable.

Wayne Caccamo: That makes things very predictable. You can adjust that variable to make sure you get what you want.

Doc Searls: So you went to O'Reilly with the idea.

Wayne Caccamo: We approached O'Rielly because as H-P we are not in a position to perform as an intermediary. If we want to have the kind of lasting impact this kind of thing ought to have, we can't be in the middle. That would discourage our competitors from participating; and we don't want that. We needed somebody like O'Reilly as an intermediary.

Brian Behlendorf: I'll jump in here. We had this meeting back in January with H-P in which they said, "Here's this interesting idea. What do you think?" And we thought the big advantage was to the developer's side. I've personally seen, in my experience with Apache and in other areas, that often a great idea would come up and somebody would say, "Oh it would be really nice if somebody worked on this." But because it wasn't really sexy, or because it wasn't an overnight hack, it would just go undone.

At the same time we have seen companies, in addition to H-P, who wanted to do things in the open source space, but didn't have an approach because they couldn't afford to hire somebody full-time to be an open source developer. Or because they didn't want to go through the whole contracting process that typically has a high start-up time. Or because the didn't know if somebody was a good open source developer. All these reasons and then some.

So we saw the potential here for a site that focuses on both sides of the equation.

Doc Searls: That serves both supply and demand.

Brian Behlendorf: Right. This would clearly be a powerful concept. It would also fit into the kind of thinking we've been doing at O'Reilly about how to explore new parts of this open source issue. We've done a lot with books on the subject, and in conferences, and in promoting the idea of open source. But this is the first flag we are putting into the ground, saying "here is an interesting new business opportunity." Given our position in the market, and the kinds of relationships we have with developers, it makes all kinds of sense.

Doc Searls: So really you're coming at this from the developers' side.

Brian Behlendorf: Yes. And we think we have come up with a system that is extremely pro-developer, that is extremely fair to people who want to be contractors, who want to get involved. It makes life a whole lot simpler for them than if they were to try to contract with each of the potential sponsors separately.

Doc Searls: And an exchange — a market — needs to bring benefits to both sides.

Brian Behlendorf: This site is going to support a whole lot of communications between developers and sponsors that just doesn't go on otherwise today. It will be a high bandwidth communications vehicle between the development priorities of the companies and what the developers think are really good projects to take forward. We're really excited about it.

Doc Searls: Is it independent?

Brian Behlendorf: SourceXchange is a wholly owned subsidiary of O'Reilly Associates: owned, operated and managed by O'Reilly. We won't hide the fact that we see this as a commercial enterprise. Any time you try to step in and play a serious management or intermediary role, you have to involve money at that stage to make sure that it works.

This is also a service, however. We are not charging for access to the code. We are not charging developers to be involved. The business model is to take a percentage of a project's value that's agreed upon between sponsor and developer, and tack that on as a fee to the sponsor. That's how we make our money.

Doc Searls: It's an intermediation strategy. I'd say "re-intermediation," but I don't think there wasn't any intermediation there in the first place.

Wayne Caccamo: It is reintermediation.

Brian Behlendorf:: We don't want to add complexity. When you say intermediary, it carries the connotation of a brick wall between two parties that don't want to be together. What we're actually doing is taking down barriers. When a developer wants to start working with a company, with a contractor, typically the process they go through to arrive at warm fuzzies from both sides and make sure it's a good project involves significant start-up time: on the order of one or two weeks. And both sides both always have to deal with the fact that they don't have an independent way to measure the quality of the other party, or a way to collectively find all the interesting projects out there from multiple contractors or companies. In addition, the companies don't have a way to evaluate the pool of developers as a whole and to compare a potential developer against that pool. So this is a way to grease the gears: to work as the WD-40 of open source software development.

Doc Searls: I hold to the belief that markets are conversations. By that metaphor what you're doing here is creating a venue where those conversations can occur. Where market mechanisms can do what they do.

Brian Behlendorf:: Yeah.

Doc Searls: So you are creating a system where goods can find their own prices, no?

Wayne Caccamo: That's right. Each project will have a proposed fee. And then there will be some iteration as the project is posted for public comment. It can expand or contract. But ultimately there is an agreed-upon price. As vendors like H-P get experience with it, we'll probably get better at putting the right value on it. If we lowball the project and there is no interest, then obviously the price will have to move upward to seek an attractive level. On the other hand, if we overshoot the market and get five thousand RFP responses, we would start to tune our sense of what an appropriate price is. But I think in most cases it will be less expensive to go out to open source than it will be to do the equivalent project internally. The price that we offer will reflect that difference. See, with internal engineers the cost is highly leveraged. We know exactly how much that is. This gives us the option to pay in cash or in kind. Which is an interesting option for a company like H-P. Say we need something like a device driver for a workstation. We ship them the workstation to work on and say keep the box: it's is yours at the end of the project. That's compensation. Developers often love equipment. And for H-P that's an extremely inexpensive way to buy compensation, and very strategic in the sense that we can populate the open source development community with H-P developer seats.

Doc Searls: I'm thinking about typical cases, and it seems to me there sure are an awful lot of device drivers that need to be written.

Wayne Caccamo: We're doing that port of Linux to PA-RISC. The initial kernel is being done by the Puffins on a voluntary basis. After that we have to make that a functional system, and there are just a zillion device drivers that need to be written, and those would be excellent candidates for SourceXchange.

Brian Behlendorf: Apache modules are another typical case. There are lots of things that are not really obvious that will manifest in this environment. In my perspective, the first set of projects are going to be those that involve between two man weeks and four man months worth of work. That may be a bad metric to try to apply to any development, especially open source development, but we are talking about things that are substantial in size. Not ust bug fixes and small patches to this and that.

Doc Searls: Original works, to some degree.

Brian Behlendorf:: Yeah. But they don't have to be 100% original. In fact, what it will do is incent people not to reinvent the wheel every time they have to solve a problem, but rather to look for people who have solved 20% or 50% of the problem, and re-use that code. Enhance rather than originate. In my opinion there is a lot of reinventing of wheels going on in the open source community. This can help mitigate that problem to some extent.

Doc Searls: There are so many things out there in the PC world that are still not there in the Linux world — especially on the client. I'm wondering if this invites some of those missing pieces to come into existence.

Brian Behlendorf:: I think anywhere there is a need, and people have a financial interest in meeting that need, this will help one side find the other.

Doc Searls: Well, this is a question for H-P, I think. Does H-P want to get stuff written for everybody? For a case in point, let's take Alexa, which has this little browser accessory, but also produces these Web statistics all the time. It's not collected anywhere, but it's really interesting stuff. Now they have no intent whatsoever, as far as I know, to develop for Linux yet. They haven't even brought the Mac version out of beta. Now I want it on Linux. If there are many of me, there is a need. But I don't see any indication from Alexa that they are even remotely interested in developing for Linux, even though the user demand might be there. Yet I suspect that the programming is quite do-able. Not trivial, perhaps; but not a huge issue. Would H-P or any of the other sponsors in SourceXchange be so interested in seeing Linux established as a client OS that they'd pay to bring some of these things forward? Is that something a vendor, thinking of its customers, would want to do? Or is Linux such a server-side business that nobody's really thinking about the client yet?

Brian Behlendorf:: I don't think you'd find anybody disagreeing that Linux through the rest of 1999 will make major forays onto the desktop. It's there. The applications are 90% of the way there to crossing the critical mass point.

Doc Searls: Which applications are you talking about here?

Brian Behlendorf:: Word processing, graphical tools, multimedia tools....

Doc Searls: But those aren't the cases I'm talking about. It's the slightly-less-mainstream ones. I can think of an example from our own shop. Our only Windows box is the graphics workstation we use to help produce the magazine, using PhotoShop and other tools not yet available on Linux clients. The GIMP is nice, but it won't do CMYK files, which we need for color separations.

Brian Behlendorf:: That is a perfect project for this thing.

Doc Searls: Well, we have gone out to the groups that work on GIMP and said "We want this," and we have had no response. It's like, so what? As you put it, it's not sexy, or it's not an overnight hack. So I'm wondering if sourceXchange provides the place for this? Would we be the sponsor here? We're not a vendor like H-P. We're H-P's customer.

Wayne Caccamo: Sometimes there is a project that would benefit the industry more than any individual or group or sponsor, but no one sponsor or group will pay to get it done. But maybe twenty sponsors together would pay for it. Aggregate sponsorship is something SourceXchange can facilitate.

Doc Searls: In other words, you can come up with a joint RFP.

Wayne Caccamo: Sure. This has the real potential to change the economics of the business by changing what's economical to do. In many cases the free rider effect would cause something to stand still. In an environment like this, you can justify a lot more using that kind of approach.

Doc Searls: I'm trying to see how it works. You are talking about three conversations: among vendors, among developers, and across both. The first is formalized; the second is informalized, I suppose; and the third is brand new with this service. Do you have something that facilitates the first and the second as well as the third? Or is it just across the first two?

Brian Behlendorf:: That we will develop as time goes on. When we launch, we will support some of that. When a developer browses through the list of RFPs, he will have the opportunity to attach a comment to an RFP, even if he is not interested in actually working on it. We can plug these things together, so the next guy can take advantage of the first guy's knowledge. A developer can also say "I can do half of this project. I can do the front end but not the back, because I don't know much about GUI programming." And another developer can come along and say "Hey, I've got a complementary fit." The two of them can work together. So we've got the beginnings of something conversational there. But I don't want to set ourselves up as replacements for mechanisms that are already out there, like the Linux Development Mailing List. There are still appropriate developer-to-developer forums. I think over time we'll develop a sponsor-to-sponsor forum.

Doc Searls: Do you see this as an addition to Eric Raymond's open source business models?

Brian Behlendorf:: Absolutely. This puts at least one or two of them to the test.

Doc Searls: So what you're saying at H-P is that open source is more than a worthy development model, and that you want to take advantage of it.

Wayne Caccamo: Right.

Doc Searls: A lot of vendors — potential sponsors — find open source threatening. It's a punch they want to roll with. But you seem to see it as a tide of development you want to surf.

Brian Behlendorf:: It's fundamentally pretty new, and I have to give kudos to H-P, who are willing to stick their neck out and give us a try. This is experimental. And it is up to the community to make it a success. With sourceXchange we enlarge that community. We make a market for open source development. It's a great thing for open source developers whether they write for commercial reasons or not. There is lots of unsexy, unhip, uncool stuff that needs to be written in open source software that is most likely not going to get done otherwise.

Doc Searls: For the simple reason that the market isn't manifest.

Brian Behlendorf:: Right. Like the CMYK problem. This provides a vehicle for those types of needs to be met. And it leaves the free software guys as free as ever to focus on fun stuff. But everybody has to be involved to make this a success.

Wayne Caccamo: From H-P's standpoint, this was born from a real-world need, and a clear idea of a way to create a market. We've launched this internally to generate interest on the supply side of sourceXchange. The RFP response has been overwhelming. There are people from all parts of the company that have expressed interest.

Doc Searls: So this has been a necessity that's mothered invention, rather than the reverse.

Wayne Caccamo: Exactly.

Doc Searls: I may have missed this, but is O'Reilly paying for all this, or is H-P funding it in some way...

Brian Behlendorf:: To be clear about roles, H-P is the founding sponsor. They are also the unofficial guinea pigs. They will be the first to put in a set of RFPs and help us work out the kinks. They have put some money up to help us with development and committed other resources, such as machines, and helping us qualify our system against the needs of typical sponsors and such. But at the end of the day the project is being owned and run by O'Reilly. All the contractual relationships between sourceXchange and everyone else is being managed by O'Reilly. SourceXchange is an affiliate of O'Reilly Associates. Everyone working on it is being paid on salary by O'Reilly. We have a couple of projects along these lines: services and infrastructures that facilitate open source software development, and this is one of them.

Doc Searls: Is this large enough that you would want to take it independently to the venture community or something like that?

Brian Behlendorf:: I don't want to rule anything out.

Doc Searls: I thought Kleiner-Perkins' investment in Linuxcare was extremely significant, because the most forward and industry-strategic of the VCs was saying in effect that open source, and Linux specifically, had at least one highly viable business model. This wasn't just free software any more. Now suddenly there is a lot of conversation about what business models work here. Eric Raymond isn't alone any more in talking about this stuff: his voice is no longer in the wilderness. Kleiner clearly has an appetite for ways open source works that Microsoft does not. You are saying that yours is one of them.

Brian Behlendorf:: Well, I've got a few short positions on Microsoft. Just kidding. Again, I don't want to rule anything out. This thing is new. We're out to make it a profitable venture. We want to be clear about that. We're not aiming to build it into the size of eBay, because we have realistic expectations. We think that the role we're playing adds real value, and we really can't see how big the market can get. But if at the end of the day it's not profitable, at least it's a good service for the community, and we'll probably still run it.

Doc Searls: Who else is out there doing anything like this?

Brian Behlendorf:: There are a couple places out there, like the Free Software Bazaar. These are more at the grass roots, $50-$100 level. They reward the first person to fix this bug or to write this simple device driver or something. We thought the bounty system, while it works for smaller stuff, doesn't really work when you start talking about three man-months worth of work. There is just no incentive for someone to start working on something on that scale when there's the potential that the day before they're finished and ready to claim the prize someone else who has been working one day longer gets the reward. We thought a system that was project-based, like this one, would be much more fair to developers, and would incent them to take on much larger projects than they might otherwise. I'm not saying that we wouldn't expand to smaller-increment projects; but it's projects on the larger scale that go wanting right now. Once we get the system going and scalable, we'll probably add projects down in the $1000 or even $500 level. There are significant dollars involved in these larger projects: anywhere from $5000 to $40000 or even $80000 or so.

Doc Searls: It occurs to me that once you get started, there will be numbers falling out of this that are interesting to publications like ours. Like, what's the going rate for X kind of work?

Brian Behlendorf:: That is hard to assess right now because, as we all know, some developers are worth 10x or even 50x more than other developers. But with SourceXchange we'll have a market that can help decide what appropriate compensation is.

Doc Searls: It's two years from now. You've had a thousand projects. The market has been doing what markets do. You're going to know some values. Will you be willing to share those? I guess that's the question. Or will it they be so public that anybody will know anyway?

Brian Behlendorf:: We won't keep any of that stuff secret. Going rates will establish themselves. Histories will be evident. We'll find out what it takes to write a good 3-D graphics or video driver for Linux. Is that a $5000 or a $30000 project? We'll know. Time will tell. In the early days we'll all be trying to figure out what those price points are. If a project is out there and getting no attention, it could be that it's priced wrong. Or it could be that it's too complex, or not worthwhile on other grounds. But we'll get to see the market at work.

Doc Searls: If this were out there 5 or 8 years ago, how would Apache have been different, if you can guess at all?

Brian Behlendorf:: I don't know if there was even the concept of what we have in the world today, way back then. What we have now is a world of opportunity uniquely enabled by the Internet — by the fact that you have all these developers on line, who can communicate in real time, who can share code in real time. It would have been a lot harder for us to start sourceXchange way back then, because the building blocks just were not there. Open source software itself was too nascent at that point. Every single project would have been too large. You wouldn't have had a fluid market. Now you can have one. And we're making it a bit more fluid with this project.

Doc Searls: So how would you like this to have been seen at some future point?

Brian Behlendorf:: As the WD-40 for open source development. Something that really greased the gears, that really helped make open source work better. Not something that changes the reasons why people work in open source. Not something that means nobody works for free any more. There will still be the same gratifications. Having your own itch to scratch will still be the same reason why most of the open source work will get done. None will be taken away.

Wayne Caccamo: I think it would actually encourage all that, wouldn't it, Brian? I mean, you still have a community there. Now there is one more way for that community to do what they do.

Brian Behlendorf:: A key is that there is just a whole lot of unsexy development that is holding up the sexier development.

Doc Searls: There but for the lack of X, nobody does Y.

Brian Behlendorf:: Right. And this is how the unsexy stuff gets done.

Doc Searls: What's your own development timeline on this?

Brian Behlendorf:: Within 6-8 weeks we will be able to start the actual development process. H-P will have some RFPs out there in the database. In late summer to early fall we'll have our official launch. That's when we'll say we have all the kinks worked out and enough RFPs from a number of sponsors, or vendors.

Doc Searls: Have other vendors gotten any wind of this?

Brian Behlendorf:: Lots of conversations with lots of people who think this is a good idea. Nothing I can talk about so far.

Doc Searls: I'm just wondering if you've felt any demand just off word of mouth about this thing.

Brian Behlendorf:: We did a whole lot of vetting of this idea before we got too involved. A lot of conversations with leaders in the open source community where we asked, "Is this going be perceived as big companies trying to take over, or is it going to be perceived as a channel for the funneling of open source interest and energy in the commercial space into an appropriate vehicle for the open source community?" And almost universally, the developers have said it's the latter. It's something that's a really good social contract between these larger entities and the developers. And at the same time we have taken this to other companies in private conversations, to get the ball rolling. Almost universally, they've said, "Yes, we have 30 projects we want to put in this thing tomorrow."

Doc Searls: To me the significant thing about this is that it certifies the recognition on the part of large companies that they are on the demand rather than the supply side for the real goods here.

Brian Behlendorf:: And I don't know if that's necessarily firm yet. There may be consulting agencies to pop up to do this, or engineering firms. There is nothing that prevents that from happening.

Wayne Caccamo: We had a big debate about whether we would allow H-P internal engineers to be involved, because we were concerned about bidding on our own projects. Would that be a non-level playing field? This debate just underscored the sense within H-P of being on both sides of the fence. There is just a tremendous endorsement of this project on the part of HP engineers who are open source developers by night.

Doc Searls: Well, there is Jamie Zawinski's report, which suggests that the Mozilla project did not take off the way everybody hoped in part because there was this perception that it was a Netscape project for which only Netscape people got paid — that it was a Netscape Thing. Free volunteer labor for Netscape. I'm wondering if we can take this as a case in point for anything. If sourceXchange had existed, and Netscape had used this rather than the Mozilla project as it was at first conceived, would we be looking at Netscape 5 now?

Brian Behlendorf:: I wouldn't want to make so bold a statement, because that would be unfair to those who have been working on Mozilla. But I think something like this would have been a cleaner mechanism for those companies that are using Mozilla and did want to see the new version come out, for them to be able to put together a pool of money to fund the work. This would be especially important for Mozilla. We talk about the unsexy code that needs to be written. Well, Mozilla was rife with to-do lists full of things that are very much behind-the-scenes, under-cover, out-of-sight and therefore unsexy to do. If there was a pool of money for this class of development, there would be a set of people available to write it.

Doc Searls: One of the things that has bothered people on this new corporate demand side of the open source conversation is that open source seems to presume the existence of an infinite pool of free labor that works merely for the approval of peers.

Brian Behlendorf:: Anyone who thinks that is naive.

Doc Searls: But a lot of people, believe me, start from this naive position. They literally are naive. The enterprise press are busy saying "free" because it's easy to say.

Brian Behlendorf:: They're getting over their fear thing, and now they're abusing it.

Doc Searls: And of course they are covering the Microsoft vs. Linux sports contest, rather than the rest of what's going on, because that's so easy to write about. But now you're saying in a big way on the demand side is, "Hey, what you're doing out there has value, and we're willing to pay for that, right here, in this mechanism whereby our money can find you, and you can find the work..."

Brian Behlendorf:: Exactly.

Doc Searls: "–and the mindful crapwork that needs to be done also has value and we're willing to pay real money for it." Suddenly that stuff is attractive.

Wayne Caccamo: That's exactly our motivation here. We use very similar words in the conversations that resulted in this thing. Companies are much more comfortable paying people for their contributions than with not paying them. Sometimes it's hard for us to just give things away. It's a more complex process than it is to sell something. Just look at what it takes to give away a machine for in-kind work. The Puffin thing was an interesting deal because they came to us and said they were going to do this PA-RISC port with or without us. When I got wind of it, I said, "Hey, we wanna help." But it wasn't easy. It seemed like a great way to get into a relationship that had enormous value, perhaps much more important than the port itself. But there came up this accusation that we were exploiting people. It made no sense, but there it was. I'll tell you, we're much more comfortable corrupting people by paying them than by appearing to exploit them. Of course I'm being facetious here. We really aren't corrupting anybody in either case. But it is time for a better mechanism.

Doc Searls: There is something about involving money in a market that makes it more of a market. And that has been a significant missing piece in the open source conversation. We've been talking about a lot of things, but not so much about anybody getting paid. Now: there it is. It's formalized. It has procedures. You can go to the Web and find it. And you can join in on one side or the other. And it looks and acts like a market.

Brian Behlendorf:: It will be interesting to see how the interaction between the paid and the free developers goes. I think so long as everybody is pretty mature... (everybody laughs) ... well, I'll leave it at that. We're all working to make better software.


Part 1: Introduction

Part 3: A conversation with Bernie Thompson of CoSource.com