Beware offers of “help” with your projects(misc-stuff.terraaeon.com)
misc-stuff.terraaeon.com
Beware offers of “help” with your projects
http://misc-stuff.terraaeon.com/articles/beware-help.html
166 comments
>Er... reading this, I would rather suspect the author of "not being a team player"
If he's in charge of the project's direction and has a specific vision that must be accomplished, that's not his job.
Unfortunately, if random people passing by are able to steer the project into the ditch and cause it to fail its most basic requirements (as he describes) then he's bad at his job (which isn't 'being a team player').
He's bad at his job because what he describes seems like a total inability to sell people on WHY to pursue his end goals. If proliferation of devs leads to the project going more and more off the rails, he's getting people who are drawn in by something or other, and feel no connection to the basic purpose of the software. That's on him. His job is to make them understand why his purpose matters, and it's like he's producing a codebase easily adapted to other purposes, but it somehow doesn't get across his purpose.
Maybe he needs to hire a writer, not devs :)
If he's in charge of the project's direction and has a specific vision that must be accomplished, that's not his job.
Unfortunately, if random people passing by are able to steer the project into the ditch and cause it to fail its most basic requirements (as he describes) then he's bad at his job (which isn't 'being a team player').
He's bad at his job because what he describes seems like a total inability to sell people on WHY to pursue his end goals. If proliferation of devs leads to the project going more and more off the rails, he's getting people who are drawn in by something or other, and feel no connection to the basic purpose of the software. That's on him. His job is to make them understand why his purpose matters, and it's like he's producing a codebase easily adapted to other purposes, but it somehow doesn't get across his purpose.
Maybe he needs to hire a writer, not devs :)
I got the impression he didn't seek help at all, and this was just unsolicited offers to help take it in various directions. He should probably make his goals clear to avoid that.
Maybe he's a great team player and loves his projects with a passion and doesn't want people to touch what he builds for himself, no?
He's talking about his personal projects, and many comments are projecting how he behaves for his personal projects to his career?
Does everyone know who he's personally and I'm the only stranger?
He's talking about his personal projects, and many comments are projecting how he behaves for his personal projects to his career?
Does everyone know who he's personally and I'm the only stranger?
> Maybe he's a great team player (...) and doesn't want people to touch what he builds for himself
Isn't that the exact opposite of being a great team player?
I had a boss who was "a great team player" once. We were both working for a rapidly growing startup and he was very open to suggestions on how to improve the system. So naturally when he started his own project I was very much eager to work with him again.
Turns out that it's easy to be a great team player when you are spending someone else's money and changing someone else's code. When I proposed changes to the system he built himself he took it very personal and all of a sudden he was not so open anymore.
It's easy to be generous with other people's money.
Isn't that the exact opposite of being a great team player?
I had a boss who was "a great team player" once. We were both working for a rapidly growing startup and he was very open to suggestions on how to improve the system. So naturally when he started his own project I was very much eager to work with him again.
Turns out that it's easy to be a great team player when you are spending someone else's money and changing someone else's code. When I proposed changes to the system he built himself he took it very personal and all of a sudden he was not so open anymore.
It's easy to be generous with other people's money.
> Isn't that the exact opposite of being a great team player?
You're projecting as well which is visible by the example you give which has next-to-nothing in common with what's being discussed here.
You don't have to want to share governing of your personal idea project. You can be open to contributions that align with your goals BUT reject those that don't.
Both can be true at the same time and the latter does not make you a bad team player. It makes you a "if you want to help me build my shed in my back yard I'll welcome you but if you turn out to want to build a garage then I'll show you the door" person. Or in other words, it makes a fairly normal Homo Sapiens.
You're projecting as well which is visible by the example you give which has next-to-nothing in common with what's being discussed here.
You don't have to want to share governing of your personal idea project. You can be open to contributions that align with your goals BUT reject those that don't.
Both can be true at the same time and the latter does not make you a bad team player. It makes you a "if you want to help me build my shed in my back yard I'll welcome you but if you turn out to want to build a garage then I'll show you the door" person. Or in other words, it makes a fairly normal Homo Sapiens.
> Isn't that the exact opposite of being a great team player?
No.
The anecdote you shared shows a different part of being human: Knowing thyself. He let you in before he was mentally and emotionally ready to let go of his code, and as someone else noted in this thread, it has nothing to do what we talk about here.
Again, it's not about "people's money". It's about being ready to share and let go of control.
No.
The anecdote you shared shows a different part of being human: Knowing thyself. He let you in before he was mentally and emotionally ready to let go of his code, and as someone else noted in this thread, it has nothing to do what we talk about here.
Again, it's not about "people's money". It's about being ready to share and let go of control.
> then he's bad at his job (which isn't 'being a team player').
the job being, being a Linus :-)
the job being, being a Linus :-)
> Er... reading this, I would rather suspect the author of "not being a team player".
I'd respectfully disagree on this. There are projects where you fixate on the outcome (i.e. success of the project and maintainability regardless of team turnover), and projects you fixate on technical aspects for yourself (i.e. I'll fit this thing into a Raspberry Pi 3).
I'd personally set first kind of projects free and accept help, and be a "trim tab" for them, however I'd never allow second type of projects to diverge from the vision I have set for them. Because the second type of projects are "what-if" projects, and engineering studies primarily.
Painting personality pictures from a single post looks like an overreaction, too.
I'd respectfully disagree on this. There are projects where you fixate on the outcome (i.e. success of the project and maintainability regardless of team turnover), and projects you fixate on technical aspects for yourself (i.e. I'll fit this thing into a Raspberry Pi 3).
I'd personally set first kind of projects free and accept help, and be a "trim tab" for them, however I'd never allow second type of projects to diverge from the vision I have set for them. Because the second type of projects are "what-if" projects, and engineering studies primarily.
Painting personality pictures from a single post looks like an overreaction, too.
In the article's example the original "small" Xnet and the other person's vision for "big" Xnet are two projects of the second type, but their vastly different objectives might be at least partly trascended and reconciled by adding a project of the first type: common standards and interfaces that allow both Xnet incarnations to serve the same content and substitute each other, thus providing practical value to actual users rather than experience to the authors.
> thus providing practical value to actual users rather than experience to the authors.
Do we need to convert everything we develop to something which provides practical value to actual users?
Some of us code for fun, and put what we do out there. If it's used, we're happy. If not, it doesn't matter since we're the primary users of our code anyway.
Novell (IIRC) provided MyRealBox e-mails as a free service for beta testing their mail servers. The web interface was crude, but it worked flawlessly over the years they provided the service. The practical value was secondary, and we provided lots of data for the developers of the stack.
We were happy even though we knew what it was. One day we received a mail about EOL'ing the thing, we migrated away, and it's gone. No hard feelings whatsoever.
I think we should stop putting frames and projecting our ideals on anything which looks similar to something we have on our minds.
Do we need to convert everything we develop to something which provides practical value to actual users?
Some of us code for fun, and put what we do out there. If it's used, we're happy. If not, it doesn't matter since we're the primary users of our code anyway.
Novell (IIRC) provided MyRealBox e-mails as a free service for beta testing their mail servers. The web interface was crude, but it worked flawlessly over the years they provided the service. The practical value was secondary, and we provided lots of data for the developers of the stack.
We were happy even though we knew what it was. One day we received a mail about EOL'ing the thing, we migrated away, and it's gone. No hard feelings whatsoever.
I think we should stop putting frames and projecting our ideals on anything which looks similar to something we have on our minds.
I was just suggesting a way for the article's author and the drive-by quasicontributor to get along, not that it would be a worthwhile product.
Practical value (running a system that does X) vs. learning value (learning to do X) is the main distinction between the two types of projects defined in the parent post.
Yes, I understand where you are coming from, but I don't see the need for creating a third umbrella project to make two projects get along or communicate. Maybe if both parties accept, they can directly implement the interoperability, but my opinion stands.
Anyway, I assume you know that GP is also my comment, but the difference is not Practical Value vs. Learning Value. It's the target of the project, plainly. i.e. Do you want a small tool which you gonna care, or a tool which you'll give away incl. its control.
Learning Value and Practical Value can be combined. I have a couple of tools which I built for myself, with hard constraints on resource consumption, because they run on low end SBCs. However, all of these tools provide a real value for me, because I deploy these tools/services and they handle real world load for me.
I also open source them [0][1], but I'll not accept big patches changing the code fundamentally.
[0]: https://git.sr.ht/~bayindirh/railgun
[1]: https://git.sr.ht/~bayindirh/nudge
Anyway, I assume you know that GP is also my comment, but the difference is not Practical Value vs. Learning Value. It's the target of the project, plainly. i.e. Do you want a small tool which you gonna care, or a tool which you'll give away incl. its control.
Learning Value and Practical Value can be combined. I have a couple of tools which I built for myself, with hard constraints on resource consumption, because they run on low end SBCs. However, all of these tools provide a real value for me, because I deploy these tools/services and they handle real world load for me.
I also open source them [0][1], but I'll not accept big patches changing the code fundamentally.
[0]: https://git.sr.ht/~bayindirh/railgun
[1]: https://git.sr.ht/~bayindirh/nudge
There is a minor irony that the author has another blogpost on how micromanaging bosses are awful, because they insist that you should work their way rather than your own way.
Perhaps the learning here is just "managing engineers to deliver something cohesive isn't straightforward". It's obviously true that an open source project can have good coding standards with multiple contributors of different skill levels, but you get there by managing the project really well.
And while more engineers can mean that an individual engineer is slower, the idea is that with good management and engineering the aggregate output can increase with each engineer (i.e. Having 10 engineers who only work at 25% of the pace of a standalone engineer will still output 2.5x as much as a single engineer. At scale it is the teams output that matters, not the output of an individual engineer).
Perhaps the learning here is just "managing engineers to deliver something cohesive isn't straightforward". It's obviously true that an open source project can have good coding standards with multiple contributors of different skill levels, but you get there by managing the project really well.
And while more engineers can mean that an individual engineer is slower, the idea is that with good management and engineering the aggregate output can increase with each engineer (i.e. Having 10 engineers who only work at 25% of the pace of a standalone engineer will still output 2.5x as much as a single engineer. At scale it is the teams output that matters, not the output of an individual engineer).
Well, yes; his way is the best. Not the boss's way, and not the way of some meddling coworkers that want to form a team around the project. It's perfectly consistent. The centre of the org chart is the (ME) bubble, surrounded by meddlers and interlopers.
It sounds like he's spelled out a pretty distinct goal.
"I want to create a platform that can be run from a tiny, low-power server running on a home Internet connection. My primary goal for Xnet is to prove that--contrary to everything everyone else says--one does not need a huge, expensive server on a super-fast Internet connection to host a social network with tens of thousands of users. The reason I want to demonstrate this with a real-world example running live on the Internet is to help average people understand that free speech on the Internet does not have to disappear. Anyone of even less-than-average means can help take it back from billionaires like Mark Zuckerberg and Elon Musk. This is not a hard vision to understand. I think spreading this message is much more important than anything I could contribute to society with one social network run by me. While I am sure that scaling up Xnet would have been a fun project for the latest person to offer his help, this is not what the project is about."
I can't fault this at all. Doesn't mean it has to be my goal (though what I do has many common factors), but from where I'm standing he's doing all the right things, in the right way, and making the right choices around them.
Now, the catch is: part of his goal is making 'average people' take back control of social networks from giant networks that benefit from, well, network effects :) and spreading this message is fundamental to his goal.
So from where I'm standing, his goal is literally unachievable. Average people will not understand or do this. Small groups of super-fans will do this, and they will fail to spread his message, they'll just carry it as well as they can. If anyone does spread it it will be by degrading it in exactly the way he fears, expanding it until it's serving far larger and less motivated populations and requiring specialized hosting, not just democratized average hosting.
If he won't get 'average people' to replace Twitter and Facebook with self-hosting his platform, does that mean his platform shouldn't exist? I think it probably should exist, and that requires it to be his way.
"I want to create a platform that can be run from a tiny, low-power server running on a home Internet connection. My primary goal for Xnet is to prove that--contrary to everything everyone else says--one does not need a huge, expensive server on a super-fast Internet connection to host a social network with tens of thousands of users. The reason I want to demonstrate this with a real-world example running live on the Internet is to help average people understand that free speech on the Internet does not have to disappear. Anyone of even less-than-average means can help take it back from billionaires like Mark Zuckerberg and Elon Musk. This is not a hard vision to understand. I think spreading this message is much more important than anything I could contribute to society with one social network run by me. While I am sure that scaling up Xnet would have been a fun project for the latest person to offer his help, this is not what the project is about."
I can't fault this at all. Doesn't mean it has to be my goal (though what I do has many common factors), but from where I'm standing he's doing all the right things, in the right way, and making the right choices around them.
Now, the catch is: part of his goal is making 'average people' take back control of social networks from giant networks that benefit from, well, network effects :) and spreading this message is fundamental to his goal.
So from where I'm standing, his goal is literally unachievable. Average people will not understand or do this. Small groups of super-fans will do this, and they will fail to spread his message, they'll just carry it as well as they can. If anyone does spread it it will be by degrading it in exactly the way he fears, expanding it until it's serving far larger and less motivated populations and requiring specialized hosting, not just democratized average hosting.
If he won't get 'average people' to replace Twitter and Facebook with self-hosting his platform, does that mean his platform shouldn't exist? I think it probably should exist, and that requires it to be his way.
Even if you're right and the average person never replaces facebook with a social media platform they run out of their living room, I don't think it would mean that he failed in his goal as long as he's able to demonstrate that it's possible to do it with modest resources. It sounds like he just wants to give people a real world example they can point to which shows that not having a ton of money isn't a huge barrier running a social media site.
> part of his goal is making 'average people' take back control of social networks from giant networks that benefit from, well, network effects :)
He didn't say that he was addressing "average people". He said that he was addressing people of "average means" (i.e., not wealthy). I assumed he meant nerds like you and I, not the average Joe on the street.
He didn't say that he was addressing "average people". He said that he was addressing people of "average means" (i.e., not wealthy). I assumed he meant nerds like you and I, not the average Joe on the street.
Average people can understand well enough that if they use someone's toy social site consisting of a single node with a tiny number of users, they will not have their egos stroked there with large numbers of "friends" or "followers" circle jerking their postings.
> There is a minor irony that the author has another blogpost on how micromanaging bosses are awful...
It's not as contradictory as it sounds, to complain both about micromanaging bosses and about underlings kidnapping projects. But one needs to switch the framing from universal truths about team organization to psychology.
I can relate to the situation quite closely because I think it's the same overall situation that I find myself in. I might be totally off the mark here because, like anyone, I can't read minds, but let me engage in some speculation.
The ability to have truly peer-to-peer relationships that are not based on any one side dominating the other is very rare. One needs to have a highly developed psyche to be capable of such relationships, so only a small minority of people have this ability. The vast majority of all human relationships work on a "dominate or be dominated" principle.
If you consistently find yourself on the losing end of power struggle, you start to see everyone as a threat to your autonomy. The result is that you work alone. Obviously, that's extremely limiting, and, for myself, I find it extremely painful to try to develop through that.
It's not as contradictory as it sounds, to complain both about micromanaging bosses and about underlings kidnapping projects. But one needs to switch the framing from universal truths about team organization to psychology.
I can relate to the situation quite closely because I think it's the same overall situation that I find myself in. I might be totally off the mark here because, like anyone, I can't read minds, but let me engage in some speculation.
The ability to have truly peer-to-peer relationships that are not based on any one side dominating the other is very rare. One needs to have a highly developed psyche to be capable of such relationships, so only a small minority of people have this ability. The vast majority of all human relationships work on a "dominate or be dominated" principle.
If you consistently find yourself on the losing end of power struggle, you start to see everyone as a threat to your autonomy. The result is that you work alone. Obviously, that's extremely limiting, and, for myself, I find it extremely painful to try to develop through that.
> Of course, if other developers find your project interesting and want to contribute, they may have their own features and use cases in mind that don't necessarily overlap with what you have planned, which doesn't however mean that it has to be a "wrong direction".
Yes it actually means exactly that -- it is the wrong direction. Since you have one person who wants to build something concrete and he doesn't owe it to anyone to support them if they want to change his thing to something else.
As I wrote in a deeper comment: if you want to build a shed in your back yard and your neighbor asks if he an help, you'll welcome them right? But then imagine the neighbor, for reasons unknown to you, wants to actually build a greenhouse and starts not doing what is asked of them and actively replaces building blocks and does stuff you don't want them to do. In your own back yard.
You will say this is not OK and want them to leave, I am certain of it.
Then somebody like you (the parent poster, a 3rd person in the picture) appear out of nowhere and claim that you are not a team player.
So I don't see how your comment follows logically at all and it's even more puzzling that it's the top comment. Makes me wonder if the people who blindly recite some theoretical democracy manifesto would be so generous if "the team players" you are defending started wanting to demand the right to change your back yard. :)
Yes it actually means exactly that -- it is the wrong direction. Since you have one person who wants to build something concrete and he doesn't owe it to anyone to support them if they want to change his thing to something else.
As I wrote in a deeper comment: if you want to build a shed in your back yard and your neighbor asks if he an help, you'll welcome them right? But then imagine the neighbor, for reasons unknown to you, wants to actually build a greenhouse and starts not doing what is asked of them and actively replaces building blocks and does stuff you don't want them to do. In your own back yard.
You will say this is not OK and want them to leave, I am certain of it.
Then somebody like you (the parent poster, a 3rd person in the picture) appear out of nowhere and claim that you are not a team player.
So I don't see how your comment follows logically at all and it's even more puzzling that it's the top comment. Makes me wonder if the people who blindly recite some theoretical democracy manifesto would be so generous if "the team players" you are defending started wanting to demand the right to change your back yard. :)
I agree that this passage says more about the author than about any fundamental law of organization.
It is true however that there is more organizational overhead if you have two people working on a thing than if you have one doing it solo.
But that is a problem that can be solved, e.g. by dividing responsibilities very clearly or by having clearly defined procedures that guarantee a decent handover. I have also experienced people that do better, more accurate and resonable work when they work together with someone else, because they will anticipate the other seeing their code.
The quoted passage tells me one thing: If you invite people to work on your project, no matter if it is a film, a garden party or a software product, the right casting is crucial. Don't invite people that won't understand the thing you're doing, and if you absolutely have to make sure there is something in it for them when they do their own job well and see your thing succeeding — but the crucial thing is, you should always know what is in it for the other person.
As someone who has been on a number of amateur film sets where nobody got paid the ones that really sucked where the ones where the initiator treated everybody like dumb paid labour that should just do as they were told, pushing people that might have cared into actively sabotaging the project.
If you want people to care about your project it is your task to find people who do and it is your task to keep them there, if they are needed for the project.
And very often that means not doing it 100% dictator-style, but letting people play and evolve within their own domain. From what I have seen the results of allowing this outshine micromanaging dictators nearly all of the times.
It is true however that there is more organizational overhead if you have two people working on a thing than if you have one doing it solo.
But that is a problem that can be solved, e.g. by dividing responsibilities very clearly or by having clearly defined procedures that guarantee a decent handover. I have also experienced people that do better, more accurate and resonable work when they work together with someone else, because they will anticipate the other seeing their code.
The quoted passage tells me one thing: If you invite people to work on your project, no matter if it is a film, a garden party or a software product, the right casting is crucial. Don't invite people that won't understand the thing you're doing, and if you absolutely have to make sure there is something in it for them when they do their own job well and see your thing succeeding — but the crucial thing is, you should always know what is in it for the other person.
As someone who has been on a number of amateur film sets where nobody got paid the ones that really sucked where the ones where the initiator treated everybody like dumb paid labour that should just do as they were told, pushing people that might have cared into actively sabotaging the project.
If you want people to care about your project it is your task to find people who do and it is your task to keep them there, if they are needed for the project.
And very often that means not doing it 100% dictator-style, but letting people play and evolve within their own domain. From what I have seen the results of allowing this outshine micromanaging dictators nearly all of the times.
This hugely assumes that the point of an open source project is to have other people do it, and 'caring about it' means doing the work of it.
Not always true.
My own open source world operates on different principles: I'm there to explore in a particular direction, not always fruitfully. Near as I can tell there isn't anybody else walking that particular beat, which among other things implies that it's a really niche interest, and that suits me just fine.
But it means I can't get other devs in to pursue this direction, because they simply won't. So my use of open source turns into a one-way faucet: rarely is there a situation where I'm able to take anything back, it's always about facilitating other people to build THEIR projects making use of whatever they find useful in my codebase. I almost never get any help with my project, and this is fine.
Maybe it works better for everyone that I don't try to get people to do my will, don't treat them as dumb paid labor. People are often very clever but caught up in doing things I don't find at all useful, not unlike the author's objections as a 'helper' tries to convert his social-media-democratization project into a much more elaborate creation that fails all the author's requirements. This is where the other person would fork and be done with it: seems rude to try and shake the original dev from his fundamental motivations with the project.
Question. If the original person is so niche that they'll create something original but unhelpful to most people, and the interloper is far more in tune with popular demand and will create something that is meh but popular, is forking the project and making two projects, the niche one and the meh popular one, bad?
If this is done and it upsets the original dev, who sees his vision desecrated by a garbage knock-off, and he quits and goes and jumps off a cliff, is THAT bad?
The latter is an extreme, but I'm reminded of so many stories from history and media along these lines. The most popular comic strip in history is named 'Peanuts', and was always the work of one man, Charles Schulz. Everything about it was him on the page… except the name, which was forced on him by the syndicate, over his preferred Lil' Folks. Schulz never came to terms with the name Peanuts. He saw it as 'little worthless things, things of little value'. This of course echoed the neuroticism of his very intelligent and fretful characters, forever worrying about their own value, and so lampshading that in the title of the strip has probably helped its popularity, as it's a guide to the kind of humor within.
Let's postulate that Schulz was able to use Lil' Folks, or even 'these are awesome self-actualized people worthy of love and respect, just like me the cartoonist', and let's imagine that he could do this and totally nerf the adoption of the strip, allowing the cartoonist's needs to intrude on the art. Should he have? What's more important, his ownership of the project, or what it could become?
Not always true.
My own open source world operates on different principles: I'm there to explore in a particular direction, not always fruitfully. Near as I can tell there isn't anybody else walking that particular beat, which among other things implies that it's a really niche interest, and that suits me just fine.
But it means I can't get other devs in to pursue this direction, because they simply won't. So my use of open source turns into a one-way faucet: rarely is there a situation where I'm able to take anything back, it's always about facilitating other people to build THEIR projects making use of whatever they find useful in my codebase. I almost never get any help with my project, and this is fine.
Maybe it works better for everyone that I don't try to get people to do my will, don't treat them as dumb paid labor. People are often very clever but caught up in doing things I don't find at all useful, not unlike the author's objections as a 'helper' tries to convert his social-media-democratization project into a much more elaborate creation that fails all the author's requirements. This is where the other person would fork and be done with it: seems rude to try and shake the original dev from his fundamental motivations with the project.
Question. If the original person is so niche that they'll create something original but unhelpful to most people, and the interloper is far more in tune with popular demand and will create something that is meh but popular, is forking the project and making two projects, the niche one and the meh popular one, bad?
If this is done and it upsets the original dev, who sees his vision desecrated by a garbage knock-off, and he quits and goes and jumps off a cliff, is THAT bad?
The latter is an extreme, but I'm reminded of so many stories from history and media along these lines. The most popular comic strip in history is named 'Peanuts', and was always the work of one man, Charles Schulz. Everything about it was him on the page… except the name, which was forced on him by the syndicate, over his preferred Lil' Folks. Schulz never came to terms with the name Peanuts. He saw it as 'little worthless things, things of little value'. This of course echoed the neuroticism of his very intelligent and fretful characters, forever worrying about their own value, and so lampshading that in the title of the strip has probably helped its popularity, as it's a guide to the kind of humor within.
Let's postulate that Schulz was able to use Lil' Folks, or even 'these are awesome self-actualized people worthy of love and respect, just like me the cartoonist', and let's imagine that he could do this and totally nerf the adoption of the strip, allowing the cartoonist's needs to intrude on the art. Should he have? What's more important, his ownership of the project, or what it could become?
> This hugely assumes that the point of an open source project is to have other people do it, and 'caring about it' means doing the work of it.
>Not always true.
Thank you for saying this. The shift of this mindset in the open source community is part of why I stepped back a bit from the open source community. I still produce open source projects, but I no longer use the term "open source" because I don't accept changes from the larger community. I do my projects, release the source, and people can fork if they want to work on it.
I do this because once you start accepting work from others, you start having to be a manager. I don't want to be a manager.
>Not always true.
Thank you for saying this. The shift of this mindset in the open source community is part of why I stepped back a bit from the open source community. I still produce open source projects, but I no longer use the term "open source" because I don't accept changes from the larger community. I do my projects, release the source, and people can fork if they want to work on it.
I do this because once you start accepting work from others, you start having to be a manager. I don't want to be a manager.
It seems to me that the author is talking about _personal_ projects, and people coming in to hijack them...not about working as part of a 'team' in a company.
Many of the replies here seem to conflate the two, which I think is either a poor reading or just ignoring the message I took from the article.
Many of the replies here seem to conflate the two, which I think is either a poor reading or just ignoring the message I took from the article.
Experimental projects tend to be personal, even in a corporate setting, because team projects are usually too large to be a mere experiment (for example, they can become serious product prototypes rather than pure testbeds).
If that's the case, your direction doesn't matter. You've got a task to complete. Your boss sets the direction and requirements. You might disagree with a 'new person's' implementation, but that's a discussion point. 'Direction' and 'implementation' are distinct. For a commercial project that you're tasked with, the direction is part of the task.
If you're setting the direction, you've likely the authority to set the direction, in which point it's not 'team' and more 'manage' or senior dev.
If you're setting the direction, you've likely the authority to set the direction, in which point it's not 'team' and more 'manage' or senior dev.
[deleted]
"As an engineer, I have worked with many, many other engineers on dozens of projects."
Maybe I don't know how to read, but that suggests a corporate setting to me.
Maybe I don't know how to read, but that suggests a corporate setting to me.
The initial paragraph talks about {author} creating a project and not putting it on github. That seems directly to me to be personal, and related more strongly to the idea that you have a direction for the project.
The followup seems like a bit of context to combat the idea that additional manpower does not just give free productivity.
If its corporate, your 'direction' doesnt matter. Your boss, and their boss, tell you what the direction is and the discussion is around implementation. Therefore, arguing direction change from project newcomers doesnt make sense.
The followup seems like a bit of context to combat the idea that additional manpower does not just give free productivity.
If its corporate, your 'direction' doesnt matter. Your boss, and their boss, tell you what the direction is and the discussion is around implementation. Therefore, arguing direction change from project newcomers doesnt make sense.
While the author mentions having this corporate experience, the article's point is organized around the author's social network project code-named "XNet", which seems personal. He wrote it in 2000 lines initially and put it on the Internet; if that was on the job somewhere using company machines and network, he'd be fired.
> I would rather suspect the author of "not being a team player"
Let's look at it: he's basically saying that teams are often bad, and the bigger they are, the worse. And, so, there are times he doesn't want to be in one.
He concludes the article with: "Sometimes the old saying is true. Sometimes, if you want something done right, you really do need to do it yourself."
That's not the parting shot you would use if you still wanted people to think you're a team player in spite of all the mostly negative things you wrote about teams.
Let's look at it: he's basically saying that teams are often bad, and the bigger they are, the worse. And, so, there are times he doesn't want to be in one.
He concludes the article with: "Sometimes the old saying is true. Sometimes, if you want something done right, you really do need to do it yourself."
That's not the parting shot you would use if you still wanted people to think you're a team player in spite of all the mostly negative things you wrote about teams.
> I would rather suspect the author of "not being a team player"
A team is a group of people all working toward the same goal. The author is talking about being wary of people who don't share the common goal. That, arguably, is being a team player, supporting the team by making sure that everyone rows in the same direction.
A team is a group of people all working toward the same goal. The author is talking about being wary of people who don't share the common goal. That, arguably, is being a team player, supporting the team by making sure that everyone rows in the same direction.
I cant say if he's a team player or not, but from what I read, it does seem that communication is key. If he was able to communicate his goals, requirements and objectives clearly to the "helper", he would have never gotten into this mess in the first place.
Leadership, communication and group by in are so important in any project. People who have mastered those soft skills tend to deliver quality good.
Leadership, communication and group by in are so important in any project. People who have mastered those soft skills tend to deliver quality good.
This reminds me of Gogs [0], where the original author refused a lot of good ideas and improvements, eventually leading to a fork [1] that's now a lot more popular and active than the original.
[0] https://gogs.io/
[1] https://gitea.io/en-us/
[0] https://gogs.io/
[1] https://gitea.io/en-us/
Well he has a vision for his project, and so by his own definitions he is essentially as narcissistic as the newcomer is by accepting all new contributors without setting expectations.
Not setting expectations from the outset, especially in an 'open' setting, leads to more problems down the line. This would deter newcomers of course, but you'll probably not want those types anyway.
Not setting expectations from the outset, especially in an 'open' setting, leads to more problems down the line. This would deter newcomers of course, but you'll probably not want those types anyway.
> ...he is essentially as narcissistic as the newcomer is by accepting all new contributors without setting expectations.
But the whole point of the article is to explain why he does not do that!
Setting expectations is no panacea. A non-trivial fraction of volunteers will nominally accept the expectations but do what they want anyway. Another non-trivial fraction will also accept the expectations but then go along with anything those of the first group suggest.
These are universal facts of organizations of any type, not just technical development teams.
But the whole point of the article is to explain why he does not do that!
Setting expectations is no panacea. A non-trivial fraction of volunteers will nominally accept the expectations but do what they want anyway. Another non-trivial fraction will also accept the expectations but then go along with anything those of the first group suggest.
These are universal facts of organizations of any type, not just technical development teams.
100% agree. Communication and setting expectations are key in making any project with 2 or more people successful.
I think the point is that this is a project with 1 person.
In my experience, the behaviors listed in the passage you quote are not uncommon (though, also in my experience, not common enough to justify characterizing "most of the newcomers" as such.) They are objectively harmful to the goals of the project, and if being a team player requires accommodating them unconditionally, you can count me out, too.
> Er... reading this, I would rather suspect the author of "not being a team player".
Of what team?
Of what team?
Any team they happen to be in.
Teamwork is collaborative and new people always bring new ideas.
One of the challenges of looking after a team of engineers is setting up a team culture that allows ego-free analysis of that, rather than rigidly sticking to one approach no matter what.
Ego-heavy engineers are quick to treat anything but their personal opinion as the wrong approach.
Teamwork is collaborative and new people always bring new ideas.
One of the challenges of looking after a team of engineers is setting up a team culture that allows ego-free analysis of that, rather than rigidly sticking to one approach no matter what.
Ego-heavy engineers are quick to treat anything but their personal opinion as the wrong approach.
You desperately need to let go of that oompa-loompa mentality when it's your own project. You need vision and ego if you're going to successfully lead a software project. You can't treat everyone who happens to pass by as a team-member whose opinions are as valuable as your own.
Listen and let yourself be convinced, sure, but it's crucially important to be able to say "no, this feature is not in line with the vision for the project". Say yes sometimes too, by all means, but when you're in the position of the primary author and leader of the project, it's your call to make.
If you say yes to every idea anyone brings by, you'll end up with The Homer[1].
[1] https://simpsonswiki.com/wiki/File:The_Homer.png
Listen and let yourself be convinced, sure, but it's crucially important to be able to say "no, this feature is not in line with the vision for the project". Say yes sometimes too, by all means, but when you're in the position of the primary author and leader of the project, it's your call to make.
If you say yes to every idea anyone brings by, you'll end up with The Homer[1].
[1] https://simpsonswiki.com/wiki/File:The_Homer.png
> If you say yes to every idea anyone brings by, you'll end up with The Homer[1].
Judging by the description of it/the episode (https://simpsonswiki.com/wiki/The_Homer), it seems to convey the opposite message? It was one person's (Homer's) vision, no input from others?
Judging by the description of it/the episode (https://simpsonswiki.com/wiki/The_Homer), it seems to convey the opposite message? It was one person's (Homer's) vision, no input from others?
I'm not making a comparison with the process, but the outcome.
Although I guess Homer Simpson could be argued to have had many ideas about what should be included in the car, although he didn't really have a vision for the car. So in that sense, it's still a reasonable parallel for the development methodology.
Although I guess Homer Simpson could be argued to have had many ideas about what should be included in the car, although he didn't really have a vision for the car. So in that sense, it's still a reasonable parallel for the development methodology.
Homer is a satire of the American everyman and his supposed incoherent desire for everything at once. In that sense, a car designed by Homer is a car designed by a committee of yes-men.
I assume OP is referring to all the teams the author said he worked on in the article, as referenced in the second paragraph:
> As an engineer, I have worked with many, many other engineers on dozens of projects.
> As an engineer, I have worked with many, many other engineers on dozens of projects.
The many engineers he has worked with in dozens of projects.
A perfect use case for git branches (one for each developer) and cherry picking features into the main branch. Git makes it almost impossible to make a negative contribution, except maybe for security stuff.
I recently forked a project to make some significant changes to make it more useful for my needs. The direction I took the fork is different from needs of the original author. My version is definitely much more useful for other people but wouldn't be any help to the goals of original project.
But I'm very thankful that the original author just posted his code to Github to make this possible.
But I'm very thankful that the original author just posted his code to Github to make this possible.
Yeah, I'm confused as to why the author wouldn't make their source code available with a message that says "I am not looking to accept pull requests or help with this project, but I'm providing the code in case it's useful to anyone in their own pursuits."
That seems like it would make everyone happy, wouldn't it?
That seems like it would make everyone happy, wouldn't it?
You can be open to contributions and help while still wanting to maintain a certain direction for a project (rather than it becoming a democracy, or a "must solve all use cases"-type of project). Actually, I think that's how most projects are run.
Yes, but that puts the onus on the maintainer to actively reject contributions that they don't like. It doesn't help that often people will implement something without even asking if its right for the direction of the project and then come with the expectation that upstream will accept it. You could say that thats on them for having the wrong expectation but that doesn't change that it isn't fun to tell people "no".
Still, forgoing all contributions for that or even keeping the source closed is throwing out the baby with the bathwater. Even if you don't want any features being contributed at all there is value in accepting patches for bugfixes.
Still, forgoing all contributions for that or even keeping the source closed is throwing out the baby with the bathwater. Even if you don't want any features being contributed at all there is value in accepting patches for bugfixes.
> it isn't fun to tell people "no".
It gets even less fun when they won't take no for an answer and want to argue with you about it: it sucks up time and energy you may not want, or even have, to give. It becomes unnecessary noise and distraction, which is a huge problem if your life is already busy.
It gets even less fun when they won't take no for an answer and want to argue with you about it: it sucks up time and energy you may not want, or even have, to give. It becomes unnecessary noise and distraction, which is a huge problem if your life is already busy.
Because this project is about the author and not the selfish people who don’t want to make it about the author
Are you being sarcastic? If I'm making a painting and someone wants to start scribbling on it, am I selfish for not allowing them?
I am being sarcastic. I think it’s more nuanced than the author thinks and he’s projecting.
Other people have egos but he probably does too for wanting the project to be an extension of himself.
It’s okay to want that, but other people aren’t bad and selfish for not conforming to your will. Sometimes you just don’t see things eye to eye and need to move on.
Other people have egos but he probably does too for wanting the project to be an extension of himself.
It’s okay to want that, but other people aren’t bad and selfish for not conforming to your will. Sometimes you just don’t see things eye to eye and need to move on.
Not if the most obvious forks would starve out adoption of the original, more niche project. That would make the original dev unhappy.
His stated purpose is for his project to proliferate and teach people to host their own social networks. It's very unlikely that this would compete effectively against larger social networks based on his stuff, that ask less of the user and offer significantly larger networks.
His stated purpose is for his project to proliferate and teach people to host their own social networks. It's very unlikely that this would compete effectively against larger social networks based on his stuff, that ask less of the user and offer significantly larger networks.
GitHub surely has a way to simply disable both Issues and PRs right?
Clone it. Fork it. Star it. That’s it.
Clone it. Fork it. Star it. That’s it.
Haha, you'd think. You can disable issues, but not pull requests, which has been a pain point for the last... forever[0]. Best you can do is setup workflows to automatically close and lock every pull request (and optionally, add an exception for a single pull request that says in all caps "DO NOT OPEN PULL REQUESTS"). It's as painful as it sounds.
[0]: https://github.com/github/dmca/pulls
[0]: https://github.com/github/dmca/pulls
You can disable issues but not PRs. People faux-disable it by opening a PR with "don't open PRs" or set up a bot to comment on PRs.
You can open source something without putting it on GitHub.
You just succintly described what will kill off github eventually
What are you confused about? Just because people want to help out doesn't mean they have an obligation to make the project open source.
Slightly off topic;
> But I'm very thankful that the original author just posted his code to Github to make this possible.
That does not make forking possible. There are many projects on GitHub that are not open source. One should be thankful for the author for licensing their software using an open source license.
> But I'm very thankful that the original author just posted his code to Github to make this possible.
That does not make forking possible. There are many projects on GitHub that are not open source. One should be thankful for the author for licensing their software using an open source license.
I think you can still fork it if it's not free software, but it needs to be a private fork. I think that, unless they say they are distributing their software on certain conditions, just copyright alone wouldn't prevent you from modifying the code for personal usage.
> just copyright alone wouldn't prevent you from modifying the code for personal usage.
This is correct. Copyright prevents you from distributing the protected work. It doesn't prevent you from taking it and doing whatever else you want with it.
(I'm ignoring the DMCA anti-circumvention clause here because that's a whole different issue and rarely actually comes into play)
This is correct. Copyright prevents you from distributing the protected work. It doesn't prevent you from taking it and doing whatever else you want with it.
(I'm ignoring the DMCA anti-circumvention clause here because that's a whole different issue and rarely actually comes into play)
You can fork it regardless per the GitHub Terms of Service, if I understand correctly: https://opensource.stackexchange.com/questions/1154/how-does....
Note that this doesn’t extend any of the other rights associated with open source.
Note that this doesn’t extend any of the other rights associated with open source.
How much of the code is based on the forked project?
Am I missing something? There is no lesson learned here. No offer of help was accepted and nothing went wrong. Why beware? He hasn't even tried it. Hell I can't even really parse if there ever was an offer to help, just some suggestions.
That's basically what the article is saying, though, isn't it? The author wasn't deceived by an offer and didn't suffer a setback, they're just commenting on the fact that offers of help always carry some kind of cost. In this case the cost was compromising on their goals for the project. It goes in the same basket as any other unsolicited opinion on the internet, including this one.
The author wasn't deceived, in fact no one even tried to deceive him. Rather, a guy offering to help clearly communicated his intentions, so that the author was able to make an informed decision to decline that help.
From the very limited information presented, it's not clear to me why the author would judge this offer to be a selfish act, or why this anecdote would support his conclusion to "beware offers of help".
From the very limited information presented, it's not clear to me why the author would judge this offer to be a selfish act, or why this anecdote would support his conclusion to "beware offers of help".
I’m inclined to let his accusation of “narcissism”
rise to the surface here. Clearly projecting.
If the person who offered helped had technical chops to scale such project. Why they would approach existing project owner instead of building it themselves?
My explanation is they did not have what is needed like tech skills or they were after taking over existing users.
Idea of scaling something up as author noted usually comes with idea that money will eventually follow. Post author is not money driven so it might be that person offering was also different in that way.
My explanation is they did not have what is needed like tech skills or they were after taking over existing users.
Idea of scaling something up as author noted usually comes with idea that money will eventually follow. Post author is not money driven so it might be that person offering was also different in that way.
Because said user was invested in this community, and reinventing the wheel further is sometimes not beneficial. Some people are really good at specialized tasks, but might not be good at other tasks. Really good backend engineer, not so great at frontend. Perhaps they don’t have the necessary marketing skills required for growth of their own. There are too many unknowns in this story, and it isn’t fair to paint the person harshly like that.
Except he has no idea what the costs would have been, and neither do we, because it never happened.
Except he does have an idea. Some people don't need a summary from a double-blind randomized decade-long experiment to know things
The author has been burned by this in the past many times. You try to include people who say they want to help.. but when alignment is off it winds up just hurting the project.
I've encountered this with dozens of contributors myself.
I've encountered this with dozens of contributors myself.
I don't think you are. Not sure why I am reading this either.
Software projects need a "Director" - much like a Film Director.
This person has ultimate control over what the software should be.
I'm always surprised to find software that is a really cohesive and appears to be the implementation of a clean and consistent vision, because software projects have so many people pulling it in so many directions.
This is, IMO, why MacOS is such a simple and clean and consistent implementation and Windows is just spaghetti soup. I don't know the truth of how these projects are run but I imagine at Apple there is someone at the top with a really clear vision of what MacOS should be.
This person has ultimate control over what the software should be.
I'm always surprised to find software that is a really cohesive and appears to be the implementation of a clean and consistent vision, because software projects have so many people pulling it in so many directions.
This is, IMO, why MacOS is such a simple and clean and consistent implementation and Windows is just spaghetti soup. I don't know the truth of how these projects are run but I imagine at Apple there is someone at the top with a really clear vision of what MacOS should be.
Apple came up with Swift. Apple's pulled off multiple changes in processor architecture (68k/PPC/Intel/Apple Silicon). They are pretty much the poster child for 'my way or the highway', for vision that shows no interest in compromising with the weight of accumulated expectation.
They're consistently willing to throw everything away and make up a new thing and force everybody to do that (and re-buy all their stuff). I don't know the specifics of how, organizationally, they do it.
They're a proof that this way of doing things can be successful, and profitable.
They're consistently willing to throw everything away and make up a new thing and force everybody to do that (and re-buy all their stuff). I don't know the specifics of how, organizationally, they do it.
They're a proof that this way of doing things can be successful, and profitable.
> and re-buy all their stuff
I’ve found my Apple products have a far longer longevity than similar products.
I’ve never found like I need to re-buy something because of a product change…
I’ve found my Apple products have a far longer longevity than similar products.
I’ve never found like I need to re-buy something because of a product change…
You aren't totally wrong, but the dozens of different dongles I bought over the decades using Apple gear are a nuisance. The amount of display adapters alone...
I'm sure that somebody has thought this through more fully than myself, but the impression I have is that for software, the benevolent dictator model works best. Python and Javascript occupy adjacent places in the programming language firmament, but the Python language (with van Rossum having fairly tight control over it), although bloating somewhat over time, has still ended up quite a lot more elegant than Javascript.
Ironically, Guido got dethroned precisely because python became too popular and “you can’t please all of the people all of the time” so he just walked away.
Now they have committee meetings to decide if an idea is good enough to form a committee to discuss if a committee should be formed to discuss the idea — though, probably not exactly like that…
Now they have committee meetings to decide if an idea is good enough to form a committee to discuss if a committee should be formed to discuss the idea — though, probably not exactly like that…
Modern python is not more elegant than modern JS, I disagree (I’ve been coding in both for over 15 years).
Python has a good degree of elegance to it, and it does have less warts due to its less stringent backwards compatibility requirements. But JS is very elegant, and better at it than python thanks to python’s shitty lambdas vs js anonymous functions.
Python has a good degree of elegance to it, and it does have less warts due to its less stringent backwards compatibility requirements. But JS is very elegant, and better at it than python thanks to python’s shitty lambdas vs js anonymous functions.
Maybe a silly question, but if js is such a complete language, why are there so many js frameworks being developed all the time, all seemingly with the goal of making it easier to do fairly basic tasks with js?
Elegance and completeness are two different things. But to answer your question anyway, I would say a framework's goals are more specific than the language's.
For example, Python serves both the data science community and the embedded community. The two have wildly different goals, and thus, different frameworks to achieve "fairly basic tasks [for their domain]".
JS serves so many different communities/domains, which is why there are so many frameworks. Larger audience, with even more different needs. The fact it can serve so many different audiences is a testament to its elegance.
For example, Python serves both the data science community and the embedded community. The two have wildly different goals, and thus, different frameworks to achieve "fairly basic tasks [for their domain]".
JS serves so many different communities/domains, which is why there are so many frameworks. Larger audience, with even more different needs. The fact it can serve so many different audiences is a testament to its elegance.
There’s nothing elegant about continuously accreting features.
If JavaScript were limited to The Good Parts I could say it’s elegant. As it stands I’d describe it as more akin to Frankenstein’s monster but riddled with tumors.
If JavaScript were limited to The Good Parts I could say it’s elegant. As it stands I’d describe it as more akin to Frankenstein’s monster but riddled with tumors.
This was not the question being answered.
There was no question to be answered.
You responded to an opinion which compared the relative elegance of two scripting languages with your own opinion.
I also provided an opinion.
You responded to an opinion which compared the relative elegance of two scripting languages with your own opinion.
I also provided an opinion.
Completely agree. This is why on whole large companies fail to innovate. Too much design by committee, too scared to trust someone with a vision.
This story sounds quite a lot like a few experiences I had.
Years ago (more than I'd like to admit), I took to playing Travian with friends and coworkers. Travian is an RTS, where 'Realtime' really means 'Real-Time'! If you attack the town next to you, just a few squares away, it can take 5 hours for your troops to arrive and the battle to ensue.
It was the perfect game; you could play it casually, in between stuff at work during the day, or on break, or in the evening.
My friends started getting really into it and spending a lot more time on it. I did not want to spend more time playing it, but it was a fun game. The makers of Travian did something interesting, though - they would dump one database table with city data every night for people to do interesting things with. My friends were using a bunch of these tools already, but I perceived some opportunity to build tools which didn't yet exist - like a tool which let you discover inactive accounts to pillage. I starting building more and more tools, eventually starting to write a bot to play the game for me, by automatically raiding inactive accounts and automatically building up my current towns to avoid appearing inactive. My goal in doing this wasn't to play the game per se, but to learn and get better at programming.
So I made the mistake of mentioning all this to another friend who was playing Travian. He was interested. I told him if I ever finished, he could try out the bot, but in the meantime he could use the rest of my tools.
Well, he got impatient waiting for the bot (which btw, I never finished, but I did learn some cool stuff from the experience). He decided he was going to 'help' me, by group calling me with another programmer friend of his who first of all quizzed me on how I was building it, and telling me I was doing it the wrong way and that I needed to use different languages, frameworks, messaging layers, etc. Yeah, so now that I am way further in my career, that guy was dead wrong and an idiot who was trying to overcomplicate everything. But the point was - he didn't want to help, he wanted to stroke his own ego by fixing (or as the case may be, fucking up) some other idiot's project.
This actually really strained my relationship with my friend. Huge dick move, and one that took me a long time to forgive him for. Stay out of my personal projects! To me, it felt along the lines of hearing about an argument with my wife, and then unbidden forcing me to take a call with a relationship coach who told me I was a bad husband.
It was the perfect game; you could play it casually, in between stuff at work during the day, or on break, or in the evening.
My friends started getting really into it and spending a lot more time on it. I did not want to spend more time playing it, but it was a fun game. The makers of Travian did something interesting, though - they would dump one database table with city data every night for people to do interesting things with. My friends were using a bunch of these tools already, but I perceived some opportunity to build tools which didn't yet exist - like a tool which let you discover inactive accounts to pillage. I starting building more and more tools, eventually starting to write a bot to play the game for me, by automatically raiding inactive accounts and automatically building up my current towns to avoid appearing inactive. My goal in doing this wasn't to play the game per se, but to learn and get better at programming.
So I made the mistake of mentioning all this to another friend who was playing Travian. He was interested. I told him if I ever finished, he could try out the bot, but in the meantime he could use the rest of my tools.
Well, he got impatient waiting for the bot (which btw, I never finished, but I did learn some cool stuff from the experience). He decided he was going to 'help' me, by group calling me with another programmer friend of his who first of all quizzed me on how I was building it, and telling me I was doing it the wrong way and that I needed to use different languages, frameworks, messaging layers, etc. Yeah, so now that I am way further in my career, that guy was dead wrong and an idiot who was trying to overcomplicate everything. But the point was - he didn't want to help, he wanted to stroke his own ego by fixing (or as the case may be, fucking up) some other idiot's project.
This actually really strained my relationship with my friend. Huge dick move, and one that took me a long time to forgive him for. Stay out of my personal projects! To me, it felt along the lines of hearing about an argument with my wife, and then unbidden forcing me to take a call with a relationship coach who told me I was a bad husband.
> he didn't want to help, he wanted to stroke his own ego by fixing (or as the case may be, fucking up) some other idiot's project
Maybe that’s just the way he approaches problems. Not necessarily helpful to you, maybe legitimately annoying, but why assume the worst?
Maybe that’s just the way he approaches problems. Not necessarily helpful to you, maybe legitimately annoying, but why assume the worst?
I don't think he was intentionally trying to fuck up my project.
But that surely would have been the result, had I taken his advice verbatim.
But that surely would have been the result, had I taken his advice verbatim.
This is gold! I love your world. Let’s be friends!
related: https://macwright.com/sites/polite.technology/preview
""" Responding to feature requests
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
The maintainer does not owe their time to anyone The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.
Ignoring the second principle will damage the project
and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.
1.) Maintainers are the keepers of the project principles
2.) The goal of the software.
3.) The scope that defines problems that the software will try to fix and those it will not.
4.) The style of the project: which programming practices are used, which language.
5. The culture by which the project is managed.
6. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed.
"""
""" Responding to feature requests
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
The maintainer does not owe their time to anyone The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.
Ignoring the second principle will damage the project
and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.
1.) Maintainers are the keepers of the project principles
2.) The goal of the software.
3.) The scope that defines problems that the software will try to fix and those it will not.
4.) The style of the project: which programming practices are used, which language.
5. The culture by which the project is managed.
6. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed.
"""
Sometimes my 5 year old wants to build her block tower just the way she wants, and she says no thank you if someone offers to help. Other times she accepts help and then the tower takes a different form. Both ways are OK.
By the point of “It is being so wrapped up in yourself and your own goals that you cannot accept the fact that your goals are not more important that those of everyone around you.” I couldn’t help but think of the expression “Pot…Kettle…Black.”
I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.
I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.
> I think most Engineering Managers know that doubling the number of engineers doesn’t double the speed of development, but you have the accept that sacrifice to actually get things to market.
You might be surprised at the number that do think it's double or close to it.
In reality it's often negative productivity. The current engineers have to lose time training the newcomers and the newcomers might not even be versed or skilled in any part of it at all.
You might be surprised at the number that do think it's double or close to it.
In reality it's often negative productivity. The current engineers have to lose time training the newcomers and the newcomers might not even be versed or skilled in any part of it at all.
The author is not being hypocritical. They can accept that their goals are not more important than the person emailing them. But (in the author’s view) their goals are incompatible. This project can only achieve one set of goals. If they try for both, it’s likely neither. So, the project goes as-is.
I can think that my hunger isn’t more important than my family’s, but if someone offers to help eat the sandwich I just made reply “go make your own”.
I can think that my hunger isn’t more important than my family’s, but if someone offers to help eat the sandwich I just made reply “go make your own”.
The author is not being hypocritical, just arrogant.
Well, it's their project.
Granted. But then why write the passive-aggressive blog post and post it on Hackernews?
Just say no. Done deal.
Just say no. Done deal.
If you think there was hypocrisy then I think you lost the thread - the point is not accepting help from people who are more interested in their own vision of the project than yours (as the originator of that project). Hence why they don't accept offers of volunteer help.
The author seems to propose it is impossible for large teams to be productive. They even go so far as to claim most potential team mates have malice intent to “sabotage the project”.
Amazon is an example of an organization that does this well (i used to work there). Small teams are responsible for their own project(s). Project(s) can be composed to form higher level project(s). It’s certainly not impossible, and id rather put in effort to manage team(s) than to place an increasingly insurmountable amount of pressure on myself.
Perhaps the reason the author’s project has “few users” is that there are competing alternatives that have authors who understand how to leverage team work to deliver more value to users, and users go where they perceive value.
Also, if you worked for an organization that actually hired (and retained) people with malice intent, i dont think team size was the real issue. In that sense i do agree with the author that you should screen anyone and ensure your goals align before agreeing to invest time in trying to work together. If someone is offering to add a feature you dont think fits in the project, i have a hard time characterizing that as “malice intent”, though!
Amazon is an example of an organization that does this well (i used to work there). Small teams are responsible for their own project(s). Project(s) can be composed to form higher level project(s). It’s certainly not impossible, and id rather put in effort to manage team(s) than to place an increasingly insurmountable amount of pressure on myself.
Perhaps the reason the author’s project has “few users” is that there are competing alternatives that have authors who understand how to leverage team work to deliver more value to users, and users go where they perceive value.
Also, if you worked for an organization that actually hired (and retained) people with malice intent, i dont think team size was the real issue. In that sense i do agree with the author that you should screen anyone and ensure your goals align before agreeing to invest time in trying to work together. If someone is offering to add a feature you dont think fits in the project, i have a hard time characterizing that as “malice intent”, though!
> The author seems to propose it is impossible for large teams to be productive.
Not productive, efficient.
Not productive, efficient.
It’s not narcissism. Don’t use terms you’ve researched on Wikipedia to diagnose other people. If that’s narcissism, then what’s creating a project that is the unique extension of your own values?
I’ll answer: both are legitimate ways to approach the world, that may involve an acceptable and perhaps at times level of selfishness.
Sometimes things don’t work with other people because you don’t see things the same way. They are not Wrong and Bad.
I’ll answer: both are legitimate ways to approach the world, that may involve an acceptable and perhaps at times level of selfishness.
Sometimes things don’t work with other people because you don’t see things the same way. They are not Wrong and Bad.
I like that I can scan down the comments on HN and usually find one that says what I wanted to say.
Damn straight. It's not narcissism to have ideas and be excited about them and to suggest that a team or a founder pursue those ideas, whether or not that jibes with someone else's original vision.
The OP doesn't tell us what the reaction was of the person who offered him help, when he re-explained his vision. Was the reaction something like "oh, okay, I didn't realize you felt so strongly about that?" Was it "I'm a narcissist and I don't care what you want?" I think the OP might be a little insecure about negotiating with other people-- which is fine-- but what not fine is to turn that into universal advice for other people about not talking to strangers.
Damn straight. It's not narcissism to have ideas and be excited about them and to suggest that a team or a founder pursue those ideas, whether or not that jibes with someone else's original vision.
The OP doesn't tell us what the reaction was of the person who offered him help, when he re-explained his vision. Was the reaction something like "oh, okay, I didn't realize you felt so strongly about that?" Was it "I'm a narcissist and I don't care what you want?" I think the OP might be a little insecure about negotiating with other people-- which is fine-- but what not fine is to turn that into universal advice for other people about not talking to strangers.
I read it clearly as someone who does not want to work with other people and deal with their bs. That’s fine, I get it. But at least be mature about that and own it.
There’s a reason why there’s a profession in software—management—that often exclusively involves dealing with other people. In fact, good management is critical to the success of any large project. But it’s not an easy job.
There’s a reason why there’s a profession in software—management—that often exclusively involves dealing with other people. In fact, good management is critical to the success of any large project. But it’s not an easy job.
This mostly sounds like the project owner doesn't have experience, or perhaps more importantly time, to manage the project and 3rd party contributions. Nothing is wrong with that, of course - but the framing here, I take issue with.
Placing the codebase on GitHub would allow folks to work and make contributions in the form of a Pull Request, which the OP can reject with explanation if it does not go in the direction they desire. They can even setup a roadmap and tickets (issues) to help guide eager-to-help offers.
For anyone wanting to take the project in a direction OP doesn't want - they can fork it and do just that.
So no, don't beware of offers to "help" - be aware of your time commitments and that not everyone's goals will always align with yours. That's just how open source works...
Placing the codebase on GitHub would allow folks to work and make contributions in the form of a Pull Request, which the OP can reject with explanation if it does not go in the direction they desire. They can even setup a roadmap and tickets (issues) to help guide eager-to-help offers.
For anyone wanting to take the project in a direction OP doesn't want - they can fork it and do just that.
So no, don't beware of offers to "help" - be aware of your time commitments and that not everyone's goals will always align with yours. That's just how open source works...
I think the confusion is coming from it being a social network which requires them to ask people for “help” to prove out their ideas — you can’t have a network without users.
Having people helping to prove the idea is one small step away from having people helping to implement the idea and, IMHO, is where the confusion is coming from. They want to implement the idea without help but can’t because the idea itself can’t work without help and helpful people are, unfortunately, helpful.
Totally wrong message being learned here.
Having people helping to prove the idea is one small step away from having people helping to implement the idea and, IMHO, is where the confusion is coming from. They want to implement the idea without help but can’t because the idea itself can’t work without help and helpful people are, unfortunately, helpful.
Totally wrong message being learned here.
What I read sounds like the project owner can clearly articulate the projects purpose (a point about free speech and big tech v lightness and about enabling).
And the proposed contributions are reasonably contrary to them as he sees it.
Experience, time... I think the response in this case was perfectly reasonable so I don't know how to remark on this.
Hosting the code (someplace) and discussing issues may be separate good suggestions, all in the context of the projects purpose.
Experience, time... I think the response in this case was perfectly reasonable so I don't know how to remark on this.
Hosting the code (someplace) and discussing issues may be separate good suggestions, all in the context of the projects purpose.
You can have the experience and time to do something and choose not to.
That is perfectly fine - but then don't write a blog post warning people about free offers for "help".
Just instead say you're not interested in doing OSS and want to keep the project private. You're not obligated to do anything.
Just instead say you're not interested in doing OSS and want to keep the project private. You're not obligated to do anything.
> which the OP can reject with explanation if it does not go in the direction they desire.
Often that alone - going through pull requests is time consuming enough to drain you.
Often that alone - going through pull requests is time consuming enough to drain you.
I think the author is taking a bit of the wrong lesson from his experience.
One of the challenges of coordinating a group of people is getting everyone to buy into the same vision. Fact is that other people see the world differently and may have different goals. Here the author is attributing that to narcissism and maliciousness when most of the time it isn't that.
So yes, as you add more people it gets more challenging to get everyone rowing in the same direction. This is why setting a clear direction and clear communication is key, but the increase in communication overhead as the team grows is always going to be difficult. In this case, as others have said, he could've just open-sourced his code so the people who had a different idea were free to run with it.
One of the challenges of coordinating a group of people is getting everyone to buy into the same vision. Fact is that other people see the world differently and may have different goals. Here the author is attributing that to narcissism and maliciousness when most of the time it isn't that.
So yes, as you add more people it gets more challenging to get everyone rowing in the same direction. This is why setting a clear direction and clear communication is key, but the increase in communication overhead as the team grows is always going to be difficult. In this case, as others have said, he could've just open-sourced his code so the people who had a different idea were free to run with it.
You don’t have to learn and grow if other people are Bad
When it comes to new employees he is right.
We just have one that is quitting. Guy is smart of course but he could not understand refactoring all code he touches is not what we hired him for.
If you make 10-20 pages long PR with spelling corrections or renaming variables where functionality company asked you for is 5% then problem is you not understanding there will be 2 or more developers having to read that.
We just have one that is quitting. Guy is smart of course but he could not understand refactoring all code he touches is not what we hired him for.
If you make 10-20 pages long PR with spelling corrections or renaming variables where functionality company asked you for is 5% then problem is you not understanding there will be 2 or more developers having to read that.
Wow, good job! Most places I've worked that guy gets promoted for being "so productive".
If you have a vision, and you make something noteworthy, people will show up with different visions, and try to take your project in a different direction. This happens when you found a company. The most dangerous employee to the life of the company is employee #2. This is why YCombinator doesn't like solo founders, and wants a more stable two-person team with a shared vision for the company. The third employee you hire is much less dangerous because they can be overruled by the majority (without even threatening to fire them).
Also note that wasn't an open-source project, so there's always the threat that someone will steal your code and your hard work. Don't allow someone to see your code unless you're ready to open-source it, or you have enough money to pay for a lawyer if the person steals your code. (I know the concept of software ownership is anathema to most of the HN crowd, but hopefully this makes it through the downvoters to reach its intended lurker audience).
Also note that wasn't an open-source project, so there's always the threat that someone will steal your code and your hard work. Don't allow someone to see your code unless you're ready to open-source it, or you have enough money to pay for a lawyer if the person steals your code. (I know the concept of software ownership is anathema to most of the HN crowd, but hopefully this makes it through the downvoters to reach its intended lurker audience).
Looks like we don't have any evidence of success of this project.
Having other people help your project might be bad for your ego, but it's also a great way to grow as a developer.
Having other people help your project might be bad for your ego, but it's also a great way to grow as a developer.
Such projects have phases of development. If too many people get involved too early, you easily create a "too many cooks in the kitchen" situation.
But once the long-term architecture is largely defined and implemented, there's usually enough inertia and established compartmentalization of modules that more developers can participate without ruining the soup.
But once the long-term architecture is largely defined and implemented, there's usually enough inertia and established compartmentalization of modules that more developers can participate without ruining the soup.
I think the author is a little cynical. As someone with a handful of small open source projects, I know exactly what he is talking about but I wouldn't say it's driven by narcissism. It's mostly just people new to programming trying to contribute and usually learn something through the process of contributing. You can always just tell them they are free to fork your project, this may offend them but if you do it politely and explain that you do not feel like investing that much time in the project or that their changes are too complicated then they will understand.
I think this is why I often push help offers away in other things. If someone wants to help, they may be more experienced and willing to teach. That'd be great. If I was doing an electronics project and an EE found the idea interesting and wanted to help me get it done, fantastic. I'm not trained in that.
However, for many things either I have an idiosyncratic way of doing things or the offer comes from someone who needs me to teach them a lot to meaningfully help. My business bookkeeping is one of those things. Teaching people to do it is stressful and painful, and then I have to worry about the mistakes they make, as opposed to the ones I make.
This author adds a third case, where your project inspires them but they want to take some ownership of the design. Either they don't understand your idiosyncratic approach or they are more comfortable with their own patterns. However, it will be clear that there will be a lot of friction and that's bad for friendships.
I think there's an implicit fourth case, where the offer is coming from a person who doesn't really know how to help but wants to get involved in something they think is cool. These are the people who mix up their terminology in their rants on your forum about how your working software could be much better done.
Finally, there's the people you enjoy teaching, where it's rewarding to include them in your journey. Maybe it's good to consider that possibility from time to time.
However, for many things either I have an idiosyncratic way of doing things or the offer comes from someone who needs me to teach them a lot to meaningfully help. My business bookkeeping is one of those things. Teaching people to do it is stressful and painful, and then I have to worry about the mistakes they make, as opposed to the ones I make.
This author adds a third case, where your project inspires them but they want to take some ownership of the design. Either they don't understand your idiosyncratic approach or they are more comfortable with their own patterns. However, it will be clear that there will be a lot of friction and that's bad for friendships.
I think there's an implicit fourth case, where the offer is coming from a person who doesn't really know how to help but wants to get involved in something they think is cool. These are the people who mix up their terminology in their rants on your forum about how your working software could be much better done.
Finally, there's the people you enjoy teaching, where it's rewarding to include them in your journey. Maybe it's good to consider that possibility from time to time.
As a maintainer (and product owner/pm) of OSS, I somewhat disagree with the OP. Beware of your over-attachment to a project that others are willing to contribute their ideas, time, and energy to. You are not an oracle; nor are you the only user of your product. Other people have better ideas than you do sometimes, especially when they're your users.
Give them latitude to take the project in ways you disagree with, even vehemently. Your project will be better for it, and you'll learn something along the way.
Give them latitude to take the project in ways you disagree with, even vehemently. Your project will be better for it, and you'll learn something along the way.
Just a tip: don't forget the nearly 50-year old book The Mythical Man-Month. It may have some lessons!
Definitely read Mythical Man-Month, which describes how adding more people may delay a project due to communication overhead ("why did the Tower of Babel fail?").
I was thinking this article would be an example of that, but actually while Mythical Man-Month mostly assumes that new team members would share the same visions and goals, this article takes a more adversarial view where new team members are assumed to come with their own agenda. I believe it's a form of cookie licking[1].
[1] https://devblogs.microsoft.com/oldnewthing/20091201-00/?p=15...
I was thinking this article would be an example of that, but actually while Mythical Man-Month mostly assumes that new team members would share the same visions and goals, this article takes a more adversarial view where new team members are assumed to come with their own agenda. I believe it's a form of cookie licking[1].
[1] https://devblogs.microsoft.com/oldnewthing/20091201-00/?p=15...
> "My primary goal for Xnet is to prove that--contrary to everything everyone else says--one does not need a huge, expensive server on a super-fast Internet connection to host a social network with tens of thousands of users"
I don't think "everyone else" believes that. In fact I believe a "social network with tens of thousands of users" can probably be served off a bash script running on a Raspberry pi over SQLite.
I don't think "everyone else" believes that. In fact I believe a "social network with tens of thousands of users" can probably be served off a bash script running on a Raspberry pi over SQLite.
I mean, that basically describes a telnetable bulletin board system, and those definitely run off an RPi.
This is a common problem with tech-adjacent types: believing that technology is the solution to all problems, including social ones. If someone isn't using your preferred social networking solution, the problem isn't necessarily that you're not using the latest whizbang language and hardware....... maybe you just haven't given them anything to do on your network. Put another way: the telephone arguably didn't catch on as a utility with obvious use until after the 1878 Tariffville Crash[1]. If you want to start a new network, you need a social nucleation point... whether that's you writing interesting stories, composing music, making artwork, whatever... SOMETHING that people can participate in and interact with in some fashion. Without that you've just got a communications device with no one in particular to reach for any reason.
-- [1] https://en.wikipedia.org/wiki/1878_Tariffville_train_crash
This is a common problem with tech-adjacent types: believing that technology is the solution to all problems, including social ones. If someone isn't using your preferred social networking solution, the problem isn't necessarily that you're not using the latest whizbang language and hardware....... maybe you just haven't given them anything to do on your network. Put another way: the telephone arguably didn't catch on as a utility with obvious use until after the 1878 Tariffville Crash[1]. If you want to start a new network, you need a social nucleation point... whether that's you writing interesting stories, composing music, making artwork, whatever... SOMETHING that people can participate in and interact with in some fashion. Without that you've just got a communications device with no one in particular to reach for any reason.
-- [1] https://en.wikipedia.org/wiki/1878_Tariffville_train_crash
Sort of off topic but I’ve noticed that when push comes to shove a lot of people are very resistant to the notion that the road to hell is paved with good intentions.
The implication being: just because you have good intentions, or because you feel the positivity in your heart, doesn’t mean you’re actually doing good. “But surely”, we all think, “that applies to other people, not me. I would know.”
The implication being: just because you have good intentions, or because you feel the positivity in your heart, doesn’t mean you’re actually doing good. “But surely”, we all think, “that applies to other people, not me. I would know.”
Blinkered and badly-written take on Open Source, and - to a larger extent - team work in general.
Obviously there are potentially problems with any development model but if you don't have the skill or motivation to be a maintainer in the open or work in good faith without ego within a team, that's cool - but maybe don't assume everybody has the same limitations as you in that regard.
Obviously there are potentially problems with any development model but if you don't have the skill or motivation to be a maintainer in the open or work in good faith without ego within a team, that's cool - but maybe don't assume everybody has the same limitations as you in that regard.
Not much wisdom from this article besides "keep other out, they don't understand your vision".
In this case, the help offered didn't align to the project owner's vision and wasn't accepted as a result. However, that doesn't mean that offers of help should always be ignored - they can often lead to improvements, opportunities, and welcome collaborations.
The author claims that people's offering of help is not true help since it's for selfish reasons. I would like to argue that this is natural and necessary to some extent. People are motivated by what benefits them personally.
All your relationships, pretty much everything you do, has a selfish aspect to it. You're not in a relationship with someone because you're being kind towards them, you're in a relationship because it benefits you, and hopefully it's mutually beneficial.
So, you need to let people be just a little bit selfish, because you need them to be motivated. Without people working for the sake of personal motivation, open source wouldn't work.
All your relationships, pretty much everything you do, has a selfish aspect to it. You're not in a relationship with someone because you're being kind towards them, you're in a relationship because it benefits you, and hopefully it's mutually beneficial.
So, you need to let people be just a little bit selfish, because you need them to be motivated. Without people working for the sake of personal motivation, open source wouldn't work.
Everyone cares about himself and everyone wants the limelight for himself. Divide and rule works perfectly in an egocentered environment. Especially for the work for free, beg for money, fork for yourself os ecosystem.
It is good that the writer could discern that his and the would-be helper's goals were not aligned.
I wonder what the best ways of discovering (and perhaps verifying) alignment-or-not could be.
I wonder what the best ways of discovering (and perhaps verifying) alignment-or-not could be.
The mythical man-month is just as true (or even more true) of open source than closed. Just because something is open source doesn't mean it has to be a free for all.
I think the way engineers help open source projects is to send a PR. ‘Offering to help’ without contributing anything seems somewhat suspicious.
On the contrary, the right way is to ask first before making large changes that might not even be wanted. For obvious fixes sure, shoot first. For anything more complex it is inconsiderate to put the maintainer into a position where they have to choose between comprimising their project or hurting your feelings.
Oh definitely, don’t send a large change as a first PR. We are in agreement there.
Anyone have a link to the post the author referenced here? "A couple of weeks ago, someone else <posted> his desire to help code Xnet, and he included his vision of the direction it should go" (emphasis added)
The way this story was presented makes me curious to see the dialog (if there was any) between the author and the guy who offered to help.
The way this story was presented makes me curious to see the dialog (if there was any) between the author and the guy who offered to help.
This article talks about two main things. Accepting "help" applies more broadly than engineering or software.
And I agree with his overall goals of his project..I believe the same. We get trapped into this bigger and better and more complicated stacks and the hardware resources required, but you can reach a lot of folks with simplicity and the basics.
And I agree with his overall goals of his project..I believe the same. We get trapped into this bigger and better and more complicated stacks and the hardware resources required, but you can reach a lot of folks with simplicity and the basics.
I've been finding myself less and less inclined to read semi-long articles so here is Kagi's summary:
The author warns against accepting help from people who are not genuinely interested in helping further the goals of a project. While the offers may seem helpful, these people often waste time driving the project in the wrong direction to suit their own goals. They do not care about the original vision of the project, but instead want the project owner to help them. This was evident when someone offered to help scale up the author's social network, Xnet, without understanding that the author's goals were the opposite - to prove a social network can run on a tiny, low-power server. While scaling up Xnet may have been fun, it was not the purpose of the project. Therefore, the author advises to be wary of offers of "help" and sometimes it is best to do the project yourself.
The author warns against accepting help from people who are not genuinely interested in helping further the goals of a project. While the offers may seem helpful, these people often waste time driving the project in the wrong direction to suit their own goals. They do not care about the original vision of the project, but instead want the project owner to help them. This was evident when someone offered to help scale up the author's social network, Xnet, without understanding that the author's goals were the opposite - to prove a social network can run on a tiny, low-power server. While scaling up Xnet may have been fun, it was not the purpose of the project. Therefore, the author advises to be wary of offers of "help" and sometimes it is best to do the project yourself.
I'll admit I was going into this thinking it was a warning against some kind of hostile takeover ig said project.
Instead it just reminded me of yanderedevs excuse of not allowing tiny build help him finish yandere simulator, which was very similar to this.
Instead it just reminded me of yanderedevs excuse of not allowing tiny build help him finish yandere simulator, which was very similar to this.
[deleted]
This is literally why git exists.
I wouldn't say 'beware', rather, just say 'fork it and have fun'.
Obviously you have to be a bit selective over who can contribute to a small project.
I wouldn't say 'beware', rather, just say 'fork it and have fun'.
Obviously you have to be a bit selective over who can contribute to a small project.
Or OP could post it on GitHub with integration tests around eg memory footprint.
There’s a mindset shift between “senior engineer” and “tech lead” that OP seems to be struggling with…
There’s a mindset shift between “senior engineer” and “tech lead” that OP seems to be struggling with…
This is terrible anti-social advice. Getting projects to work is about organizing people to work together. Unless your DJB, software is a team sport. If it is a one person project it will fail.
Now when somebody offers to help, be welcoming because it's amazing. But also remember that most of the time their desire to help won't translate in to something useful. That's ok, eventually people will show up who are helpful. Keep being open.
Also, what the hell is somebody doing making a social network if they don't like people.... WTF!?
Now when somebody offers to help, be welcoming because it's amazing. But also remember that most of the time their desire to help won't translate in to something useful. That's ok, eventually people will show up who are helpful. Keep being open.
Also, what the hell is somebody doing making a social network if they don't like people.... WTF!?
Linus was able to do it. We all benefit from the fact that Linus is a jerk that knows what he is doing and cares about the result.
Now I want to see the unnamed social network.
OP created wt.social
> The non-toxic social network
The tone of TFA doesn't make that likely.
> Welcome to a place where advertisers don’t call the shots.
> Where your data isn’t packaged up and sold.
> Where you – not algorithms – decide what you see.
> Where you can directly edit misleading content.
Sounds pretty bad.
> Where bad actors are kicked out and kept out.
Strong echo chamber vibes.
> Where you actually like spending time.
> Welcome to social media the way it should be.
> Welcome to WT.Social.
> Register [to even be able to see any of it at all]
Yeah I can see why this would not catch on.
The tone of TFA doesn't make that likely.
> Welcome to a place where advertisers don’t call the shots.
> Where your data isn’t packaged up and sold.
> Where you – not algorithms – decide what you see.
> Where you can directly edit misleading content.
Sounds pretty bad.
> Where bad actors are kicked out and kept out.
Strong echo chamber vibes.
> Where you actually like spending time.
> Welcome to social media the way it should be.
> Welcome to WT.Social.
> Register [to even be able to see any of it at all]
Yeah I can see why this would not catch on.
The GitHub block function, your friend, is.
Now I'm going to be the one and say that this was written by an AI. Because it doesn't make any sense at all.
Tru dat.
Don’t you also have to be a little bit narcissistic to say, “You can help build this thing but only as long as you adhere to my vision.”
No? They're not forcing, or even encouraging, people to help them. People just... Want to. It's not narcissistic to say "Oh... Well I was planning to work on this myself, you can help if you want, but I have my own vision that I don't want to diverge from"
it's not narcissistic to say "You can help build this thing but only as long as you adhere to this vision.”
it would be narcissistic to say "...and this vision is MY vision, nobody else has a vision like mine" which I don't hear the author saying
it would be narcissistic to say "...and this vision is MY vision, nobody else has a vision like mine" which I don't hear the author saying
Er... reading this, I would rather suspect the author of "not being a team player". Of course, if other developers find your project interesting and want to contribute, they may have their own features and use cases in mind that don't necessarily overlap with what you have planned, which doesn't however mean that it has to be a "wrong direction". As the owner of the project, you are free to accept their contributions or not, and they are free to fork the project and take it into another direction if you don't like that direction.