Beware offers of “help” with your projects
misc-stuff.terraaeon.com
misc-stuff.terraaeon.com
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.
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.
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.
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 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.
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.
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).
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.
"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.
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.
Of what team?
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.
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].
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?
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.
> As an engineer, I have worked with many, many other engineers on dozens of projects.
What makes you think this is open source?
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.
Maybe I don't know how to read, but that suggests a corporate setting to me.
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.
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.
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.
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.
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.
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.
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 :)
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?
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.
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.
Welcome to HN.
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.
the job being, being a Linus :-)
Leadership, communication and group by in are so important in any project. People who have mastered those soft skills tend to deliver quality good.
[0] https://gogs.io/
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.
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. :)
But I'm very thankful that the original author just posted his code to Github to make this possible.
That seems like it would make everyone happy, wouldn't it?
Clone it. Fork it. Star it. That’s it.
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 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.
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.
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.
> 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.
Note that this doesn’t extend any of the other rights associated with open source.
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)
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".
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.
I've encountered this with dozens of contributors myself.
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.
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…
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.
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.
You responded to an opinion which compared the relative elegance of two scripting languages with your own opinion.
I also provided an opinion.
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.
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.
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…
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.
Maybe that’s just the way he approaches problems. Not necessarily helpful to you, maybe legitimately annoying, but why assume the worst?
But that surely would have been the result, had I taken his advice verbatim.
""" 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.
"""
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 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”.
Just say no. Done deal.
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.
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!
Not productive, efficient.
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.
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.
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.
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...
Just instead say you're not interested in doing OSS and want to keep the project private. You're not obligated to do anything.
Often that alone - going through pull requests is time consuming enough to drain you.
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.
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.
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.
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.
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).
Having other people help your project might be bad for your ego, but it's also a great way to grow as a developer.
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.
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.
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.
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 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.
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
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.”
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.
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.
I wonder what the best ways of discovering (and perhaps verifying) alignment-or-not could be.
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.
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.
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.
Instead it just reminded me of yanderedevs excuse of not allowing tiny build help him finish yandere simulator, which was very similar to this.
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.
There’s a mindset shift between “senior engineer” and “tech lead” that OP seems to be struggling with…
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!?
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.
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