Hi all, This email is an attempt to provide a relevant summary of a discussion from the cloudstack-private list. It's largely a re-hash of things that have already been discussed, but we wanted to get this summary moved into the dev list so that the points are available for reference. We should probably distill this into a wiki page somewhere, but that's not done quite yet (volunteer?). Keep in mind that I've tried to pull the important parts of the conversation into this email... it was a fairly long thread of discussion and debate. I'd suggest reading it all the way to the end to form your own understanding of why we have to be careful about how we work as a community.
The TL;DR version: The issue that we ran into with several features being developed "outside the community" for 4.1 was a major deal, and it had several implications. First, doing that effectively hurts our community. The other issue is related to the legal right of the project to accept the code developed elsewhere. And on to the discussion: Alex started the relevant conversation with the following: On Thu, Jan 10, 2013 at 09:39:26AM -0800, Alex Huang wrote: > I'm still no clear on this issue. > > What's the difference between the following? > > - Someone discussed what they want to do on the mailing list, > started working on it on their computer, 3 months later, > pushes 30 commits and 1500 lines of code into ASF. > - Someone discussed what they want to do on the mailing list, > started working on it on a private branch, 3 months later, > merges 30 commits and 1500 lines of code into ASF. > > I understand the community aspect of this and agree it's not > good for the community but how is this different to ASF? > > Or is the problem the code was released? So in that case, I > want to ask this question. > > - Someone starts a public branch and does everything right in > terms of discussion and updates to community and the code is > in the public eye but, for whatever reason, needed to release > this branch before an official CS release. It's not official > release from apache and it's not made to community members. On > CS's next release, that branch is merged into CS and is part of > official CS release. > > What's the ramifications in this case? > > --Alex I followed up: On Thu, Jan 10, 2013 at 04:27:16PM -0500, Chip Childers wrote: > On Thu, Jan 10, 2013 at 12:39 PM, Alex Huang <alex.hu...@citrix.com> wrote: > > I understand the community aspect of this and agree it's not > > good for the community but how is this different to ASF? > > If it's one person working on their own, then I don't think it's > anything more than a community issue for either one of the above > items. Both don't show a very good integration with the community for > the work, but it wouldn't be a blocker IMO. > > > Or is the problem the code was released? So in that case, I want to ask > > this question. > > We are talking about something different from just an individual > working on code and not communicating well. I'm specifically > concerned about a commercial entity paying for that work under the > auspices of a commercial software product (which isn't an open source > product), that product being publicly / commercially released, and > then (which is the bit for us to figure out) that same code being > donated to Apache. > > Does the distinction I'm making make sense? This is obviously a bit > muddy, but the story above is the one that we're facing. > > > - Someone starts a public branch and does everything right in > > terms of discussion and updates to community and the code is > > in the public eye but, for whatever reason, needed to release > > this branch before an official CS release. It's not official > > release from apache and it's not made to community members. On > > CS's next release, that branch is merged into CS and is part of > > official CS release. > > > > What's the ramifications in this case? > > If the code was committed or submitted to the project before the > commercial release, I think that's one situation. And in that > scenario, I don't think there is a problem at all. That's the joy of > the ASLv2! It's also the same scenario if the code was in a publicly > visible repo, coupled with community discussion on the development > activity. IMO, that's OK too! > > However, if the code wasn't submitted to the project (commit or > otherwise) or even made visible to the project as an OSS activity > prior to the commercial release, then I think we have to deal with it > differently. Most of the legal concern I have is around the question > of knowing the express intent of the commercial entity when funding > the developer to do the work, and there being ambiguity in what that > intent was. > > I had a good chat with Brett, and he pointed out that there are two > aspects to the acceptance of code that is from a questionable source > (like the scenario above). Brett - please clarify if I am > interpreting our irc conversation incorrectly, but this is what I took > away from it. > > First, there is the question of the contract that allows the code > submission. If the code was developed completely by the person > submitting it, and they have an ICLA on file (this is critical), then > the contractual situation is OK for the submission. If the person > does NOT have an CLA, then the software grant or CLA is needed. If > there were more than one collaborator on the code, this gets more > complicated... > > The second part of the acceptance has to do with process. The IP > clearance process can accept code that is coming in via a grant or via > a CLA. It's goal is to be the procedure used by the ASF to ensure > that the appropriate due diligence has been exercised by the > foundation, prior to accepting code developed outside of an ASF > project. > > As I said in the scenario breakdown above, my concern is about > ensuring that the project (and the ASF) are in a strong position to be > certain about the provenance of any code in our repo. Questionable > provenance (caused by the scenario above) should mean that we trigger > the IP clearance process. > > Does my line of thinking make sense? Brett replied to Alex's initial questions with: On Fri, Jan 11, 2013 at 01:08:13PM +1100, Brett Porter wrote: > > On 11/01/2013, at 4:39 AM, Alex Huang <alex.hu...@citrix.com> wrote: > > I'm still no clear on this issue. > > > > What's the difference between the following? > > > > - Someone discussed what they want to do on the mailing list, > > started working on it on their computer, 3 months later, > > pushes 30 commits and 1500 lines of code into ASF. > > - Someone discussed what they want to do on the mailing list, > > started working on it on a private branch, 3 months later, > > merges 30 commits and 1500 lines of code into ASF. > > > > I understand the community aspect of this and agree it's not > > good for the community but how is this different to ASF? > > There's no difference in these cases (or the one below). If a significant > amount of work lands, it's a good idea to question the providence and > formalise its history (and have a good chat to that committer!) > > > - Someone starts a public branch and does everything right in > > terms of discussion and updates to community and the code is > > in the public eye but, for whatever reason, needed to release > > this branch before an official CS release. It's not official > > release from apache and it's not made to community members. On > > CS's next release, that branch is merged into CS and is part of > > official CS release. > > > > What's the ramifications in this case? > > I challenge the "everything right" part of this statement. Why not > commit it to the ASF repository on a branch? Git as a DVCS is very > capable of allowing a downstream product to pull those changes onto > the release branch you refer to. Make the ASF repository the > upstream - and then all these discussions go away. > > There are certainly legitimate situations where something might be > developed for a commercial product first, and a decision is made > later to contribute it to ACS, and that's fine. But if something is > intended to be part of ACS from the outset, that's the place it > should be developed. And Brett commented on my response to Alex: On Fri, Jan 11, 2013 at 01:08:13PM +1100, Brett Porter wrote: > > As I said in the scenario breakdown above, my concern is about > > ensuring that the project (and the ASF) are in a strong position to be > > certain about the provenance of any code in our repo. Questionable > > provenance (caused by the scenario above) should mean that we trigger > > the IP clearance process. > > > > Does my line of thinking make sense? > > That's really the key thing to take away. Start there for anything > developed outside the ASF, and then figure out what is needed both > legally and community-wise to make it an acceptable contribution. > > I don't think there's a lot of benefit to analysing the different > situations that might come up. Optimise the process for the happy > path, and deal with concrete exceptions as needed. The last things I > want to have happen is that there are special rules to make > accepting work outside the ASF easier when it was intended to be > developed within the project, or conversely for the PMC to have to > spend a bunch of time processing paperwork for contributions. > > It's probably best we continue this on dev@ for everyone's benefit if > there is more to be said? I'm slowly catching up on the related threads... Alex then asked: On Thu, Jan 10, 2013 at 06:12:27PM -0800, Alex Huang wrote: > Hi Brett, > > Let me clarify. When I say 'everything right' I do mean that it is > branched on ASF git repo and everything is done publicly including > all checkins. Just that they couldn't wait for the CloudStack > release to happen before they release. Is there any ramifications > in this case? To which Brett replied: On Fri, Jan 11, 2013 at 01:43:50PM +1100, Brett Porter wrote: > > Sorry that I misinterpreted you. There should be no ramifications > here - an entity can take ACS source, re-badge, customise and add to > it, and release it as another product as long as they comply with > the terms of the Apache License. In addition, any contributions > they've made to the project, they can do with as they please since > they still own them. So there's no problem pulling in a branch or > cherry-picking from the ASF Git repo and releasing it before ACS > have. > > (I'm assuming good faith here, there could be some community issues > with an entity that routinely did that in a way detrimental to the project). > > Just be careful with the way you use "they" in that sentence and remember > that even if it is the same person or an overlapping group of people, there > are distinct roles there between doing the work for ACS, and the > responsibilities they have with their employer to produce a release of the > commercial product that includes it. And an attempt to summarize the conversation from Alex: On Thu, Jan 10, 2013 at 07:52:22PM -0800, Alex Huang wrote: > Thanks Brett! I think it's very clear now and I think it jives with Chip's > response. > > Let me summarize and you guys can look this over. > > - Work and collaborate as individual contributors in public for the > code. > > - If the organization the individual contributor works for have a > legitimate need for the code to be private for the time being, it > can be but when it is contributed back, depending on the > contribution size, the contribution may have to go through IP > Clearance process. I think Chip has layout the intricacies here > so I won't repeat. > > - If the organization the individual contributor works for needs to > release earlier, it is fine as long as the all the work was done > in a manner that befits the first point and the release complies > with the terms of the Apache license. > > I think the above are actually very reasonable and flexible enough > to satisfy both the demands on individual contributor and an > organization's responsibility to their customers. To which David replied: > So a couple of warnings ahead of time - this is likely to be long > winded, and I apologize. Also, I am firmly wearing my ACS PPMC hat > here, and have hidden my Citrix employee hat in the closet. > > So while I recognize that employers and even individuals may have a > legitimate need or desire for code to be private for the time being, > from an Apache CloudStack perspective it is almost universally > deleterious to our community building efforts, and to our existence. > While I don't expect anyone to be a free software hippie mooching free > wifi from starbucks and coding simply because they enjoy it, I do > think some perspective is important and it we as a PPMC need to > realize the effect that this action has on the project. What it says, > especially to nascent members of the community is: We really can't be > bothered to engage with the community, work through the processes, > solicit feedback early and often, or invite them to participate. > Perhaps it is even seen as saying 'We don't want your help, we want to > do it our way, and you can take it or leave it when we are done with > it, because our needs have been met." (I'll also point out that this > was the early attitude of Xensource folks to the Linux kernel > community). > > My personal expectation is that from a committer this should NEVER > happen. From a newcomer, perhaps it will happen, but it should be the > exception rather than the rule, and we should always be encouraging > collaborative development. (Look at how often IP Clearance happened in > other Apache communities below) > > I liken bad behavior like this to other deleterious behavior, like > eating poorly. It can be indulged occasionally with little long term > effect, but a pattern of bad behavior has effects that are exponential > and long lasting. > > As much as ACS is a highly technical project, you simply can't escape > the social and community aspects. People hate surprises, and people > want to know that the project, and the people in the project care > about them and care about the success of the project, and about their > participation, and the above behavior has the effect of illustrating > that it doesn't. Again, I don't expect a company full of Richard > Stallman, and I realize that it is a balancing act to weigh the > competing demands of the project, internal management and customers, > but if this is a habit, people will walk away with the following > impressions: > > * People don't care about the success of the CloudStack community - > they are meeting their commercial needs as they see fit, and flinging > code over the wall in a show of apathy > * People don't care about my involvement, or having my input on the > things the develop > * There is no chance for me to become involved, because by the time I > even learn about something, the code exists and is here. > > I also have to say I am a bit exasperated that this issue continues. > We were discussing it back in late July, and I honestly thought we as > a community understood all of this, we'd had the long drawn out > discussions here and on -dev that I thought sat out expectations - > only to come back and see that for 4.1 we have at least 9 significant > features that have this problem. Moreover we have committers who don't > seem to understand the problem, and are a significant source of these > code flinging exercises. Which leaves me at a bit of a loss as to how > to solve this. Are we not clearly explaining the issue? How do we > solve it? I've pondered whether we should acknowledge that this > behavior is indeed a risk to the project, and politely say 'no thanks' > to code that arrives like this; community is more important than code > after all; or holding committers directly responsible, perhaps even > considering stripping commitership from folks who are actively harming > the community with this behavior. What we've done thus far on the > issue doesn't seem to be very effective. > > Looking at the previous IP Clearance filings - the entire ASF - over > 100 TLPs plus a number of codlings - had 4 filings in 2012. We > potentially will more than double that number just for a single > podling, and we aren't even out of January. > > Also frustratingly, I am of the opinion that we have flubbed the > opportunity to use the 4.1 release cycle as a time to show that we had > this contentious issue, first raised in the 4.0 dev cycle, under > control, and that as a community we were ready for graduation. How do > we demonstrate that we 1) Have this community, particularly the > committers, acknowledge that this is a problem that must be the very > rare exception. 2) that we do value community over code. 3) That we > care about the community and the success of the project. A question was then raised about reconciling the statement about recognizing the possible need for private development against the statement that "from a committer this should never happen", to which David replied: On Sat, Jan 12, 2013 at 11:18:48AM -0500, David Nalley wrote: > > I do recognize that folks have needs and desires for their code to be > private. I also recognize that it's largely inconsistent with the > Apache way of doing things. That said I don't expect that the Apache > expectations will be met 100% of the time, particularly by folks who > are coming to the project new. > > That said, a committer, who should know our process, who is known to > the project, and has earned our trust, I have far higher expectations. > I expect that individual to realize the effects of developing outside > of the community. Yes ultimately he is probably providing a work for > hire and may have little choice in the matter. >
