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." 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. 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. 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_? 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. -- 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.
