CodePlex - 2 sides of the same coin?

[johnvpetersen]

This forum and the resulting discussions, blog posts, interviews, etc
have been great. Through it all, I am seeing something very good (or
at least the potential to be very good) arising. I read Jon Arild
Tørresdal's interview with Sam Ramji - which you can find here:
http://www.infoq.com/news/2009/09/codeplex-sam-ramji.

Between this interview the comments from Mark Stone and the other
comments here, I am seeing two distinct , yet interrelated functions
for the foundation:

- To serve as an information resource for companies wishing to learn
more about OSS
- To serve as a sponsor/facilitator of OSS projects

If the CPF can initiate outreach efforts by sponsoring talks,
conferences, etc that serves to educate companies on all the facets of
OSS, I think that would be a very good thing. I would tend to agree
this is something that other foundations do not do - at least as part
of their core mission on a proactive basis. And I also agree that the
CPF, being a corporate entity would tend to have more success driving
that discussion with IT centers of influence (COI's) in business
today. Perhaps participation in an event like this:
http://www.phillyemergingtech.com/index.html would be a good way to
advance that ball. Keeping with the two sides of the same coin, there
is the technology itself and then there is the business of consuming
that technology. Listening to Sam's interview on the CPF website and
reading his interview with Jon - coupled with Mark's comments, I think
this is what is being talked about as a core part of the CPF strategy.
I hope it is as I think this sort of strategy would be a good thing.

Then - there is the other side of the coin - the projects and the core
technology. This is the part that I don't think is being discussed
enough. Again,I go back to Ayende's simple, yet very enlightening
comment - what's in it for the project?. The CPF has to be something
different than the other foundations - but at the same time - it also
has to share many of the aspects of those other organizations. For
example, facilitation - in the form of sponsorship, care taking, legal
advice, management, tech support, documentation etc. i.e., the
business side of a project. The creative aspect is already handled by
the project team and contributors out in the field today. It is this
business aspect of the project that the corporate types often look for
(and this goes directly to my first point on outreach).

The playbook for the second point is, IMO, is a known quantity. It's
being done in other areas. There is however an new aspect re:
supporting the first point.

Functionally, I believe there needs to be two areas within the
foundation - that work together to provide a level of synergy that
makes a the CPF a relevant player in the OSS space.

[Mark]

On Sep 18, 5:52 am, johnvpetersen <johnvpeter...@gmail.com> wrote:
"Again,I go back to Ayende's simple, yet very enlightening
comment - what's in it for the project?"

It's interesting that one of the key issues the CodePlex Foundation
proclaims to be addressing is one you guys hardly talk about. This may
well be because, as Ayende says, you guys are already in open source
and established. You figured it out, worked through the issues, and
have already arrived at the destination.

But I'll reiterate what, for me, has been a core insight: software
companies under-participate in open source projects. I don't even
think that's a particularly controversial claim, but if you disagree,
then we've found the root of our disagreement: it's a factual
disagreement about the relationship between software companies and
open source.

If, on the other hand, you agree that software companies under-
participate, you have to ask yourself, "How would the world look
different, and how would projects benefit, if software companies fully
participated in open source projects?" Then you have to ask the next
question, "What's holding these companies back from fully
participating?"

We have some ideas about the answer to that latter question, and we
believe we have a role to play in changing the game on that matter.
You can see the direction we're going in from looking at the model
agreements we've posted. Is that going to help Ayende? Maybe not so
much. Are projects, on the whole, going to benefit? Absolutely.

Mark Stone
Deputy Director
The CodePlex Foundation

[Jay Glynn]

This is interesting. I currently work for a SaaS company. We have utilized OSS in our offerings and have talked about contributing to these projects. While we aren't the type of software company you're probably talking about here, with a little guidance our upper management would feel a lot better about what the contribution really could mean to the company, not to mention to the various projects. 

[Ayende Rahien]

Mark,
I am not going to agree or disagree with this statement. I don't have enough data about it to do so.
I am going to ask a different question.

Why, as an OSS developer, do I care about software companies participation?

[Jay R. Wren]

Ayende,

You were in the room at Alt.Net Seattle when I asked the exact same question and also asked, why should any of us care about more open source software developers?

Software companies or individual participation, why is "more" a good thing? Developers are going to do what they want to do. If they want to contribute, they will. If they don't want to contribute, they won't. It is neither good nor bad IMO.

So why should the codeplex foundation encourage open source contribution? Do we need more of it?

--
Jay R. Wren

[Ayende Rahien]

Oh, I can give you a lot of reasons to use OSS.
High quality software, community, ability to change, etc.

That is different from encouraging OSS contribution. I don't see this as an important goal.

I think that a more accurate question is what do you want to achieve.

[John Petersen]

Mark..

I think the issue of the extent of OSS participation has been discussed. Also, I think most recognize that bridging this chasm is one of CPF's stated goals. The question I and others have posed is precisely how the CPF will achieve that goal.

JVP

[Mark]

I'll give you two scenarios of the kind of activity that CPF hopes to
engage in. The CPF did not spring to life in a vacuum, and both these
scenarios are representative of the sort of situation that led people
to think that there was a need for CPF.

(1) A software company has Product X that contains Component A, and
through A the product interoperates with another company's product Y.
As an alternative to Y, open source Project Z has also sprung up and
gained popularity. So the better Component A interoperates with Z, the
more of Product X the company will sell. So the company makes the
business decision that Component A should be released as open source.
They've decided this because it's a relatively self-contained piece of
software that can be open sourced while still enabling them to
productize X, and because they don't have the expertise in product Y
or project Z to dictate how interoperability should go. Better to put
this in the hands of the community where that expertise resides, with
the rights to make needed modifications. Devs from the software
company can continue to work on the now open source Project A to make
sure it still does what Product X needs it to do. Note that the Ayende-
type dev passionately working on Project Z benefits because he's now
interoperating with an open source project he can examine and fix
instead of black box that leaves him at the mercy of the software
company to recognize and fix issues.

Sounds great, right? So what's the catch? Well, here are some typical
problems that come up:
* Product manager: "So this is going to be out there with our name and
our brand on it, and other people will be modifying it in ways we
can't necessarily control, and using it in ways we can't determine? I
don't think so."
* Lawyer: "What about product liability? No one's going to sue the
open source devs on this if something goes wrong, because they aren't
a legal entity and they don't have any money. They're going to sue us.
I don't think so."
There are lots more objections of that kind. If you think those
objections sound silly or trivial, well, then that probably explains
why you're a dev and not a lawyer or marketing professional.

The solution? The software company contributes the code to Component A
to the CPF, and when their devs work on Component A they do so under
the auspices of the CPF rather than as employees of the company. The
company still has involvement in the project as required by Product X,
but none of the exposure that raises concerns. The company is still
working with a recognized legal entity, rather than an amorphous
community, and that legal entity is the target of any concerns rather
than the company or any project devs.

(2) A software company has Product X that interoperates with another
company's product Y. As an alternative to Y, open source Project Z has
also sprung up and gained popularity. So the better Product X
interoperates with Z, the more of Product X the company will sell.
Project Z contains Component A that handles the bulk of
interoperability, and so the company decides to include Component A in
their Product X. The company will even have devs work on Component A
to improve its interoperability with Product X.

Sounds great, right? What's the catch? Well, here are typical
problems:
* Product manager: "What if the project doesn't prioritize my
features? What if the development path for the project goes in a
different direction? And what are our customers going to think about
3rd party code of uncertain origin in our product?"
* Lawyer: "What if this code unwittingly infringes on somebody else's?
And how are we going to assume liability for 3rd party code in our
product?"
And of course lots more questions like these.

Solution: This is a harder case without a perfect solution. Open
source projects are going to go their own way. That just is the nature
of open source. And a community just is less concerned about liability
than a company, which is a legal entity with assets. At the end of the
day companies will include OSS in their products because competitive
opportunity outweighs business risk, not because there is no business
risk. But if a project is accepted into the CPF, and that acceptance
is with an understanding that the project is working in partnership
with certain software companies, then these concerns can be somewhat
addressed. The CPF serves as a mediating entity, both in a legal sense
and in facilitating coordinated project direction. For companies, this
mitigates risk. For projects, this expands the user base by letting
the project ride on the coattails of a commercial product. That ought
to be a win-win.

[Ayende Rahien]

inline

BTW, please make up product names in the future, keeping track of alphabet soup is hard.

On Mon, Sep 21, 2009 at 8:58 PM, Mark <mark....@gmail.com> wrote:

I'll give you two scenarios of the kind of activity that CPF hopes to
engage in. The CPF did not spring to life in a vacuum, and both these
scenarios are representative of the sort of situation that led people
to think that there was a need for CPF.

(1) A software company has Product X that contains Component A, and
through A the product interoperates with another company's product Y.
As an alternative to Y, open source Project Z has also sprung up and
gained popularity. So the better Component A interoperates with Z, the
more of Product X the company will sell. So the company makes the
business decision that Component A should be released as open source.

That rarely works. OSS doesn't mean that someone else is going to do the work for you for free.
 

They've decided this because it's a relatively self-contained piece of
software that can be open sourced while still enabling them to
productize X, and because they don't have the expertise in product Y
or project Z to dictate how interoperability should go. Better to put
this in the hands of the community where that expertise resides, with
the rights to make needed modifications. Devs from the software
company can continue to work on the now open source Project A to make
sure it still does what Product X needs it to do. Note that the Ayende-
type dev passionately working on Project Z benefits because he's now
interoperating with an open source project he can examine and fix
instead of black box that leaves him at the mercy of the software
company to recognize and fix issues.

Sounds great, right? So what's the catch? Well, here are some typical
problems that come up:

All of which has good, solid answers for them. Your point?
 

* Product manager: "So this is going to be out there with our name and
our brand on it, and other people will be modifying it in ways we
can't necessarily control, and using it in ways we can't determine? I
don't think so."

People can _fork_ it, you control the original source.
 

* Lawyer: "What about product liability? No one's going to sue the
open source devs on this if something goes wrong, because they aren't
a legal entity and they don't have any money. They're going to sue us.
I don't think so."

All OSS licenses (for that matter, all _software_ licenses) include no liability sections.
 

There are lots more objections of that kind. If you think those
objections sound silly or trivial, well, then that probably explains
why you're a dev and not a lawyer or marketing professional.

The solution? The software company contributes the code to Component A
to the CPF, and when their devs work on Component A they do so under
the auspices of the CPF rather than as employees of the company. The
company still has involvement in the project as required by Product X,

Manager: "I have to give my code to Microsoft? We compete with Microsoft on the CRM space, they will use this to hinder us."
Accountant: "What do I put in the "worked for" section for the time they worked for the CPF? We have no contract for work for the CPF, and it is no longer in house work."
Etc...
 

but none of the exposure that raises concerns. The company is still
working with a recognized legal entity, rather than an amorphous
community, and that legal entity is the target of any concerns rather
than the company or any project devs.

(2) A software company has Product X that interoperates with another
company's product Y. As an alternative to Y, open source Project Z has
also sprung up and gained popularity. So the better Product X
interoperates with Z, the more of Product X the company will sell.
Project Z contains Component A that handles the bulk of
interoperability, and so the company decides to include Component A in
their Product X. The company will even have devs work on Component A
to improve its interoperability with Product X.

Sounds great, right? What's the catch? Well, here are typical
problems:

Again, there are solid answers for them right now.

 

* Product manager: "What if the project doesn't prioritize my
features? What if the development path for the project goes in a
different direction? And what are our customers going to think about
3rd party code of uncertain origin in our product?" 

Are you telling me that CPF is going to make guarantees about project futures? I find this unlikely.
By the way, ask the same question about any commercial piece of software.
 

* Lawyer: "What if this code unwittingly infringes on somebody else's?
And how are we going to assume liability for 3rd party code in our
product?"

By the way, ask the same question about any commercial piece of software.
 

[Mark]

Ayende: It may well be that for your situation, CPF doesn't appear to
offer anything helpful. I have no problem with that. We aren't trying
to be all things to all people or all projects. I am not claiming we
offer a unique solution to anything. I can well imagine that you might
think there are better solutions available in situations where we
could be helpful. That's fine.

What I do know is that there are real companies and real projects
struggling with the pain I've described, and that we are in a position
to help them.

I look forward to more of your thoughtful and spirited input. This has
been a great discussion so far.

[John Petersen]

>>
There are lots more objections of that kind. If you think those
objections sound silly or trivial, well, then that probably explains
why you're a dev and not a lawyer or marketing professional.
>>

Mark... I am a lawyer.....:) But I am also a developer (I was a developer first). Are you a lawyer? My guess is you are not....

