3 ms·

Very nicely explained, as I kept reading it covered all my experiential "yes, but" thoughts. I will add that-knowing- all this is helpful, but implementing it

Very nicely explained, as I kept reading it covered all my experiential "yes, but" thoughts. I will add that-knowing- all this is helpful, but implementing it when you are early in your career is hard. For example, it's good that Business is the big priority, but when you gave no experience of what is good, or bad, in business, it can be hard to understand the ramifications of decisions made now. Equally, business priorities should win, but your goals and the business goals may not be aligned. An individual may need to resume-pad (learn that new framework) while the business may want homogeneity (everything built on one framework.) Finally, of course, this refers to commercial software. Open Source software is the exact opposite flow, dev > maintainer > user > business. Which ultimately explains why it's so hard to get funding for OSS.

082349872349872 3y ago
Then again, the original ideal for OSS is that (just like owning a home is having the tenant and the landlord be the same person) devs and users are the same, so: (dev = ops = user) ≹ (biz).
goodpoint 3y ago
> Open Source software is the exact opposite flow, dev > maintainer > user > business That's a pretty sad assumption. "dev > user" is why a lot of projects have very poor usability.
- bruce511 3y ago
  Obviously it's not true for all projects. But it's true for most of them, no?
- zen928 3y ago
  devs have to use it to hoist it to a platform that can accessed by others before users can use it, right? imo users don't typically use open source software, they use generated artifacts from an upstream development process representing the capabilities of the software. users don't "use grafana", they use the implementation of how you deploy it. it should be improved upon by responses from the users who use your implementation, but what you're saying suggests that efforts like architecting your software in ways that improve/maintain development standards or packaging your software in a dependency manager before delivering any level of user facing feature is a sad assumption to you. I don't think the concern of usability here takes the entire picture of a project into context.

082349872349872 3y ago

Then again, the original ideal for OSS is that (just like owning a home is having the tenant and the landlord be the same person) devs and users are the same, so: (dev = ops = user) ≹ (biz).

goodpoint 3y ago

> Open Source software is the exact opposite flow, dev > maintainer > user > business That's a pretty sad assumption. "dev > user" is why a lot of projects have very poor usability.

bruce511 3y ago
Obviously it's not true for all projects. But it's true for most of them, no?
zen928 3y ago
devs have to use it to hoist it to a platform that can accessed by others before users can use it, right? imo users don't typically use open source software, they use generated artifacts from an upstream development process representing the capabilities of the software. users don't "use grafana", they use the implementation of how you deploy it. it should be improved upon by responses from the users who use your implementation, but what you're saying suggests that efforts like architecting your software in ways that improve/maintain development standards or packaging your software in a dependency manager before delivering any level of user facing feature is a sad assumption to you. I don't think the concern of usability here takes the entire picture of a project into context.