-
Notifications
You must be signed in to change notification settings - Fork 339
Playing the coordination game
There was a moment in Haskell Mode history when Haskell Mode was in danger of having five indentation modes at the same time.
Some people say that more choice is better because, well, more choice is better by definition.
No, it's not.
I have no direct experience with other communities but Haskell language seems to generate extraordinarily fragmented landscape. Is this something about the language or inherent in the people involved I cannot judge. Needless to say excessive fragmentation has negative effects.
Instead of viewing the world in terms of availability of choices, we should view the world in terms of friction required to enact choices. Imagine a world where choices were labeled with how difficult they were to fulfill like coefficients of friction. -- Tristan Harris.
For example imagine all the energy required to select an indentation mode:
- Try to find documentation about each of the choices.
- Try to understand all the bugs and issues each mode has.
- Each mode has options and settings, try to understand those.
- Make an informed decision.
Note that items 1 to 4 are impossible due to lack of documentation and the best you can do is jump on IRC, ask a question, get (or not) an answer and blindly trust it or grab a preexisting haskell-mode configuration from a random github repo.
Fragmentation encourages new projects instead of improvement in the existing ones. For example Network.HTTP could support SSL but it won't. It was easier to start a new HTTP library project with SSL support than to fix the old one. Fragmentation breeds more fragmentation because how to know which of the seven database libraries one should contribute to? Easier to start the eighth database library project. Fragmentation encourages single person projects and that in turn encourages projects without documentation because writing useful manuals and tutorials is a multiperson activity due to amount of work required to make it happen.
Although coordination is a hard problem Haskell community should be predisposed to play the coordination game on a reasonable level. What is static typing if not an information channel that helps to coordinate software components?
Individual actors (that is us!) should be aware of the problem and steer personal energy to reduce the entropy instead of increasing it. I understand it is not always clear what is the enthropy gradient but best effort here is better than random choice. Rule of thumb: contribute to an already existing project instead of starting your own.
More projects should be run as projects as opposed to 'a bunch of source code files'. A project has a certain dynamics in time, has energy that causes it to evolve with compiler upgrades, with dependent packages, with its user base. If you own a source code project then try to run it as a real project. If that is not possible due to life circumstances (or you just do not want to do this) then relinquish control and mark your source code as lacking a project behind it, aka "looking for a maintainer".
Finally, we should encourage maintainers and their work. There is a spontaneous happiness when a new package is released and such reaction certainly was a very important aspect of the culture when hackage hosted a three digit package count. Hackage has five digit number of packages now and there is a different set of problems manifested at this scale.
Community culture and values should shift to long term project support. This is already happening and I'm happy to observe that the coordination failure problem we have seems to be more and more recognized in the community.
Having said all of the above let me underline that aboundance problem is a sweet problem to have as too much choice is always better than no choice.