Right now the only example of big changes asked by users I can come with is Gnome 3 ... you can guess what would be my answer to the question in the title ;-)
Hey, we think hot corners are cool because they're easy to hit with a mouse - never mind that we're moving to more of a touch friendly interface.
And speaking of touch interfaces, isn't it cool using swipe-to-unlock with a mouse? Users like that!
Oh, we abandoned the old HIG. I mean who needs UI guidelines? Why would users want an icon labeled "email" and not the name of the program?
=====
They have some things really right and some just so wrong. And from what I've read they don't listen as if they have a coherent plan, but it's not really making sense to me what that plan is.
They got responses to 5 questions from 72 OSS developers with projects on SourceForge. There is absolutely no way you can draw any sort of reasonable conclusion from that sample.
That is a good point. Projects that are on sourceforge are going to select for less recently created projects and projects less likely to migrate to a platform with better developer experience.
As a FOSS developer, my aim is to grow the FOSS community in the long term. Number of users, and their real or perceived wants, is only sometimes helpful to this goal. Sometimes it is not, for example when "shiny" is prioritised over solid engineering or security, or when a short-term attention gain from temporary "hired guns" is prioritised over attracting reliable and skilled workers that will help to sustain the community.
"Contribute or shut up" seems to be a common response.
My experience, not extensive mind you, is mixed on the matter. The people who make the communication positive gets my attention, even if they so no. Otherwise, I'll still possibly use the project as needed but I don't feel the need to contribute even if I could.
I think it depends on the project. I get a ton of feature requests that are off the beaten trail. I basically give people the feed back of: We have limited bandwidth, but I'm happy to point you in the right direction.
"Contribute or shut up" worded differently may not be an ideal answer but it's an understandable one. Imagine if you were a resource constrained engineer having hundreds of queries and emails a day about certain things users want and then not only have that feature not be something of interest to anyone but that user but also have it be something that isn't even on your road map.
Technology that's general purpose enough (in our case machin e learning/scientific computing) will give you this.
There's a huge delta between say: a resource constrained but heavily used project and a javascript lib that only provides a slightly better basic widget.
It's no excuse for OSS devs to be rude but I hope you can understand what it looks like from our side a bit.
My experience is that often even when the user comes with a suggestion backed up with a patch, it can be rejected because either they didn't understand how it interacts with other features in the codebase, or the maintenance burden would be too high for too little gain.
Essentially even when you're asking to contribute a patch, you're requesting that someone maintain some code you wrote for an indefinite span of time.
My experience has been that it's much more productive to say "I can't merge that patch into the core, but here is how it would be implemented as a plugin" and ensure your plugin interface is powerful and stable enough to allow people to do what they want.
As a maintainer of an open source project, we often get a lot of proposals from people - my project is a compiler. And while some of them are interesting, there are a few who are suggested by people who don't really have any experience in language design, so usually we have to say no to a lot of features.
When someone knows what they're on about, it's probably the architecture of our project that doesn't allow us to implement a specific feature; or would make it incredibly difficult to do so. And when you're dealing with even larger projects like Nginx or something, you have to work on it to know if something would work in terms of the project, which is tricky unless you've worked on it extensively.
We've even had a guy who said we shouldn't use LLVM because it's slow (it's not), and he didn't like it. What I'm getting at with this point is that some people suggest ideas that a) change the entire course of the project, or b) are kind of silly and subjective.
On my regular job, at Canonical's MAAS team, we do, and we do a lot. The nature of the project makes it easier: it is a very specialized tool for managing primarily physical servers. Our users, therefore, tend to be very knowledgeable and have a very diverse set of problems they need solved.
That, of course, does not mean we don't say "no" or "not just yet".
Even on my own personal projects I tend to say "not yet" more often than not. Sometimes the feature requested makes sense, but the suggested implementation requires some thoughtful design. I've painted myself into corners far too many times before to fall into that kind of trap. As the Zen of Python says, "never" is often preferable to "right now".
I built a big chunk of an open source ml tool (I'm not sharing the name because I keep my life pretty private.) I think part of the problem lies in motivation. Fundamentally, I don't give a shit if anyone but me uses this software. I wrote it because I needed it, and I share it in case someone else finds it useful. Even if it isn't a perfect fit for them, it's a 300 to 500 hour head start on what they need.
Also, for me personally, I ignore users: I don't necessarily know if most of them are assholes, but many of them that interact with me are. For example, many have enormous entitlement issues about hand holding around usage, understanding the results the software gives, etc. Just because you managed the arduous feat of getting an email address and typing out a vague 2 line email, that doesn't mean I'm going to spend hours on you when it's clear you couldn't even be arsed to read the (and they do exist!) docs or usage examples. Better yet, people get pissy when you decline to act as their free consultant. And for the vast majority of people that report a bug -- which may or may not so be -- I'd estimate fewer than 10% can produce a competent bug report: version, what happened, what you expected to happen, and shape and structure of the dataset.
I used to be far more helpful but it both takes a lot of time and the weekly raging assholes -- verbal abuse, forceful demands for assistance, complaints that I didn't promptly respond to email -- that contact me really sucked all enthusiasm for working on the project out of me. I'd find a couple hours, make the mistake of reading the project tag in gmail, get upset, and just get discouraged or unmotivated.
The solution was to basically ignore all email unless they're (1) nice, (2) competent, (3) demonstrate effort on their part to find the solution themselves, (4) document the above in the email, and (5) I'm in the mood. Also, in the history of several years of email, I'm confident that fewer than 10 requests offered to pay me. Ask for my consulting rate and you have my attention.
Back when I did web programming all the time, I had a really good experience reporting a bug to Firefox (where they were incorrectly throwing an exception for something the DOM spec said should be a no-op-- they sent me a t-shirt.)
Around the same time, Chromium added a regression where trying to search for text on a long page would fail to work (I can't remember the details, but it was about of equal severity to the Firefox bug.) My bug to them was completely ignored. (It ended up fixed in the next release, but I don't know how-- my bug was never triaged AFAICT and there weren't any dupes AFAICT. Maybe they had a second, private, bug tracker?)
God knows I've disagreed with a lot of Firefox's design decisions recently, but they really did a good job of engaging with their users. At least back in the 4.x timeframe.
One bit of nuance to this is how one defines "users". An existing open source project (or even perhaps an exiting proprietary product) is likely to think of its users as "those people who currently use the product", while a startup building a product to be sold to a future larger userbase is going to think of them more broadly. The problem with this is that the former is subject to selection bias. All the people who are currently using the product are by selection, those who have the patience to deal with its' usability warts.
Therefore, if an outsider to a project wants to make a change in favor of usability, they have a much harder time overcoming the objection that changing the code might break things.
The same is true on a second level: All of the existing developers of a project are those who are by selection already comfortable with both the development process and the resulting product. If someone wants to join, they have to already be familiar with how the project is structured and how it does things. They probably have to already be comfortable with this. Someone who hates working on projects without automated testing is very unlikely to join such a project and then convince the team to adopt automated testing.
Of course, you can't just let random new people come into a project without pushing back on them; Often their ideas are genuinely bad ideas which come from a lack of understanding & context.
You also can't just join a commercial software project. But you can fork an open source one.
For most open source software projects, the "user base" is developers who like open source software. That's a good thing really; otherwise, there would be nothing that works well for people like me, as all commercial software companies go after the much bigger markets.
I try to (and I work in 5+ opensource projects/libraries).
It's a two-way street here, the users need to also listen and engage with the developers. So don't forget that to, opensource people (especially if they are doing it in there spare/free-time) require working with, not being dictated to ;)
I think that this is a complicated question for two reasons.
1. It probably greatly depends on the open source project. Some developers are probably in tune with their users while other barely realize that users exist.
2. Some people have a different definition of "listening to their users" than others.
Users who want something but don't get it may regard the developer as not listening to them.
The developer, on the other hand, may be hearing everything users are asking for, but aren't implementing everything that's requested because it isn't practical or just doesn't fit in with the scope and future plans for the project.
A developer can't just throw in everything that users want because the result may be a horrible mess. So even if the developer listens to what users are saying and directs the project in a way that makes sense from a long-term perspective, many users may feel like the developer isn't listening to them.
That's really a communications issue. If the developer simply ignores requests because they don't make sense (or makes hostile responses), they're more likely to be regarded as not listening.
If their responses are respectful and they post information about their design decisions and how they are implementing certain requested features and why, then they're a lot more likely to be perceived as listening to their users.
I'm part of two open-source frameworks -- http://deeplearning4j.org and http://nd4j.org -- and I can tell you that we spend about half our time listening to users, fixing bugs they report, adding features they request and improving the docs. It really helps when other users kick in to help.
23 comments
[ 5.0 ms ] story [ 71.3 ms ] threadHey, we think hot corners are cool because they're easy to hit with a mouse - never mind that we're moving to more of a touch friendly interface.
And speaking of touch interfaces, isn't it cool using swipe-to-unlock with a mouse? Users like that!
Oh, we abandoned the old HIG. I mean who needs UI guidelines? Why would users want an icon labeled "email" and not the name of the program?
===== They have some things really right and some just so wrong. And from what I've read they don't listen as if they have a coherent plan, but it's not really making sense to me what that plan is.
A rigorous examination of thing's which most people consider to be obvious is still valuable.
My experience, not extensive mind you, is mixed on the matter. The people who make the communication positive gets my attention, even if they so no. Otherwise, I'll still possibly use the project as needed but I don't feel the need to contribute even if I could.
"Contribute or shut up" worded differently may not be an ideal answer but it's an understandable one. Imagine if you were a resource constrained engineer having hundreds of queries and emails a day about certain things users want and then not only have that feature not be something of interest to anyone but that user but also have it be something that isn't even on your road map.
Technology that's general purpose enough (in our case machin e learning/scientific computing) will give you this.
There's a huge delta between say: a resource constrained but heavily used project and a javascript lib that only provides a slightly better basic widget.
It's no excuse for OSS devs to be rude but I hope you can understand what it looks like from our side a bit.
Essentially even when you're asking to contribute a patch, you're requesting that someone maintain some code you wrote for an indefinite span of time.
My experience has been that it's much more productive to say "I can't merge that patch into the core, but here is how it would be implemented as a plugin" and ensure your plugin interface is powerful and stable enough to allow people to do what they want.
When someone knows what they're on about, it's probably the architecture of our project that doesn't allow us to implement a specific feature; or would make it incredibly difficult to do so. And when you're dealing with even larger projects like Nginx or something, you have to work on it to know if something would work in terms of the project, which is tricky unless you've worked on it extensively.
We've even had a guy who said we shouldn't use LLVM because it's slow (it's not), and he didn't like it. What I'm getting at with this point is that some people suggest ideas that a) change the entire course of the project, or b) are kind of silly and subjective.
TL;DR It's complicated
That, of course, does not mean we don't say "no" or "not just yet".
Even on my own personal projects I tend to say "not yet" more often than not. Sometimes the feature requested makes sense, but the suggested implementation requires some thoughtful design. I've painted myself into corners far too many times before to fall into that kind of trap. As the Zen of Python says, "never" is often preferable to "right now".
Also, for me personally, I ignore users: I don't necessarily know if most of them are assholes, but many of them that interact with me are. For example, many have enormous entitlement issues about hand holding around usage, understanding the results the software gives, etc. Just because you managed the arduous feat of getting an email address and typing out a vague 2 line email, that doesn't mean I'm going to spend hours on you when it's clear you couldn't even be arsed to read the (and they do exist!) docs or usage examples. Better yet, people get pissy when you decline to act as their free consultant. And for the vast majority of people that report a bug -- which may or may not so be -- I'd estimate fewer than 10% can produce a competent bug report: version, what happened, what you expected to happen, and shape and structure of the dataset.
I used to be far more helpful but it both takes a lot of time and the weekly raging assholes -- verbal abuse, forceful demands for assistance, complaints that I didn't promptly respond to email -- that contact me really sucked all enthusiasm for working on the project out of me. I'd find a couple hours, make the mistake of reading the project tag in gmail, get upset, and just get discouraged or unmotivated.
The solution was to basically ignore all email unless they're (1) nice, (2) competent, (3) demonstrate effort on their part to find the solution themselves, (4) document the above in the email, and (5) I'm in the mood. Also, in the history of several years of email, I'm confident that fewer than 10 requests offered to pay me. Ask for my consulting rate and you have my attention.
Around the same time, Chromium added a regression where trying to search for text on a long page would fail to work (I can't remember the details, but it was about of equal severity to the Firefox bug.) My bug to them was completely ignored. (It ended up fixed in the next release, but I don't know how-- my bug was never triaged AFAICT and there weren't any dupes AFAICT. Maybe they had a second, private, bug tracker?)
God knows I've disagreed with a lot of Firefox's design decisions recently, but they really did a good job of engaging with their users. At least back in the 4.x timeframe.
Therefore, if an outsider to a project wants to make a change in favor of usability, they have a much harder time overcoming the objection that changing the code might break things.
The same is true on a second level: All of the existing developers of a project are those who are by selection already comfortable with both the development process and the resulting product. If someone wants to join, they have to already be familiar with how the project is structured and how it does things. They probably have to already be comfortable with this. Someone who hates working on projects without automated testing is very unlikely to join such a project and then convince the team to adopt automated testing.
Of course, you can't just let random new people come into a project without pushing back on them; Often their ideas are genuinely bad ideas which come from a lack of understanding & context.
For most open source software projects, the "user base" is developers who like open source software. That's a good thing really; otherwise, there would be nothing that works well for people like me, as all commercial software companies go after the much bigger markets.
It's a two-way street here, the users need to also listen and engage with the developers. So don't forget that to, opensource people (especially if they are doing it in there spare/free-time) require working with, not being dictated to ;)
1. It probably greatly depends on the open source project. Some developers are probably in tune with their users while other barely realize that users exist.
2. Some people have a different definition of "listening to their users" than others.
Users who want something but don't get it may regard the developer as not listening to them.
The developer, on the other hand, may be hearing everything users are asking for, but aren't implementing everything that's requested because it isn't practical or just doesn't fit in with the scope and future plans for the project.
A developer can't just throw in everything that users want because the result may be a horrible mess. So even if the developer listens to what users are saying and directs the project in a way that makes sense from a long-term perspective, many users may feel like the developer isn't listening to them.
That's really a communications issue. If the developer simply ignores requests because they don't make sense (or makes hostile responses), they're more likely to be regarded as not listening.
If their responses are respectful and they post information about their design decisions and how they are implementing certain requested features and why, then they're a lot more likely to be perceived as listening to their users.