Sorry... I had to get that out up front. I thought you were aware of my background.

When I was practicing full time, I was heavily involved with startups M&A activity and general transactional matters  - all of which touched upon a variety of IP matters. A big chunk of what I did was set forth the various governance parameters for new entities. Perhaps this adds some color to the questions I have raised and why I have been pressing for more specifics. 

Moving forward, from a legal perspective, the issues you cite are ones I do not see as all that onerous - at least legally speaking. If I license software, I will disclaim liability to the hilt. 

In terms of where the software will go, at the end of the day, it will still be OSS. As Ayende said, people are going to be able to fork it That is the nature of amd beauty of OSS.

I get the idea of what you are talking about in terms of goals. However, I still don't see any specifics on how those goals will be achieved. As a lawyer, I can tell you that the legal issues you raise are not issues at all. i.e, there are any number of simple remedial devices out there that do not require the services of a third party entity such as the CPF. From my perspective, you appear to have corporate-centric perspective on CPF and less of an OSS Project-centric viewpoint - which I think out to be at least a co-equal issue in the matter.

< JVP >

[Ayende Rahien]

Mark,
I believe that I am a member of some of the largest .NET OSS projects that are out there.
I have to question the very purpose of CPF if it can't help those projects.

[Jesse Ezell]

No offense Ayende, you've worked on some of the greatest .NET OSS
projects out there today... but the greatest OSS .NET projects would
be lucky to mop the floor of true OSS projects in other communities.
Projects like GlassFish, Apache HTTP server, GCC, etc. are in a
different world entirely than NHibernate and RhinoMocks. IMO, if the
foundation doesn't enable people to build comparable projects and all
it did was fund little things like RhinoMocks, it would be a complete
waste of time.

