Maintainers-surveys 2021

Jump to: navigation, search

2021 Maintainers's Survey

Survey organized by ddemaio@suse.com & nycticorax@opensuse.org, ran from 07.10.2021 01:00 to 03.11.2021 17:01. Send us an email to access the full dataset.

Data tabulated by nycticorax@opensuse.org on the 7th of November 2021 at 19:49 UTC+1.

Values for "answers" are plain numbers. All other values are percentiles, unless mentioned otherwise.

Key takeaways

Demographics.

Maintainers & packagers:

  • are mostly male (95%)
  • live in Western Europe (peaking at 57.7% on the UTC+1/2 timezones, with a handful in the Americas (6%) and Far East Asia (6%)

Education and work

Maintainers & packagers:

  • either have or are pursing a university degree (74.8% overall)
  • usually work or have been working in IT for at least one year (68.75% on average)

Platforms

Maintainers & packagers:

  • mainly use the mailing lists and IRC (Libera) to work with one another (58.6%)
  • don't rely on Matrix very much (9.6%)
  • see the mailing lists and IRC (Libera) as the most appropriate platforms for daily work
  • see the mailing lists and the forums as the main source of news about the distributions and the community
  • see Reddit as a promising platform for recruiting new contributors/members

Maintainership

Maintainers & packagers:

  • are few to contribute for less than 1 year (18%)
  • are numerous to contribute for more than 3 years (41%)
  • interact with 11.34 people on average for devel projects
  • find it easy to identify who to work with for their tasks (53%), with 22% uncertain and only 25% who clearly don't find it easy
  • find it easy to find ways to contribute with others (55%), with 29% uncertain and barely 14% who disagree or strongly disagree
  • find it somewhat difficult to know what to prioritize in their work (only 46% find it easy)
  • find it quite difficult to know what end users need or want (only 28% find it easy, with 35% uncertain)
  • find it somewhat difficult to determine what's good for the distributions or the Project (only 36% find it easy, with 38% uncertain)
  • find it easy to sync with the pace of upstream (only 20% disagree, with 16% uncertain)
  • overwhelmingly agree that the projects and packages need more contributors (71%, with 22% uncertain)
  • think that recruitment for projects and packages is / would be difficult (only 13% think it would be easy)
  • a slight majority of contributors are uncertain whether, or don't think that, enabling, teaching and mentoring new contributors would be easy (56%)

Satisfaction

Maintainers & packagers:

  • are satisfied with the state of the target package sources, specifications and documentation (79% at least satisfied)
  • are satisfied with the state of devel packaes, libraries and compilers (78%)
  • are mostly satisfied with the state of osc-cli (70% satisfied or very satisfied)
  • are 'neutral' with regards to the opi-cli client (70%)
  • are mostly satisfied with the state of build.opensuse.org (64% satisfied or very satisfied)
  • are mostly satisfied with the state of work communication channels (only 22% less than satisfied)

Suggestions and comments

Respondents have made interesting suggestions:

Overall, lack of clear best-practices and documentation in packaging routines are the most cited causes of dissatisfaction and the most desired objects of improvements.

Demographics

gender

answers: 182

  • male: 95 %
  • female: 2.7 %
  • non-binary: 2.3 %

age

answers: 199

  • 25 and less: 19 %
  • 25-34: 26 %
  • 35-49: 42 %
  • 50+: 12.5 %

hemisphere

answers: 199

  • Northern: 86.9 %
  • Southern: 13.1 %

timezone

answers: 199

UTC (removed below 5%):

  • +8: 6 %
  • +2: 47.2 %
  • +1: 10.5 %
  • -3: 6 %

Education

have a university degree

answers: 187

  • Yes: 59.3%
  • No: 40.7%

are pursuing a university degree

answers: 187

  • Yes: 15.5%
  • No: 84.5%

Work

have been doing a job in IT for at least 1 year

answers: 187

  • Yes: 71.2 %
  • No: 28.8 %

currently doing a job in IT

answers: 187

  • Yes: 66.3 %
  • No: 33.7 %

Platforms

most used to facilitate maintenance/packaging

answers: 145

  • mailing lists: 38.6 %
  • forums: 4.1 %
  • Matrix: 9.6 %
  • IRC(Libera): 20 %
  • Telegram: 5.5 %
  • Discord: 5.5 %
  • Reddit: 6.2 %
  • Other: 10.3 %

Are there specific aspects of the openSUSE communication channels worth improving which you'd like to mention?

answers: 16

  • Matrix
  • The communications channel work well but , as written before, should require a real mentoring program to form a new contributor
  • It is hard to motivate anyone from upstream to care about packaging. Thus the communication does not even get started in an openSUSE environment.
  • The wealth of real time communication options effectively means I won't attend any on a regular basis, user base is too split. Don't need to close any down but give a clear guidance on what you recommend going forward.
  • Discord, a proprietary channel, is prominently used, without working bridges to free platforms such as Matrix.
  • More surveys so the community can better shape the future of and participate in the project.
  • Telegram should be moderated by individuals who care for contributors, and not allow it to be a constant source of negativity towards the people building our distributions
  • The current channels are enough. But it seems that many contributors who are from SUSE rarely communicate with the community on these channels.
  • Reducing them... sticking with the Forums, Mailing lists and IRC.
  • Keep personal differences with members as away as possible from discussions.
  • Code of conduct enforcement needs to be improved. There are a lot of things that go unmoderated that aren't really okay.
  • The mailinglists are a toxic swamp, the discord community is pretty great on the other hand but rather quiet lately.
  • Why isn't there a page which sums up the public communication channels? planet.opensuse.org only collects blog entries. It would be very cool to have an "openSUSE dashboard" page, which integrates wiki, news, blogs, packages - and all the communication channels above in one tool. Should be customizable, of course. But this would allow to have the latest information in one place - instead of searching for them in each tool individually.
  • The Matrix server is still not functioning properly, despite being actively advertised. Bots and bridges are down and federation is lagging heavily.
  • No central place, communication is distributed across everything.

good for...

answers: 40 (removing further than 20% from top 2)

  • mailing lists:
   - 52 %: learning about upcoming events and activities relevant to your work as a contributor
   - 42 %: woking with others in your team
  • forums::
   - 41 %: socializing, chatting
   - 38 %: learning about upcoming events and activities relevant to your work as a contributor
  • Matrix:
   - 48 %: hanging out, socializing, chatting
   - 38 %: working with others in your team
  • IRC /Libera:
   - 61 %: working with others in your team
   - 30 %: hanging out, socializing, chatting
  • Telegram:
   - 43 %: hanging out, socializing, chattings
  • Discord:
   - 43 %: hanging out, socializing, chattings
  • Reddit:
   - 36 %: hanging out, socializing, chattings
   - 33 %: recruiting new contributors
   - 26 %: learning about upcoming events and activities relevant to your work
  • Other:
   - 10.3 %

Maintainership

how long been maintaining devel projects

answers: 78

  • 1-3 months: 4 %
  • 3-6 months: 9 %
  • 6-12 months: 5 %
  • 1-2 years: 15 %
  • 3-5 years: 35 %
  • forever: 6 %

how many people do you interact with on a regular basis for devel projects

answers: 76

  • average: 11.34 %
  • std deviation: 38.98 %

easy to identify who to work with

answers: 85

  • strongly agree: 13 %
  • agree: 40 %
  • uncertain: 22 %
  • disagree: 20 %
  • strongly disagree: 5 %

it's easy to find a way of working with others

answers: 85

  • strongly agree: 14 %
  • agree: 41 %
  • uncertain: 29 %
  • disagree: 8 %
  • strongly disagree: 7 %

it's easy to know what to prioritize in your work

answers: 85

  • strongly agree: 12  %
  • agree: 34 %
  • uncertain: 32 %
  • disagree: 2 %
  • strongly disagree: 1 %

it's easy to know what end users need or want

answers: 85

  • strongly agree: 6  %
  • agree: 22 %
  • uncertain: 35 %
  • disagree: 26 %
  • strongly disagree: 9 %

it's easy to determine what's good for the distributions or the Project

answers: 85

  • strongly agree: 8  %
  • agree: 28 %
  • uncertain: 38 %
  • disagree: 20 %
  • strongly disagree: 5 %

it's easy to keep in sync with the pace of upstream

answers: 85

  • strongly agree: 16  %
  • agree: 46 %
  • uncertain: 16 %
  • disagree: 15 %
  • strongly disagree: 5 %

our devel projects / packages need more contributors

answers: 85

  • strongly agree: 38  %
  • agree: 33 %
  • uncertain: 22 %
  • disagree: 4 %
  • strongly disagree: 0 %

if our devel projects / packages needed more contributors, it would be easy to it's easy to recruit some

answers: 85

  • strongly agree: 6  %
  • agree: 7 %
  • uncertain: 40 %
  • disagree: 24 %
  • strongly disagree: 20 %

if our devel projects / packages needed more contributors, it would be easy to enable / teach / ment them

answers: 85

  • strongly agree: 8  %
  • agree: 32 %
  • uncertain: 33 %
  • disagree: 15 %
  • strongly disagree: 8 %


Satisfaction

with the openSUSE tools and toolchain

as far as target package sources, specs & docs

answers: 80

  • Very satisfied: 18 %
  • Satisfied: 61 %
  • Neutral: 21 %
  • Less than satisfied: 10 %
  • Dissatisfied: 3 %

as far as devel packages, libraries, compilers

answers: 80

  • Very satisfied: 26 %
  • Satisfied: 51 %
  • Neutral: 21 %
  • Less than satisfied: 1 %
  • Dissatisfied: 0 %

as far as osc-cli

answers: 80

  • Very satisfied: 29  %
  • Satisfied: 41 %
  • Neutral: 21 %
  • Less than satisfied: 8  %
  • Dissatisfied: 1 %

as far as opi-cli

answers: 80

  • Very satisfied: 6 %
  • Satisfied: 14 %
  • Neutral: 70 %
  • Less than satisfied: 6  %
  • Dissatisfied: 4 %

as far as obs web

answers: 80

  • Very satisfied: 16 %
  • Satisfied: 48 %
  • Neutral: 19 %
  • Less than satisfied: 15  %
  • Dissatisfied: 3 %

as far as communication channels

answers: 80

  • Very satisfied: 15 %
  • Satisfied: 40 %
  • Neutral: 22 %
  • Less than satisfied: 15  %
  • Dissatisfied: 8 %

Are there other tools or aspects of the ordinary routines you would like to mention as good targets for improvements? Which improvements would you like to see?

answers: 33

  • Automatic tracking of upstream updates. This could be done by specifying RSS or ATOM url in spec file. When an update is available it would send an email to maintainer.
  • the 'osc collab' toolchain is underused and, especially for topic-based projects, can be of great help. Saldy, it is quite a fragile piece of code (no real developer caring for it)
  • Should be there much more collaboration from opensuse project versus new contributor. Even if the contributor is a prepared person , can't resolve problems if hasn't full collaboration. It takes a long and useless time to do that.
  • Building Docker containers is possible but the naming of the containers is unflexible atm in my opinion. Researching build errors is nearly impossible on your own because most of the documentation is outdated or not existant.
  • Better source control for packages, as it is very important in case packages carry patches.
  • All documentation around source services
  • Devel packages for Leap should be newer. So it can easy update packages, because Leap packages are sometimes very, very old. I don't speak about basic system.
  • "maintainer fatigue" in some long-term contributors
  • Bugzilla
  • It's next to impossible to get packages into Factory that build on multiple distros. I sometime have the impression that a single %if in a spec trigger a refusal.
  • the openSUSE communication channels need to become a safe space for contributors, and not a constant lynch mob from entitled non-contributing users who critique, but not contribute
  • rpmbuild
  • 1. An automated upstream version update scraper and notification service, for example next to the package in devel project or by mail. Like yeah there is a project for that, dead, "why would you need that?", "no, OBS team will not provide service like that". Other distros have that, the data can be shared. 2. Per-package statistics of package downloads. "Why would OBS team implement that?" 3. Make packagers' documentation up to date and complete. For example a complete documentation of the .service file directives, that's also discoverable (yeah the word itself does not make it easy). 4. Make the wiki up to date, better structured, archive pages with obsolete products or versions or hardware. 5. OBS web interface usability is degrading with each update, that's a lost battle, but needs to be mentioned. 6. Review membership in many devel projects. Lots of people do nothing, never reply, never ack/review/contribute. 7. Push more packages from devel projects to Factory. Please.
  • There are no clear communication channels. In Matrix chats it's hard to find support.
  • I'd appreciate git based OBS, that seem to be standard nowadays. Our software-o-o / appstore
  • git integration in the OBS workflow * better upstream mononitoring (e.g. integration of releasemonitoring.org) * store meta-information for pacakges: + where to find proper upstream changelogs + upstream bugtrackers/mailinglists + eventually links to packages from other distributions
  • build.opensuse.org and osc is very good. Though there is a learning curve. software.opensuse.org and opi is, unfortunately, a mess. Malformed one-click installs, still not working for 15.3, users not understanding the reliability of main vs devel vs home repos, lack of protections for common user mistakes like clicking the wrong distribution, there is a lot of scope for improvement here.
  • never heard of opi-cli before - but I'm using TW since more than 5 years now as dev I developed my own tools to fill some packaging tools' gaps: https://github.com/sebix/packaging-utils/
  • More detailed guides on how to create packages and reference on .spec files
  • The OBS docs are still outdated or incomplete.
  • Generally the who packaging process is cryptic and undocumented and relies on "who you know" which excludes a lot of people.
  • OBS is just far too complicated for the average user/packager.
  • openSUSE Wiki - in many places it's outdated and chaotic.
  • It is difficult to express relationships, for example, python-boto3, python-botocore and aws-cli packages generally need to be updated together. If someone "kust want to help" and they are not familiar with this interconnection submit requests generally need to get rejected or someone familiar with the connections has to run after the person trying to help to "clean up".
  • I would love to see more focus on overall design of both the product as well as processes, workflows and tools for contributors. Individual packages as well as tool for contributors are all good but the openSUSE distribution is lacking as a consistent user-centric experience, e.g. no easy graphical OS version upgrade assistent (compare to Ubuntu) but support lifetimes of about only a year for individual product versions. For contributors there is easy starting point to see where help would be most needed but individual contribution areas are not linked, e.g. wiki, translation, fixing packages in OBS, fixing tests in openQA, etc.
  • 1. It would be good to have a unique view of a package corresponding to the different active projects (devel, Factory, TW, Leap:15.x), like different branches in a gitk version tree. A comparison between the devel and the maintenance projects is a bit hard. 2. If SUSE likes to have a hand on a package, then the maintainer from SUSE should be available and reply/contribute in a timely manner.
  • The new OBS UI is very good in certain points, but not very handy in others. Unfortunately, UI developers re reluctant to suggestions....
  • Integration of Matrix (account link?) in the packager profile? Maybe even create Matrix channels for big OBS projects - and integrate them in the WebUI?
  • Better tools to check licensing
  • One clear channel (like opensuse-announce@opensuse.org in former times), that informs about any important change. Infrastructure issues, news.o.o hints, latest forum infos or similar could be combined into a good "weekly news".
  • The web interface of OBS does not work as expected in things what works with osc commands. Rebuilds are not triggered as expected as an example and you receive wrong messages after successful builds.
  • Automatic tracking of upstream updates. This could be done by specifying RSS or ATOM url in spec file. When an update is available it would send an email to maintainer.
  • Java packaging is still a nightmare. I thought about updating the Eclipse IDE as it is very old, but kept downloading pre-compiled tarballs from eclipse.org instead due to the hassle.
  • the 'osc collab' toolchain is underused and, especially for topic-based projects, can be of great help. Saldy, it is quite a fragile piece of code (no real developer caring for it)

Three improvements you would like to see happen within the Project

answers: 33

  • 1. At the moment i only see a lack of collaboration. A contributor is forced to do the job almost alone
  • 1. Death to vendored packaging. 2. Better Documentation. 3. Keep going with the Git Integration
  • 1. OBS web usability
  • 1. documentation of source services and how to actually use them is too high level or missing
  • 1. target package sources, specs & docs: Better OBS / RPM Spec Documentation. 2. openSUSE communication channels: Easier way to find out if a maintainer is still actively working on a package or not
  • 1. Devel packages for Leap should be newer.
  • 1. a tool to share tasks among co-maintainer. 2. a way to see where is the primary communication channel of a specific package. 3. packaging guide
  • 1. Faster Web UI
  • 1. De-emphasise/reduce influence of non-contributors in the project. 2. Provide safe spaces for contributors to collaborate. 3. Focus on encouraging contributors to contribute for their own benefit, not the mythical benefit of others - altruism is not a sustainable motivator
  • 1. Download build dependencies through osc.
  • 1. Better documentation for novices.
  • 1. Increased visibility in external media.
  • 1. More control over whether OBS build results are promoted to end users or not. Broken packages show up next to working ones with no way to show this in the software.o.o inteface. 2. Overhaul of software.opensuse.org. Many users, rightly or wrongly, now assume it is the first stop for installing software. 3. (To help with software.o.o) Stricter maintenance of metadata associated with packages, and new types of metadata, including e.g. package maintenance status and suitability for end-users.
  • 1. Fix the RTL8192EU Kernel Driver. 2. Add out of the box support for dlna support. 3. Add some thing like "cast to device" for streaming media files to dlna renderer
  • 1. less manual work needed. 2. tools to keep the packages automatically up to date with upstream. 3. better documentation and examples, automatic utilities for services files, and the ability to use them in factory, have them executed automatically (less need for manual updates)...
  • 1. Better documentation of available RPM macros. 2. Improving the download speed of api.opensuse.org for local builds. 3. More robust source management (osc is pretty fragile). Maybe git could help, and we store source tarballs with git-lfs?
  • 1. Give more visibility to the packaging docs and keep them up to date. 2. Keep the enviroment casual but professional - personal differences and ideologies should be kept away from discussions as much as possible
  • 1. Documentation. 2. Attention to human interaction psychology and workflows (usability)
  • 1. openSUSE Wiki
  • 1. less manual work needed. 2. tools to keep the packages automatically up to date with upstream. 3. better documentation and examples, automatic utilities for services files, and the ability to use them in factory, have them executed automatically (less need for manual updates)...
  • 1. make interdependencies visible/settable by maintainers
  • 1. easy graphical OS version upgrade assistent
  • 1. Make the upgrade of a Base package shared with SLES more transparent. It's usually extremely hard to get the latest version into next Leap:Y.X, and we had new releases with a 3-year old version of the package.
  • 1. more mentoring and conference sessions to increase visiblity and collaboration
  • 1. Better options within installer
  • 1. Include usage information (downloads?) about a package in build.o.o 2. Provide an own GitLab, please. Pagure is brain-dead.
  • 1. central communication plattform
  • 1. Fix OBS messages with wrong statements after successful builds via web interface
  • 1. I would like to use openQA, but I don't understand how to set it up locally.
  • 1. more AppStore feeling within the distro
  • 1. A lot of the packaging is done by undocumented convention -> should be documented
  • 1. Less self-entitled documentation writers, more collaboration with developers. 2. More emphasis on contributors, not non-contributing users
  • 1. static libs for system programs

Which libraries, system applications or packages are you maintaining, packaging or developing? NB: You can list devel projects (example: devel:tools:building, network:utilities) and/or individual packages (example: python-dbus-python, sonnet...)

Processing...

Suggestions/comments about this survey or other relevant aspects of the Project you'd like to see improve

answers: 12/18 (removed comments exclusively about the survey)

  • In general, this project is awesome but lacks the documentation and collaboration to motivate a contributor. It should only require an initial period following a real mentoring program about whatever opensuse project....after that I think that all be able work for you.
  • I am puzzled that none of the ticket tracking options or OBS' internal messaging and task options show up when asking on how I coordinate with other people.
  • Perhaps I missed that, but where are packagers/maintainers communicates?
  • I hope this still adds up here: - Better out of the box codec support (Eg asking in the installer if all relevant non-free codecs should be installed as well) - YaST Installer easy mode similar to Ubuntus (while keeping the current one as advanced) - Better out of the box GPU detection and setup the required packages/drivers maybe by using an assistant. Like: Would You like to use closed source or open source drivers? Is power management important for your Laptop? (Because the nv driver does not support power management on all GPU architectures while in some scenarios the use of suse-prime or bbswitch is not the best default choice) eg.
  • Don't try to go the "openSUSE" way everywhere. Be more open to accept solutions from the outside.
  • Good that the survey is here. Lots of thnigs need improving on the tooling side, packaging is essential but utterly boring. Asking for features or giving feedback falls on deaf ears or is met by snarky comments or "we won't do that". Feedback in a form of survey may help to expose and identify the problematic areas, I hope.
  • Be more specific in asking for location. There's no meaning in learning that almost everyone is in the Northern emisphere.
  • regular surveys are a great idea!
  • Please bring up the quarterly releases of existing distributions (like Leap 15.3) as announced. I still hate to roll-out new machines in my infra because of the increasing amount of updates...
  • Packaging sucks and people are moving away from it towards docker etc
  • "it's easy to know what end users need or want" doesn't matter - openSUSE is built by contrubtors
  • Good that the survey is here. Lots of thnigs need improving on the tooling side, packaging is essential but utterly boring. Asking for features or giving feedback falls on deaf ears or is met by snarky comments or "we won't do that". Feedback in a form of survey may help to expose and identify the problematic areas, I hope.
Retrieved from "https://en.opensuse.org/index.php?title=Maintainers-surveys_2021&oldid=160724"