On Oct 18, 2012, at 4:18 PM, Miguel Di Ciurcio Filho <[email protected]> wrote:
> On Thu, Oct 18, 2012 at 2:33 PM, Luke Kanies <[email protected]> wrote: >> >> I would *love* to have more work on Puppet coming from outside of our >> organization. I've always wanted that, and it's always pained me that we >> never really figured it out. >> >> How do we do this? It's not as simple as just giving a bunch of people >> commit access, is it? > > No, that is not going to help at all. Want to really have more > contributions? Short answer: _get rid of the bureaucracy_ > > Now the long answer, based on what is written in CONTRIBUTING.md. > > 1) Drop the CLA. > > - > http://www.flamingspork.com/blog/2012/05/28/contributor-agreements-kill-contributions/ > > "A low barrier to entry is what has made the largest, most successful > free software projects what they are today. If you’re wanting your > project to be an open source project and not an open source product – > then you too must set a low barrier to entry. Contributor Agreements > significantly raise the barrier to entry. Suddenly my 10 line patch to > fix a bug turns into a discussion with my company lawyers, your > company lawyers and goes from taking an extra 5 minutes to send an > email with a patch to a mailing list into something that takes hours > and hours of my time." > > - > http://blogs.computerworlduk.com/simon-says/2010/11/contributor-agreements-say-your-contribution-is-unwelcome/index.htm > > " If you're a company hoping to create a new open source project, take > heed; that advice you are getting to have a contributor agreement may > well lead to you getting no co-developers. As long as that's what you > want - well, I suppose that's OK, but intentionally discouraging > community is hardly the open source way." > > - https://lwn.net/Articles/414051/ (LPC: Michael Meeks on LibreOffice > and code ownership) > > This LWN article is a must read, including the comments. But I would > highlight this: > "Copyright assignment does not normally deprive a contributor of the > right to use the contributed software as he or she may wish. But it > reserves to the corporation receiving the assignments the right to > make decisions regarding the complete work. We as a community have > traditionally cared a lot about licenses, but we have been less > concerned about the conditions that others have to accept. Copyright > assignment policies are a barrier to entry to anybody else who would > work with the software in question. These policies also disrupt the > balance between developers and "suit wearers," and it creates FUD > around free software license practices." Note that we don't require copyright assignment and never have. We have a nearly-standard Apache CLA, which just confirms that we have the right to distribute the code you're contributing. We're actually in the process of figuring out whether we can remove these. Every lawyer we're talking to is saying no, but every one of us wants to get rid of them, so I expect us all to end up ignoring the lawyers. The only reason we instituted them in the first place is because we were GPL'd, and we expected to either make commercial forks (which we didn't do) or switch licenses (which we did). > 2) Drop the requirement for accounts on GitHub and Redmine. > > Why can't I just `git send-email` patches to the mailing list, receive > feedback on the mailing list, `git send-email` again, maintainer > applies the patch. > > Requiring to have a ticket/issue for every single code contribution > does not make sense. > > Look at all the steps and requirements for submitting a simple patch. > There is a lot of back and forth, copying and pasting URLs on the > ticket, etc. I'm surprised to hear this. I would expect that github would be dramatically easier for contribution than emailing or whatever. I know that I personally never was able to extract patches from a mailing list, because I use IMAP, not mboxes. Yes, I know I could do filtering, set up mutt explicitly for this, and relearn how to use it just for patches, but… I could also just go to github and see a clean, clear list with support for comments, email, and everything else I want. I could see reducing to one account type, but I couldn't see us ever switching to email for patch management unless git changes its expectations of how people do email to include the actual internet. No, I'm not bitter. :/ I'd prefer to have tools to automatically sync redmine and the pull requests, rather than getting rid of one. We've done a lot of work there for syncing redmine and trello, for instance, but I don't think we've done much with github yet. > 3) Develop and discuss stuff in public > > You guys said a few days ago that Dashboard is getting axed and a new > ENC is on the works. Well, would you mind to share what is being > worked on? Design ideas? You might want to get some feedback early. We do a lot of this, but we're mixed in how consistent we are. Part of the reason is just the mixed bag of lots of us sitting in the same room - it's more expensive to communicate with people outside the building, so we tend to suck at it more than we should. I will say that I'm still a bit gun-shy of posting all of our ideas publicly, at least anything other than stuff we're basically ready to work on now. I'm a bit gun-shy for 2 reasons: First, I do have some legitimate competitive concerns, but most importantly, it's a lot of work to get it all out there and there's questionable value. That being said, we should obviously be more open about what we know we're going to work on and what we think we're going to build. We just recently split dev teams so that our OSS developers are much more independent of the commercial teams, which means that they'll naturally start looking outward more. In the short term, I'll commit that we'll publish the ENC stuff ASAP. Note that I'm stepping out as a rogue CEO here and I've no idea of the actual consequences of my statement here, but it should clearly be open from the beginning. Note, though, that we've been doing a lot of work already talking to as many people as possible about this, so it's not like we've been just doing all of the thinking inside our walls. > How about before doing anything new, send to this list some simple > RFCs. Look back at the first link of point 1, it is written there a > great question: are you an open source _project_ or an open source > _product_? We should do way more here, I agree. I don't actually know the difference between an open source project and an open source product. It's all just free code on the internet, right? > Bottom line: > > Summing up points 1 and 2, it will continue to be hard to have new > volunteers. New volunteers begin fixing typos, and all these > requirements will never motivate new blood to come along and hack I > include myself in this, mostly because of the CLA. Just so I understand, is the problem with the CLA just a too-high barrier of entry, or is it that you don't agree to the terms? -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
