4 ms·

You cannot reasonably expect people to check into a plethora of information streams, digest it, and be able to come to a meaningful consensus of action. The me

You cannot reasonably expect people to check into a plethora of information streams, digest it, and be able to come to a meaningful consensus of action. The meetings, the management, the prioritization, they all act as information filters of a sort. Otherwise, you experience death by information overload. The most "open" of open source and remote companies still have meetings, product roadmaps, and prioritization. Resources and time are finite.

cuteboy19 5y ago
How does Linux do it? Does anyone know of any documentation for the process they follow?
- striking 5y ago
  Linux doesn't solve nearly the same set of problems that Windows does. One is a kernel. The other is an operating system. Typically this is just semantics, but it's meaningful here because you still need all of the other components (GNOME and X and PulseAudio and SystemD and so on, as concrete motivating examples) to make up the whole OS. And unsurprisingly, you end up losing out on features that would require vertical integration. Accessibility on Linux is more or less a non-starter, the design of every application and toolkit is blindingly variable, nothing about the system can be depended on (even the standard C library!) unless your app has been intentionally built and tested with that particular version of that grab bag of components. Windows is one thing. People know what they're getting when they use it. I don't like it much, but it certainly achieves the goal it set out to accomplish. I certainly don't lie awake in bed wondering why everyone uses it over my favorite grab bag of widgets that more or less looks like an OS.
  - cuteboy19 5y ago
    I think someday we might need to have systemd-accessibilityd at this rate
    - striking 5y ago
      Or we could pick one UI toolkit and stick with it! Kidding, I know that'll never happen. (Unless Electron counts as a UI toolkit, because that's apparently where we're headed.)
      - deleted 5y ago
        [deleted]
- gourlaysama 5y ago
  See the Linux documentation's "How the development process works" [0]. The way a changeset goes from a developer's machine to the root is reasonably similar (it usually gets pulled through a number a intermediate trees, from a development tree to a sub-subsystem tree to a major subsystem tree to Linus's tree), riding the train from the bottom to the top, with an additional time constraint on it (the merge window being open). The kernel also has a "next" tree that is a snapshot of what the kernel would look like with incoming changes merged right now, surfacing early the exact long-distance coordination issues described in the article. Plus, of course, everything is in the open, so maintainers of different subsystem can then coordinate directly on things that impact both sides, even if the required patches will if possible make their way up separately. [0]: https://www.kernel.org/doc/html/latest/process/2.Process.html#development-process https://www.kernel.org/doc/html/latest/process/2.Process.htm...
jka 5y ago
What you say is true, but the open source model does make it easier for people to subscribe to a subset of threads, issues, projects, etc that they find relevant to their goals, and to follow and contribute to those selectively. In other words: core project team(s) may follow traditional organizational practices, but it's also possible for them to accept contributions from pro-bono specialist interests. (that's theoretically possible for companies using inner-source approaches too, although the audience size in those situations is likely to be smaller)

cuteboy19 5y ago

How does Linux do it? Does anyone know of any documentation for the process they follow?

striking 5y ago
Linux doesn't solve nearly the same set of problems that Windows does. One is a kernel. The other is an operating system. Typically this is just semantics, but it's meaningful here because you still need all of the other components (GNOME and X and PulseAudio and SystemD and so on, as concrete motivating examples) to make up the whole OS. And unsurprisingly, you end up losing out on features that would require vertical integration. Accessibility on Linux is more or less a non-starter, the design of every application and toolkit is blindingly variable, nothing about the system can be depended on (even the standard C library!) unless your app has been intentionally built and tested with that particular version of that grab bag of components. Windows is one thing. People know what they're getting when they use it. I don't like it much, but it certainly achieves the goal it set out to accomplish. I certainly don't lie awake in bed wondering why everyone uses it over my favorite grab bag of widgets that more or less looks like an OS.
- cuteboy19 5y ago
  I think someday we might need to have systemd-accessibilityd at this rate
  - striking 5y ago
    Or we could pick one UI toolkit and stick with it! Kidding, I know that'll never happen. (Unless Electron counts as a UI toolkit, because that's apparently where we're headed.)
    - deleted 5y ago
      [deleted]
gourlaysama 5y ago
See the Linux documentation's "How the development process works" [0]. The way a changeset goes from a developer's machine to the root is reasonably similar (it usually gets pulled through a number a intermediate trees, from a development tree to a sub-subsystem tree to a major subsystem tree to Linus's tree), riding the train from the bottom to the top, with an additional time constraint on it (the merge window being open). The kernel also has a "next" tree that is a snapshot of what the kernel would look like with incoming changes merged right now, surfacing early the exact long-distance coordination issues described in the article. Plus, of course, everything is in the open, so maintainers of different subsystem can then coordinate directly on things that impact both sides, even if the required patches will if possible make their way up separately. [0]: https://www.kernel.org/doc/html/latest/process/2.Process.html#development-process https://www.kernel.org/doc/html/latest/process/2.Process.htm...

jka 5y ago

What you say is true, but the open source model does make it easier for people to subscribe to a subset of threads, issues, projects, etc that they find relevant to their goals, and to follow and contribute to those selectively. In other words: core project team(s) may follow traditional organizational practices, but it's also possible for them to accept contributions from pro-bono specialist interests. (that's theoretically possible for companies using inner-source approaches too, although the audience size in those situations is likely to be smaller)