[Ayende Rahien]

Jesse,
I am well aware of that.
However, I _am_ living in the .NET space.
If CPF isn't going to do much for the .NET space, my interest in it approaches zero.

[Louis DeJardin]

I believe Jesse's point was more along the lines that something like the CPF could be a missing ingredient in the .NET space for projects of that magnitude.  

[Ayende Rahien]

Great,
HOW?!
I have been asking that for over a week now.

[Louis DeJardin]

In that particular example, hate to say it, but by providing a framework for a bureaucracy?

[Ayende Rahien]

*snort*
bureaucracy isn't going to help OSS, it is going to make things harder
Notice something about the _BIG_ OSS projects, they all have someone paying the bills.

[Louis DeJardin]

As you've said, projects can reach a point where the personal time and energy they can consume is more than the benefit you personally receive. To scale beyond that point, short of finding a replacement BDFL with more spare time, delegating work to a bureaucracy is a valid option.  

Which leaves the question - would the cpf have people paid directly tasked with this type of thing? Or would they coordinate the efforts of interested parties? Anyone know how ASF operates? 

So yeah, point taken that details are needed for this and other things the cpf could do. And as they're not known yet, what steps are planned to figure out those details. And if those steps are not known, there's a serious problem. 

[Ayende Rahien]

inline

