Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The crazy part is that this is absolutely a solved problem.

I'm not sure if everyone misses this due to Linus-worship, holding him up as an example of how to run an OSS project (which... he isn't a good one), but most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here.

I'd love to see everyone:

(1) Buy their nearest PM an appreciative beer, thanking them for keeping this off you at your day job.

(2) Recruit somebody with this experience to your project. It's unreasonable to expect that OSS is a developer-only world, when closed-source software doesn't function that way. Changing the culture of OSS to involve PMs when projects hit a significant size and respect their contributions would be excellent.



> most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here

Good PMs are hard to find, and the problem is far from solved. Some PMs add to the problem by adding more forms with even more mandatory fields that have very little to do with actual development and a lot to do with feeding into their "Project Reports". So, don't buy that beer too hastily.


> Good PMs are hard to find

I'd take this further -- I think finding good PM's is harder than finding good dev's. I'm not sure why exactly. I bet you'd find a lot of dev's who think their PM does the opposite of their job (that is, creates more work for them).


Beacuse you can't judge a PM's work as easily in an interview. For all the difficulty we have hiring people to write code, either your fiz buzzes or it doesn't.

A long term bad-quality PM knows the vernacular and can talk a good game. And thats all you have, really. Not even that fizz buzz level of pass or fail


Product managers's job is not to reduce work for developers (it could be a nice side effect), is to help avoid building unnecessary things and build the right things without waste as much as possible.

PMs end up doing a lot of stuff that's not necessarily their job to keep the wheels turning, and it's the right attitude to a degree (sometimes it allows dangerous sloppiness to survive past its due date) but the job you have in mind should be performed by a good QA person.


> most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here.

That sure would be nice. Almost every PM I've work with has actually just been a source of busywork who seemed to view their job as to ensure that the engineers spent as much time on issue management as possible. The only one which actually tried to do it himself had a habit of closing actionable bug reports because the reporter didn't bother giving the useless extra info that the PM asked for, while sending all the useless ones on to the developers.


Closed-source and open-source software is different in many ways. One little example is that open source software doesn't need to constantly grow features, it can live on with a slow rate of change for decades and be useful. (examples: bash, zsh, rsync, tar, ssh, vim, emacs, awk, sed, gnu screen ... the list is quite long)


When you make a statement like "(which... he isn't a good one)" it would be good to qualify why. Especially when its objectively clear that the Linux project is probably one of the most successful human enterprises to date.

And when you then continue on to claim that PM's is the panacea that will "fix OSS culture" I feel I have to point out that "OSS culture" is what built the technological world we live in today. And while its not perfect, I respectfully suggest that you don't fuxor with things that are not broken, given that the OSS world's track record of delivering world changing software is unrivalled.

To put it more succinctly: https://www.youtube.com/watch?v=CDGuPp1np4o


Except that it IS broken. That's why we're having this discussion. The "Dear Github" post is trying to say "the process of making OSS is broken" but is asking for a software solution to a human problem.

Linus' approach to project management is to chase away everyone by being a "gentleman sausage". He has the sheer technical competence to succeed in spite of this, but it's not a successful approach for most people, and dudes attempting to emulate Linus chase out the decent human beings.

Making the process of making OSS sustainable for mere mortals will go a long way to making more OSS.


Not so. The "Dear Github" post is all about bug tracking facilities in github, nothing more. Previous versions of Github had a more functional issue tracker - it went largely ignored and github wisely removed the unwanted cruft from their code base. Github is not JIRA. OSS projects are free to use whatever bug-tracking facilities they choose. Just like everyone else. I would like to see better API's from github to support this.

On to Linus. There are 12000 contributors to the linux kernel, If Linus sucks at anything, it would be his ability to "chase away everyone". You seem to be of the opinion that if there were more than 12k Linux would somehow be "better". This is entirely conjecture on your part, and many would argue that Linus is fact too lenient as it stands.


I'm a PM and it's disturbing to read how many people think our role is to do QA.


What is "Pls"?

Linus also delegates to his kernel "lieutenants" to scale Linux development.


A typo (now fixed).


Recruit somebody instead of automating it by more smart tool than GitHub? Really? Are you programmer after that? :)


Automating processes involving people from outside your project is just a very hard problem. The trade-off here is investing a possibly small amount of time into recruiting a PM vs. investing a possibly ridiculous amount of time into building a magical issue triaging AI.


When tool have simple fields like "affected versions", "OS", "steps to reproduce", users use them and greatly decrease amount of needed time to classify issue. It's not smart AI, just fields.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: