It's also a major product problem. Imagine that you're the engineering director, or CTO of a company whose next release is blocked by some Flutter bug. What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix. Oh well - can't use Flutter any more. Flutter won't survive if these kinds of experiences become common.Your team doesn't know how to work on the Flutter frameworkskill issue quite frankly
@pounce@nyan.network my point was really just about cost analysis of engineering time to rewrite a project from scratch to stop depending on something vs just fixing the thing you're depending on (even if that means maintaining a fork) usually leans towards the latter with mature projects
@pounce@nyan.network I guess I wasn't clear, I meant creating a fork/patchset, did plenty of that at my last job. I am aware that their acceptance of external contributions is basically nil.... that PR thread is ghastly :notlikethis:
@nik eh not really the flutter project is especially horrible in answering community PRs/etc i have been trying to get a tiny dart library change merged for a year, and i've involved several dartlang team members at google before they were laid off and i still haven't gotten it merged https://github.com/dart-lang/cli_util/pull/94
basically this means you need to fork _every library_, and then you have to maintain a fork anyway
really not sure where this point is coming from...it's almost always easier to find someone to fix a bug in the open source framework you're using than it is to rewrite an entire project in something else