On Tue, Sep 22, 2009 at 7:59 PM, Louis DeJardin <louis.d...@gmail.com> wrote:

As you've said, projects can reach a point where the personal time and energy they can consume is more than the benefit you personally receive. To scale beyond that point, short of finding a replacement BDFL with more spare time, delegating work to a bureaucracy is a valid option.  

Huh?
Who pays for that?
 

[Mark]

John Peterson said: "Moving forward, from a legal perspective, the

issues you cite are ones I do not see as all that onerous - at least
legally speaking. If I license software, I will disclaim liability to
the hilt."

I'm not (directly) speaking about legal issues. I'm speaking about
business issues. The concerns I've described are real, and business-
decision makers do struggle with those very points. Engineers get
frustrated because the technically right decision isn't always the
right business decision. Lawyers get frustrated because being legally
in the rigth isn't always sufficient for the business.

Open source exists at a complicated confluence of business, legal, and
technical decision-making. In the fifteen+ years I've been working on
what we now call open source, I've seen a lot of effort put forth and
tremendous progress made technically. I've also seen a lot of good
thought and progress on legal / licensing / patent issues. But let's
not lose sight of the fact that business decision-makers trump
technical or legal recommenders every time. And I would suggest that
our collective thinking about the business of open source is in a much
less mature state. This was the challenge we tried to address when I
edited "Open Sources 2.0" 6 years ago.

