1. 31
  1. 11

    This feels about right, but maybe it’s about temperament?

    I’m a pretty strong introvert. When I’m working a big project, I have enough drive to take most of the associated people-work in stride–but I find that it’s largely bound by direct interactions. I find it hard, motivationally and emotionally, to put a lot of energy into speaking into the void.

    I envy people (including some here) who’ve built good creative networks where they can ask a question and get answers/help or make statements that effectively direct community resources. It isn’t that I’m stuck in a transactional mindset–I enjoy being a helpful node in those networks and paying forward the kindness of people who’ve helped me over the years. But I can’t at all imagine extraverting enough to forge my own.

    This is to say that I have to be kind to myself around the meta-work of trying to cultivate help without a megaphone. I can go into the hole, spend 6 months building something before it bears fruit, and emerge sharp, fulfilled, and invigorated. I can spend two weeks documenting where and how I could use help and be rewarded with a nagging motivation-sapping doubt that anyone ever will. Even when I could put the hands to good use, I’ve been trying to err on the side of waiting until someone asks.

    I have to assume there are many more people on the flip side of this who find working alone to be a grind that they can only keep up for so long without more hands, input, and ~community.

    1. 7

      I’ve recently found meaning in a similar theory: if I’m creating a new programming language or computing environment, then I should make sure that it works for me first. It should do what I need it to do. My roadmap should consist entirely of achievements which matter to me. After it works for me, then I can design the ergonomics for other people. Of course, principles like collaborative development still need to be kept in mind when I’m working alone, but they’re hypothetical: if I were collaborating, then I would like certain features.

      1. 2

        While I don’t disagree, there are some things to consider outside what matters only to you at least in the sense of not painting yourself into certain corners. It’s hard to make a call because you don’t want to over-architect on hypotheticals, but you may not want to get yourself fully locked into a specific platform. Seeing what happened with Akka and other license changes, seeing lock-in to any web/code hosting platform… stuff like this tends to come back to bite you even if this is optimizes for what you need right now.

        1. 4

          The effort of making things work for one person should come before considerations like hosting or licensing. Whether I can host my code on somebody else’s computer, or whether somebody else is licensed to use my code, are issues involving somebody else besides me.

          If a language designer doesn’t take this consideration seriously, then they can end up drowned by feature requests from prospective users. There are some features that I’ll never add to any project just because they tend to be requested often but rarely maintained by the community which requests them.

      2. 5

        I find building something not only alone but for one’s own benefit to be an incredible source of creative freedom. Free from external constraints, one can really explore designs and architectures that fit one’s requirements and expectations. I find myself doing that a lot when healing from bouts of burnout from time to time, and it has always been of tremendous help.

        1. 5

          Interesting read, I definitely agree with the general sentiment.

          TLDR: In Roc, which has approximately 5 to 10 big contributors, most of the issues mentioned in this article don’t arise too often/have ok solutions. Definitely not as flexible as being solo, but surprisingly decent. With correctly set expectations and some minor cost, I think going from solo to a small team is not a big deal. With more growth though, these issues definitely become worse.

          As one of the large contributors to Roc, I have a few comments on the potential issues you mentioned and how they played out for me while contributing to Roc.

          Working alone means you don’t have to share the context of your changes with others… But if there’s a change I wish to make, I can do so without consulting others.

          100% agree. All of my hobby projects that are open source are this way. Sure someone can depend on it if they want, but I can and will change it whenever I am working on it. It is up to others to keep up if they want to use the project. The project is primarily for me. It is open to other just in case it happens to be useful for them.

          That being said, a lot of main Roc contributors essentially own a section of Roc (I mostly deal with the x86/arm dev backend and the surgical linker). As such, they are the go to person on that section of code. Due to how the compiler is structured, a contributor can do a lot without consulting anyone (except for code reviews because we require them). In many parts of the code, there is almost no chance of a PR collision. Still not as good as a solo project on these ergonomics, but surprisingly not bad.

          You’re able to keep to your own schedule, and adjust it as necessary.

          This is hit or miss. I think that Roc has done a good job at setting expectation. All of the main developers know that others are working in their spare time. It may not be possible for them to get to a feature that you want. You might have to just wait for them or figure it out yourself. People also have work they find interesting. If the feature you want is drab work, it might be a bit before someone wants to deal with it. I think overall the expectations are low here and the core contributors are all friendly so it doesn’t really lead to issues in practices, but as Roc gets closer to 0.1 with some real users, this is likely to get a lot more complex.

          Shared goals have to be established through long conversations and RFCs.

          We have live text chat with discussions that works pretty well. We also do a lot of video chats which work around these communication issues quite well for us. On top of that, working on Roc is ultimately accepting that Richard is currently the BDFN (benevolent dictator for now), and you are buying into his vision. You mostly have to convince him. That may sound bad to a number of people, but it does deal with this issue quiet well. Still more restricted, but mostly works fine so far. Again, growth and more users will likely eventually strain this.

          a creator with a strong opinion and direction leads to a purer, more cohesive creation

          Totally agree, which is why it is a BDFN. Does have some overhead compared to a solo project, but not bad.

          I can take this collective knowledge on a specific feature and implement it myself, and that’s likely the best way for a new language.

          I think this depends a lot on the language. Many languages have so many pieces that a single person can not implement them all in a reasonable amount of time. Roc would probably never get finished without the community of contributors. It has a lot of different things to handle (some using novel PhD algorithms). Just so much work for one person to cover.

          1. 4

            a lot of main Roc contributors essentially own a section of Roc

            This was how a lot of Elm community projects were run - under my banner, for some time, fell json-to-elm, elm-webpack-loader, elm-test, and the elm-community org on Github. It definitely makes sense when a project is scaling up - like you say, there’s a lot of different topics that might require someone to do a deep dive that wouldn’t be possible if there was one person doing it alone. But I’ve also seen the benefits with Derw of doing much of that myself - for example, having written the testing framework and the CLI interface to Derw means that I know how to make those pieces fit together nicely, without the need for convincing others.

            On top of that, working on Roc is ultimately accepting that Richard is currently the BDFN (benevolent dictator for now), and you are buying into his vision

            This is how I think languages, and a lot of projects, have to work. There’s a reason why we don’t just build everything based on groupthink, and in my experience groups tend to establish weaker visions than if they had someone who could guide the conversations and debates. In the case of Roc, I know from experience that Richard is excellent at both listening to people and enabling them to do great things.

            1. 4

              Roc has a very simple story: like Elm, but compiles to native executables. It’s easier to organize a group of people if the mission is crystal clear. Again, Linux was: “like Unix on a PC, except GPL”. Those projects had lots of collaborators very early on.

              If you are doing an exploratory research project, creating a new category of software without a lot of hard constraints, then it makes sense to do cathedral style development with a single person or a very few close collaborators, until the design is solid and the requirements are crystal clear. Then it’s time to open up to bazaar style collaboration.

              Smalltalk was an extremely ambitious & original project. It started as a series of exploratory prototypes designed and implemented by Alan Kay from 1967-1971 (from Flex, through some intermediates, to Smalltalk-71). Then it became a cathedral-style project at Xerox PARC with a small, close group of collaborators from 1972-1980, undergoing massive design changes. It was released in 1980, at which point the design became more or less frozen. Now Smalltalk is a bazaar.

              I understand that Rust was a personal hobby project by Graydon Hoare from 2006-2009, then in late 2009 Mozilla got interested and assigned a team of developers to the project, switching to cathedral mode until there was an MVP solid enough to release. Now Rust has a huge community of contributors.

              1. 1

                If you are doing an exploratory research project, creating a new category of software without a lot of hard constraints, then it makes sense to do cathedral style development with a single person or a very few close collaborators, until the design is solid and the requirements are crystal clear. Then it’s time to open up to bazaar style collaboration.

                Thanks for this framing. It more clearly names and tags something my intuition has suspected for a while, but I’ve been leery that it was just finding excuses for how I already enjoy working.

            2. 4

              This feels right to me. Most of the software I write outside work has a very small audience: either just me, or people close to me. In the latter case, to borrow a phrase from Robin Sloan, the software is a home-cooked meal.

              When I occasionally choose to open-source those projects, it’s more for the sake of sharing something I think is wonderful, rather than looking for help or contributions. “This is fun, I shouldn’t keep it to myself.” Bug fixes are welcome, I suppose, but I’m unlikely to accept contributions that I don’t personally find useful.

              1. 3

                The “social” part of coding is quite overrated sometimes.

                It’s great that people like to collaborate and work together. That’s really the best way to scale efforts. But not every project needs to scale. There’s a certain focus that comes from being the lone dev on a project.

                Lack of people-scaling can be a useful forcing function. It’s hard to bloat an app quickly as an only dev; you’re too busy steering the ship and keeping it going.

                1. 3

                  There’s a darker side to it: sometimes you will be forced to build something alone even if you have a community, and say thanks if they merely aren’t helping. ;)

                  With VyOS, I didn’t have the luxury of being able to retreat to a cathedral because, as a fork of Vyatta, it already had a community. But in its early days I was routinely accused of being “uncooperative” when I rejected band-aid solutions to fundamental problems and technically good contributions that would cement those problems further. People were also frequently threatening to make a fork that would be free of me. One or two did and quietly abandoned their forks after a few weeks when they realized that “you just need to do X” was anything but “just”.

                  Now no one argues against those ideas anymore, but if people chose to help with them instead of hating on them from the start, they would be implemented a few years earlier.

                  1. 1

                    This can be compared to woodworking, which is also wonderful time alone

                    1. 3

                      I am a bit of a daydream-prone clutz with probable aphantasia, so I find ~physical creativity challenging (and sometimes dangerous). A lot of my creative work is fairly abstract or conceptual. Writing and programming scratch the itch pretty well.

                      I had a spare slot my last semester of college, so I took an intro to design art class (all physical, not graphic design). I was predictably terrible at the physical process, but I did get a lot of joy and peace out of going into the studio at night and just ~executing. Iirc the instructor’s initial grade of most of my projects was in the C range, but she always asked what i was thinking and trying to accomplish before finalizing it.

                      I had several sheets of Bristol board left over as the semester drew to a close, so I designed a rubber stamp for a literary publication I had just started, measured and marked the sheets, cut them into small cards, and stamped them all. This took a few weeks of spare time. I don’t think I have found a peace on earth quite like it.