5 ms·

I find it really sad when projects grow enough that they start seeing user input as a burden. It's usually the beginning of the end and a sign of the hubris th

I find it really sad when projects grow enough that they start seeing user input as a burden. It's usually the beginning of the end and a sign of the hubris that tends to grow out of popularity. Both the author and GitHub itself are guilty of this. Docker is another good example. They've stopped listening because they have become too smart for users. When your userbase grows you need to evolve your methods not make it harder for users to communicate their needs.

derefr 11y ago
They've stopped listening because now they have two classes of users: multi-million dollar enterprise contracts, and everyone else. I guarantee you that they're very responsive to the "users" in the former class. And really, I don't think there's a good solution to this problem: almost all SaaS businesses are built on the premise that all the free users who join in the beginning are a loss-leader on the path to acquiring the enterprise contracts. Even bootstrapped companies are not immune. The pool of non-enterprise users just can't support engineers' salaries on their own. The only real way to avoid the eventuality of a SaaS service focusing its resources on its enterprise customers, is to just avoid using SaaS services. Maybe use FOSS projects like Gitlab instead. Though, even then, the people who build themselves up as experts on that FOSS project will—with nearly the same inevitability—be hired as employees by some company that wants to sell support contracts for that FOSS project to enterprises. I work at such a company; we're just as enterprise-focused as anyone else, and we've basically sucked our FOSS ecosystem dry of developers who would be heavy user-focused contributors, redirecting their attention (via their salaries) to the enterprise needs. So, really, I'm not sure if there's any viable solution for most projects. Some projects, with enough reach, can thrive off having multiple competing corporate sponsors—that's when you see committees like WHATWG or Khronos forming, so all the corporate contributors with conflicting enterprise needs can tug at one-another. But nearly nothing has that level of reach.
- op00to 11y ago
  This happens when you don't keep a strong firewall between upstream and downstream. When the enterprise development team is also the upstream team, it's a lot harder to say "no, we don't like this shitty idea that $bigCompany asked for".
  - derefr 11y ago
    Our company (which runs an ASF project you probably have heard of as SaaS for enterprise customers) is pretty well-separated. Separate bug trackers with dual tickets, separate mailing lists, etc. The problem is that our corporate developers make up about 80% of the developers on the upstream ASF project. We took the ASF developers and hired them. There are people who want to get things done in the upstream project, and they try... but they just don't have the resources, because most of the people on the project are busy doing their jobs. Excluding corporate-support-contract-of-this-project employees from having contributor rights to the upstream project might work, but then you get the opposite problem: a downstream that's increasingly diverged from the upstream (because if the customers want a feature, but upstream won't take the patch, forking is pretty much necessary) where the "free core" of the upstream begins to stagnate because (in relative terms) nobody's eyes are on that code.
- cbhl 11y ago
  It's worth noting that both GitLab (with GitLab Enterprise customers) and Phabricator (with Facebook) are themselves both prone to this problem.
  - epriest 11y ago
    Facebook has had essentially no involvement in Phabricator for several years.
- deleted 11y ago
  [deleted]
- timv 11y ago
  It's no just "free users" that can suffer from this. A company I worked for has outsources some payments infrastructure to a third party. That third party had put in a very aggressive bid in order to win our business. We were to be their "big name customer" and they wanted to use that deal to gain credibility with other potential customers. It seemed like a rational business decision for them, and we took the deal. But, the fact is, that deal wasn't commercially sustainable, and we both suffered from it. They lost money on everything they did for us, and because they were losing money they tried to do everything as quickly and cheaply as they could, which inevitably meant badly. We were never happy with their offering. When the time came to renegotiate the deal, we went back out to market, and we invited them to participate in the tender process, but we were very clear - "This is the SLA we expect. These are the penalties we will apply if you miss the SLA. We intend to hold you to them. If you submit a bid, make sure it is commercially viable, and that you can afford to actually deliver on the SLA, or else you will end up losing a lot of money on this." I think we ended up sticking with them for a bit longer (due to politics and inertia) and then eventually ditched them a few years later.
sangnoir 11y ago
> I find it really sad when projects grow enough that they start seeing user input as a burden Low quality bug reports waste everyone's time: I don't know of any developer who would disagree (open source or not, paid work or volunteering). If the "user input" is low quality bug reports, then it is a burden. Complaining that Issues enables low-quality bug reports isn't hubris.
- jcoffland 11y ago
  Yes users have to be trained and you need guys who's sole job is issue triage.

derefr 11y ago

They've stopped listening because now they have two classes of users: multi-million dollar enterprise contracts, and everyone else. I guarantee you that they're very responsive to the "users" in the former class. And really, I don't think there's a good solution to this problem: almost all SaaS businesses are built on the premise that all the free users who join in the beginning are a loss-leader on the path to acquiring the enterprise contracts. Even bootstrapped companies are not immune. The pool of non-enterprise users just can't support engineers' salaries on their own. The only real way to avoid the eventuality of a SaaS service focusing its resources on its enterprise customers, is to just avoid using SaaS services. Maybe use FOSS projects like Gitlab instead. Though, even then, the people who build themselves up as experts on that FOSS project will—with nearly the same inevitability—be hired as employees by some company that wants to sell support contracts for that FOSS project to enterprises. I work at such a company; we're just as enterprise-focused as anyone else, and we've basically sucked our FOSS ecosystem dry of developers who would be heavy user-focused contributors, redirecting their attention (via their salaries) to the enterprise needs. So, really, I'm not sure if there's any viable solution for most projects. Some projects, with enough reach, can thrive off having multiple competing corporate sponsors—that's when you see committees like WHATWG or Khronos forming, so all the corporate contributors with conflicting enterprise needs can tug at one-another. But nearly nothing has that level of reach.

op00to 11y ago
This happens when you don't keep a strong firewall between upstream and downstream. When the enterprise development team is also the upstream team, it's a lot harder to say "no, we don't like this shitty idea that $bigCompany asked for".
- derefr 11y ago
  Our company (which runs an ASF project you probably have heard of as SaaS for enterprise customers) is pretty well-separated. Separate bug trackers with dual tickets, separate mailing lists, etc. The problem is that our corporate developers make up about 80% of the developers on the upstream ASF project. We took the ASF developers and hired them. There are people who want to get things done in the upstream project, and they try... but they just don't have the resources, because most of the people on the project are busy doing their jobs. Excluding corporate-support-contract-of-this-project employees from having contributor rights to the upstream project might work, but then you get the opposite problem: a downstream that's increasingly diverged from the upstream (because if the customers want a feature, but upstream won't take the patch, forking is pretty much necessary) where the "free core" of the upstream begins to stagnate because (in relative terms) nobody's eyes are on that code.
cbhl 11y ago
It's worth noting that both GitLab (with GitLab Enterprise customers) and Phabricator (with Facebook) are themselves both prone to this problem.
- epriest 11y ago
  Facebook has had essentially no involvement in Phabricator for several years.
deleted 11y ago
[deleted]
timv 11y ago
It's no just "free users" that can suffer from this. A company I worked for has outsources some payments infrastructure to a third party. That third party had put in a very aggressive bid in order to win our business. We were to be their "big name customer" and they wanted to use that deal to gain credibility with other potential customers. It seemed like a rational business decision for them, and we took the deal. But, the fact is, that deal wasn't commercially sustainable, and we both suffered from it. They lost money on everything they did for us, and because they were losing money they tried to do everything as quickly and cheaply as they could, which inevitably meant badly. We were never happy with their offering. When the time came to renegotiate the deal, we went back out to market, and we invited them to participate in the tender process, but we were very clear - "This is the SLA we expect. These are the penalties we will apply if you miss the SLA. We intend to hold you to them. If you submit a bid, make sure it is commercially viable, and that you can afford to actually deliver on the SLA, or else you will end up losing a lot of money on this." I think we ended up sticking with them for a bit longer (due to politics and inertia) and then eventually ditched them a few years later.

sangnoir 11y ago

> I find it really sad when projects grow enough that they start seeing user input as a burden Low quality bug reports waste everyone's time: I don't know of any developer who would disagree (open source or not, paid work or volunteering). If the "user input" is low quality bug reports, then it is a burden. Complaining that Issues enables low-quality bug reports isn't hubris.

jcoffland 11y ago
Yes users have to be trained and you need guys who's sole job is issue triage.