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.

"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.

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.

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.