The relationship between software businesses and open source projects
is still poorly understood on both sides. I think it's awesome that
Microsoft has recognized that, and recognized that it's an important
enough issue to warrant something like the CodePlex Foundation. I know
we owe you all a great deal yet on specifics. I can only ask for
patience. We launched -- by design -- without a rigid, complete plan.
We asked for input, and you all have been great at providing that. We
need some time to digest all of that and respond in more detail, but I
assure you we will. It's been less than 2 weeks since our launch, and
I think you'll see steady progress at working through this dialog and
providing details in the days and weeks ahead.

[John Petersen]

Hi Mark...

I agree with you that making the business case is of paramount import.

I look forward to your presentation.

< JVP >

[scott...@gmail.com]

More than just paying the bills, they have BIG organizations (IBM,
Oracle, Apple) heavily invested in the PROJECT ITSELF. Not just the
use of the project.

There's a vast difference between "we use this project because it
makes our developers happy and more productive" and "we make money off
of this project"

[Ayende Rahien]

Scott,
There is a lot of precedence of companies that make money out of an OSS project and decide to contribute to that project.
Linux is probably the best example of that, but even in the .Net world, we have a company (iMeta) that put dedicated developers for helping develop NHibernate.

[Pablo Barrera]

Hello

2009/9/23 sc...@lazycoder.com <scott...@gmail.com>

More than just paying the bills, they have BIG organizations (IBM,
Oracle, Apple) heavily invested in the PROJECT ITSELF. Not just the
use of the project.

There's a vast difference between "we use this project because it
makes our developers happy and more productive" and "we make money off
of this project"

theres no doubt, that the "non profit" mission is for create a better profit in respective organization with their own biz.
with the leadership of Icaza, is guarranted the perfect balance between both world, because he understands both
sides. "Fear of" some administrative issues, needed by corporation ( yes, could be a weak point, but its up to corporations ),
are not the main goal of the foundation.

I think that everyone here on this list, or the "real life project", wants, to became a sucessfull project.
 

On Sep 22, 9:48 am, Ayende Rahien <aye...@ayende.com> wrote:
> *snort*
> bureaucracy isn't going to help OSS, it is going to make things harder
> Notice something about the _BIG_ OSS projects, they all have someone paying
> the bills.

Nothing new, but this project, its about how to make this better on CodePlex Foundation.
Lets no forget, that this movement is "historic".


Regards
Pablo Barrera