A conversation with Mark Shuttleworth about upstream collaboration and the role of copyright assignment. Sept 14, 2010 My original comment on Mark's blog post http://www.markshuttleworth.com/archives/517#comment-333616: Mark, As a vocal critic I’ll stand up and say right now, as I have in the past, that the papercuts projects its absolutely the best thing I’ve seen that leverages Ubuntu’s position as an end-user focused effort. Papercuts, every time I’ve checked, exceeds what I expect as a sincere effort to drive fixes upstream. But Papercuts, sadly, is the exception that makes the rule. And its a relatively new effort. Honestly I wish everything Canonical was doing to interact with upstream was patterned on papercuts. For example, there is a long rich history of misgivings about how Launchpad, by design, aggregates competing translation efforts downstream of projects like KDE and GNOME, and has yet to be sorted out in a way that would make the Launchpad translation workflow feedback as an enhancement to the upstream projects without a lot of additional human effort. If Launchpad had at its inception had a _papercuts_ view of downstream translations how much different would the workflow look now? And how much better would the perception of Canonical/Ubuntu has an upstream friendly downstream be? And if you were _just_ integrating and polishing existing code things would be different. But Canonical is most assuredly writing new code and new features. More worrisome, that the bulk of this new code and new features are under copyright assignment polices which make it difficult to build cohesive development communities around. Copyright assignment to a for-profit entity greatly retards project contributor growth. History tells the lesson. Does Canonical really need copyright assignment for libzeitergist? Really? Canonical must let go of copyright control if you want projects like the new touch framework convenience libraries to flourish. Canonical needs to let go of sole copyright control as an enticement for wider contribution and adoption. if you want to take a lesson away from Red Hat, that is the lesson you need to learn. Do you really think libvirt would be as widely reused as a foundational technology in virtualization if Red Hat had required copyright assignment for it? And moreover, you have personally raised the profile of Canonical and Ubuntu as a target for criticism because you have personally been on a mission to publicly evangelize your opinion about how upstream projects need to work more tightly together, on timescales that most directly benefit your chosen development model.. without offering up manpower to upstream projects to help with release management to make that vision a reality. If you are going to challenge project development workflows, expect pushback from the developers to earn your place at the bully pulpit. Is that 200,000 desktop deployment contract involved a potentially renewable landscape services revenue? Or just a one-time occurring migration revenue? -jef ---- Sept 15, 2010 Mark's first reply to me in private email: On 14/09/10 18:11, Jef Spaleta wrote: > For example, there is a long rich history of misgivings about how Launchpad, by design, aggregates competing translation efforts > downstream of projects like KDE and GNOME, and has yet to be sorted out in a way that would make the Launchpad translation workflow > feedback as an enhancement to the upstream projects without a lot of additional human effort. If Launchpad had at its inception had a > _papercuts_ view of downstream translations how much different would the workflow look now? > And how much better would the perception of Canonical/Ubuntu has an upstream friendly downstream be? As it happens, the database design of LP's translation engine (which I did) specifically tracks upstream seaprately from what;s in the package, for the very reason that the intent was to make that bidirectional flow smooth. If you have a critique, direct it to the developers, or contribute a patch since it is in fact open source. But you are mistaken if you think there is a malicious one-way feature designed in on purpose. In many cases, LP was designed to make upstream's life easier. Every distro has bugs and patches, only LP systematically tries to keep track of things in a way that upstream can engage with. By demonising that effort, you are more likely to disincentivise the LP folks from finished their work there, than actually get a better result. > And if you were _just_ integrating and polishing existing code things would be different. But Canonical is most assuredly writing new code and new features. Yes, we are writing new code. Where there are gaps, or opportunities to do things better, we're taking up those challenges. Surely that counts as contributing new upstream code to the body of free software? I don't see that contributing a new memory manager to the kernel is any more valuable than contributing bzr, or contributing Unity. > More worrisome, that the bulk of this new code and new features are under copyright assignment polices which make it difficult to build cohesive development communities around. That's not my observation at all. I think there are a vocal group who demonise compyright assignment, but when done well there is very little friction. Folks run code, find problems, fix them and contribute the fixes. They feel *good* about doing so, their contribution is appreciated. > Copyright assignment to a for-profit entity greatly retards project contributor growth. Do you have evidence for that assertion? I don't. I've seen many projects thrive with copyright assignment. More importantly, when a project drops out of the headlines, having integral copyright keeps someone with an incentive to continue to invest in the project, while the crowd moves on. Did you notice that Intel dropped the copyright assignment requirement for clutter, right after they said they'd adopt Qt for Meego, and that Matthew Allum has now left Intel? So Clutter has gone from being something that OpenedHand was incentivised to lead, to something that Intel was incetivised to lead, to something that nobody is incentivised to lead. It will almost certainly fade ;-) > History tells the lesson. Does it? Which lesson? There are certainly projects that thrive without assignment. They are things which, like the Linux kernel, will always attract contribution regardless. Other things, like Gtk, have struggled. GNOME is facing a major problem for the lack of investment in Gtk. Perhaps, had we been more thoughtful of this issue in the past, we would have a bigger ecosystem around Gtk today. > Does Canonical really need copyright assignment for libzeitergist? Really? Is assignment too much to ask on a patch that someone whipped up and wants to contribute? Really? > Canonical must let go of copyright control if you want projects like the new touch framework convenience libraries to flourish. No, I disagree. I think that assignment is an easy thing to use as a blocker to adoption if you want to be political about it. But if you're willing to go there, you can use anything else you want as an excuse not to adopt something. > Canonical needs to let go of sole copyright control as an enticement for wider contribution and adoption. if you want to take a lesson away from Red Hat, that is the lesson you need to learn. Do you really think libvirt would be as widely reused as a foundational technology in virtualization if Red Hat had required copyright assignment for it? Yes I do :) > And moreover, you have personally raised the profile of Canonical and Ubuntu as a target for criticism because you have personally been on a mission to publicly evangelize your opinion about how upstream projects need to work more tightly together, on timescales that most directly benefit your chosen development model..without offering up manpower to upstream projects to help with release management to make that vision a reality. If you are going to challenge project development workflows, expect pushback from the developers to earn your place at the bully pulpit. If you disagree with cadence as a great approach to open source roadmap management, by all means make the case. But I think you'll find that the trend is very definitely in favour of cadence. And if you think it works for individual projects, then the case for cadence-thinking at the systemic, FLOSS-ecosystem level, is very strong too. And if things move in that direction, Ubuntu would adjust its cadence to fit with the ecosystem. I pointedly have NOT said "you should work to our schedule". I've said "working to a schedule works well, it will work well across projects too, here are some arguments about why some cadences are better than others, let's work it out". Perhaps you could point out the part which is not logically in the interest of the whole ecosystem? Mark ---- Sept 15, 2010 My first private email respose to Mark: Since you decided to take move this discussion in private, I need to ask the following question. Do I have your explicit permission to repost this email in its entirety and all follow-up emails in their entirety to a public forum of my choosing and then use that publicly archived location as an authoritative reference for citation in future discussions. I've no compelling interest to hold a private conversation with you as I don't really think a private conversation with you will prove to be constructive as neither of us can be held accountable for what we say in a private conversation. So before I reply in full. Please let me know if I have your permission to repost this conversation in a publicly archived manner. -jef ---- Sept 15, 2010 Mark's second private email respose to me: On 15/09/10 20:21, Jeff Spaleta wrote: > Since you decided to take move this discussion in private, I need to > ask the following question. > Do I have your explicit permission to repost this email in its > entirety and all follow-up emails in their entirety to a public forum > of my choosing and then use that publicly archived location as an > authoritative reference for citation in future discussions. I've no > compelling interest to hold a private conversation with you as I don't > really think a private conversation with you will prove to be > constructive as neither of us can be held accountable for what we say > in a private conversation. I can. > So before I reply in full. Please let me know if I have your > permission to repost this conversation in a publicly archived manner. > Sure. Mark ---- Sept 15, 2010 My second private email to Mark: On Wed, Sep 15, 2010 at 5:31 AM, Mark Shuttleworth wrote: > if you think there is a malicious one-way feature designed in on purpose. Did I say it was malicious? I did not. I do not ascribe to malice which can be explained to...youthful exuberance. (I know the exact quote is incompetence but even that's too harsh for what I'm trying to say) What I said is there is a long track record of misgivings from upstream projects concerning how competing translations (which differ from what the upstream translation community is doing) are aggregated in launchpad instead of being integrated upstream. I went further and suggested that if the mental construct of the papercut project, and its upstream submission focus, had existed at the beginning of Launchpad's translation offering then perhaps the workflow around it would look much different now and there would have been less friction concerning how translations are being done in Launchpad downstream of projects like KDE. > > In many cases, LP was designed to make upstream's life easier. Every > distro has bugs and patches, only LP systematically tries to keep track > of things in a way that upstream can engage with. For the sake of argument, I'll accept that the intention was to make life easier for upstream projects. I'll go talk to some upstream project people who aren't using Launchpad for development (easy enough to find there are thousands of projects on launchpad like that), and see if they'll talk about their experience interacting with LP. If they provide critical feedback on their frustration will you refrain from casting it as a demonization of LP and take it as a good faith effort to drive feedback meant to be constructive? > > By demonising that effort, you are more likely to disincentivise the LP > folks from finished their work there, than actually get a better result. Did I in fact demonize? Hmm. I don't remember calling them evil or diabolical. I didn't even call them a failure. What I did was suggest that the approach inherent in the papercut project is something that should be replicated and pointed to the translation workflow as an example where the papercut mindset could reap significant benefits. Especially as you say the design goal was to make life easier for upstreams. If singling translations out as an example is demonization, I could add more examples so they don't feel singled out. I'm more than happy to spread the criticism around across other Canonical led efforts. I think you are more than adequately aware that my well of criticism is deep. I've no fear that we'll exhaust it any time soon. Though your response begs the question.. is every critique that would suggest that mistakes have been made a demonization to you? That's not necessary a good trait for someone holding the reins for a company that needs to be nimble and avoid bad decisions as much as its needs to cultivate good opportunities. > Yes, we are writing new code. Where there are gaps, or opportunities to > do things better, we're taking up those challenges. Surely that counts > as contributing new upstream code to the body of free software? I don't > see that contributing a new memory manager to the kernel is any more > valuable than contributing bzr, or contributing Unity. No one has made an effort to count contribution to the total body of available open source code. What effort that has been made has been in the context of common components that are widely reused. The linux kernel, the plumbing layer, and most recently the GNOME codebase. A lot of things fall outside of those efforts. Things like spacewalk, amd the Fedora directory server..and all of the fedora build infrastructure like koji and mirrormanager...none of those things get counted either...even though they are inherently valuable to people. If you want to draw the boundary of relevance in a different way than what has been done so far, and cast the net wider, and want to do a systematic accounting of code contribution across a much wider space than what has been done so far...that would be interesting to see. I'm not really sure its going to change the overall picture of corporate involvement much. If for example KDE were included, Red Hat's involvement would be depressed somewhat, but noone would be shocked by that. But the fact remains that when you specifically state in interviews that Canonical is working with the GNOME community.. but you aren't showing up in the contribution stats in GNOME. People are going to reactive negatively to the incongruency between what you personally say and what the contribution stats say. http://video.golem.de/desktop-applikationen/3312/mark-shuttleworth-interview-auf-dem-linuxtag-2010-in-berlin.html But more to the point it really comes down to what contribution means. Is Android as a differentiated kenel in and of itself a contribution to the open source ecosystem? Using your definition, then yes it is. But such a definition defeats the point of the original argument that GKH was making about upstream involvement in the context of the kernel. You have to remember that this whole discussion about Canonical's contribution level is in actuality a sidebar to a discussion meant to entice/shame/conjole/browbeat _Google_ into contributing to the mainline kernel more. Canonical came up only offhandedly in the Q/A between GKH and Google staffers and then it snowballed because Canonical employees got defensive at the offhanded remark after the video from the talk he gave to a room full of Google staffers. Noone was really expecting Canonical to shine brightly in the kernel..except for the Canonical people who reacted strongly the GKH's offhanded response from a Google staffer. What we have been doing since then is a quixotian romp across the software landscape attempt to find the pocket of the landscape where Canonical is a shining example of technical leadership to substantiate that initial defensive reaction at feeling undervalued so offhandedly. The more we look, the more the original remark is validated the more defensive Canonical is becoming. The Google staffer who originally asked Greg about Canonical's contribution must be laughing his ass off at what he touched off with his snarky question. Though I will say the inherent value of bzr is an interesting point of discussion, considering how pervasive git usage is now outside of Launchpad. I look forward to the day with Launchpad is re-engineered to use git as a backend to better align Canonical long term interests with the general direction that the ecosystem is headed. >> More worrisome, that the bulk of this new code and new features are under copyright assignment polices which make it difficult to build cohesive development communities around. > > That's not my observation at all. I think there are a vocal group who > demonise compyright assignment, but when done well there is very little > friction. Folks run code, find problems, fix them and contribute the > fixes. They feel *good* about doing so, their contribution is appreciated. Again with the demonization... sigh. Such characterization of opponents to your view does not bode well for the project Harmony discussions. Since I can't actually name names thanks to the Chatham House rules, I will say that I see very little support for for-profit assignment in the archived Harmony discussion. Can you show me an example outside of Canonical where a corporate entity has done copyright assignment well in your opinion? I'll show you one where copyright assignment has retarded contribution. OpenOffice.org. Quite recently in fact we've seen potential contributors from Novell lament the fact that the copyright assignment policy for OpenOffice keeping a specific feature circulating downstream as a patch to be reimplemented anew more than a year later because of the copyright assignment requirements. > Did you notice that Intel dropped the copyright assignment requirement > for clutter, right after they said they'd adopt Qt for Meego, and that > Matthew Allum has now left Intel? So Clutter has gone from being > something that OpenedHand was incentivised to lead, to something that > Intel was incetivised to lead, to something that nobody is incentivised > to lead. It will almost certainly fade ;-) That a great bit of analysis. Remind me again, what is your new Unity interface based on? Isn't it Clutter?. Are you implying that Unity will also move to Qt because Canonical is not incentivised to lead clutter development even though Unity depends on it? Hmm...interesting. You leave so much left unsaid. I'll go further and turn your argument on its head. Copyright assignment to a for-profit entity only incentivizes a single entity...the single copyright owner. Other potential contributing entities are dis-incentivized to contribute and instead are incentivized to re-implement instead of re-using. Copyright assignment to a single for-profit entity does not build multi-entity partnerships around a technology. Who really other than Google at this point can just plow ahead and go it alone as a business and take on the entire cost of technology development for a platform? Surely not Canonical. > >> History tells the lesson. > > Does it? Which lesson? There are certainly projects that thrive without > assignment. They are things which, like the Linux kernel, will always > attract contribution regardless. Other things, like Gtk, have struggled. > GNOME is facing a major problem for the lack of investment in Gtk. > Perhaps, had we been more thoughtful of this issue in the past, we would > have a bigger ecosystem around Gtk today. And Canonical copyright onwership of chunks of a Gtk based stack are going to fix these problems? This paragraph is ripe with additional implication that Canonical is going to follow Meego and rebase inhouse efforts around Qt. > >> Does Canonical really need copyright assignment for libzeitergist? Really? > > Is assignment too much to ask on a patch that someone whipped up and > wants to contribute? Really? Depends on the patch and the entity asking for assignment. > >> Canonical must let go of copyright control if you want projects like the new touch framework convenience libraries to flourish. > > No, I disagree. I think that assignment is an easy thing to use as a > blocker to adoption if you want to be political about it. But if you're > willing to go there, you can use anything else you want as an excuse not > to adopt something. Make no mistake, copyright is most assuredly politics at a very fundamental level. Requiring assignment is just as much politics as choice of copyright license is politics as the both impact how the code can be used in the future and who has the rights to do what with the code on down the line. If everything were MIT or BSD licensed and anyone could just take the code and run with it...no biggie. But when copyright assignment to a for-profit entity is coupled with GPL in anticipation of building a framework for future proprietary business model for that single entity...totally different situation...and makes for a much more complicated assessment of the strategic and political value of collaborating on that codebase versus reimplementing. > If you disagree with cadence as a great approach to open source roadmap > management, by all means make the case. But I think you'll find that the > trend is very definitely in favour of cadence. > > And if you think it works for individual projects, then the case for > cadence-thinking at the systemic, FLOSS-ecosystem level, is very strong too. > > And if things move in that direction, Ubuntu would adjust its cadence to > fit with the ecosystem. > > I pointedly have NOT said "you should work to our schedule". I've said > "working to a schedule works well, it will work well across projects > too, here are some arguments about why some cadences are better than > others, let's work it out". Perhaps you could point out the part which > is not logically in the interest of the whole ecosystem? I've expressed no opinion either way. What I have said is changing in development workflows are going to require manpower to institute release management objectives. If you aren't bringing manpower to the table when you talk _at_ upstream projects about what you think is in their best interests...expect pushback. Lets see what's not covered...oh right my question about whether the 200,000 desktop contract includes a Landscape contract. Maybe you just clipped it by mistake. I'll ask it again. The 200,000 desktop deployment contract you mentioned, is that include a Landscape management subscription contract and thus represents the potential for recurring revenue or is it just a one-time migration payment? Thanks again for giving me permission to repost this private email conversation. -jef