One more I'll add which is touched on a little below. Contributors spawn from a healthy Userbase/Operatorbase. If their needs are not met, then they go elsewhere and the contributor base shrinks. OpenStack has created artificial walls between the various Projects. It shows up, for example, as holes in usability at a user level or extra difficulty for operators juggling around so many projects. Users and for the most part, Operators don't really care about project organization, or ptls, or cores or such. OpenStack has made some progress this direction with stuff like the unified cli. But OpenStack is not very unified. I think OpenStack, as a whole, needs to look at ways to minimize how its archetecture impacts Users/Operators so they don't continue to migrate to platforms that do minimize the stuff they have the operator/user deal with. One goes to a cloud so you don't have to deal so much with the details.
Thanks, Kevin _________________________________ _______ From: Zane Bitter [zbit...@redhat.com] Sent: Monday, April 23, 2018 1:47 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier? On 23/04/18 10:06, Doug Hellmann wrote: > [This is meant to be one of (I hope) several conversation-provoking > questions directed at prospective TC members to help the community > understand their positions before considering how to vote in the > ongoing election.] > > Over the last year we have seen some contraction in the number of > companies and individuals contributing to OpenStack. At the same > time we have started seeing contributions from other companies and > individuals. To some degree this contraction and shift in contributor > base is a natural outcome of changes in OpenStack itself along with > the rest of the technology industry, but as with any change it > raises questions about how and whether we can ensure a smooth > transition to a new steady state. > > What aspects of our policies or culture make contributing to OpenStack > more difficult than contributing to other open source projects? > > Which of those would you change, and how? There's probably two separate groups we need to consider. The first is operators and users of OpenStack. We want those folks to contribute when they see a problem or an opportunity to improve, and their feedback is extremely valuable because they know the product best. We need to encourage new contributors in this group and retain existing ones by: * Reducing barriers to contributing, like having to register for multiple services, sign a CLA &c. We're mostly aware of the problems in this area and have been making incremental progress on them over a long period of time. * Encouraging people to get involved. Low-hanging-fruit bug lists are useful. Even something like a link on every docs page indicating where to edit the source would help encourage people to take that first step. (Technically we have this when you click the 'bug' link - but it's not obvious, and you need to sign up for a Launchpad account to use it... see above.) Once people have done the initial setup work for a first patch, they're more likely to contribute again. The First Contact SIG is doing great work in this area. * The most important one: provide prompt, actionable feedback on changes. Nothing kills contributor motivation like having your changes ignored for months. Unfortunately this is also the hardest one to deal with; the situation is different in every project, and much depends on the amount of time available from the existing contributors. Adding more core reviewers helps; finding ways to limit the proportion of the code base that a core reviewer is responsible for (either by splitting up repos or giving cores a specific area of responsibility in a repo) would be one way to train them quicker. Another way, which I already alluded to in my candidacy message, is to expand the pool of OpenStack users. One of my goals is to make OpenStack an attractive cloud platform to write applications against, and not merely somewhere to get a VM to run your application in. If we can achieve that we'll increase the market for OpenStack and hence the number of users and thus potential contributors. But those new users would be more motivated than anyone to find and fix bugs, and they're already developers so they'd be disproportionately more likely to contribute code in addition to documentation or bug reports (which are also important contributions). The second group is those who are paid specifically to spend a portion of their time on upstream contribution, which brings us to... > Where else should we be looking for contributors? Companies who are making money from OpenStack! It's their responsibility to maintain the commons and, collectively speaking at least, their problem if they don't. For a start, we need to convince anybody who is maintaining a fork of OpenStack to do something more useful with their money. Like, for example, building it into a big pile and setting fire to it to keep warm. Maybe education is something that can help here. For a lot of folks, OpenStack is their first direct contact with an open source community. If we could help them to learn why contributing is in their best interest, and how to do it effectively, then we could make some progress. It's pretty remarkable that there are Foundation board members still asking the TC to direct employees of other companies to work on the stuff they want them to for free. cheers, Zane. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
