A less male gender focused way of saying a “man-year”, a common term to imply the amount of effort, rather than an exact duration.
If someone says it’ll take 3 person-years (just to make it gender agnostic), that means if only one person was working, it’d take about 3 years. It implies that theoretically 3 people could do it in one year, 6 people in 6 months.
It’s not a definitive statement, especially if one has read mythical man month and buys into it, but gives a very tough scoping.
Interesting choice of words beyond just gender. 'Girl' is roughly analogous to 'boy', both implying reduced age. Considering how proficient teenagers are these days, I suppose the terminology is not that far-fetched.
This is what threw me for a loop. I speak in person-hours at work even when other people speak of man-hours, but hearing someone speak in girl or boy-hours is a bit jarring due to the implications around age and experience.
Sorry if my English is broken and I may sound rude but this is my concern for the team.
Other than free time or money, I’m curious if the main issue is due to complex testing process on Windows within the community?
In concerning to support your community, how responsive will the team resolve issues on Windows even if it is ready? As far as I feel you need a project manager to drive the progress. If there is a dip in the quality or, consider rebuild Crystal from scratch that inspire by Go’s roadmap or you will simply throw a huge amount of monies and resources for the contributors to invest with no ROI where Go succeed in simplicity.
Even if you have a big funding at your disposal to fill other missing features and API where Zig already works on Windows and V language are moving hastily to support Windows with even less amount of donations. How did they have the right community to support which I think the Crystal inner working code can be tedious to work on? C is the best language at least most programmers know.
Someone in your team ought to give a serious thought to get this sort out or scale down to Crystal core to keep its simplicity at least: why would you choose LLVM in the first place when it can become complex for a small team and depending on Ruby’s new features that you have to keep adding? Go choose to be simplicity and not accepting new feature for 1.x even when they have vast amount of cash and software engineering?
To put it another opinion, I don’t see how Crystal should be benchmark against Go and others if they are vastly differ in feature capabilities. So for this case, what made you think of comparing?
Since Windows support isn't on parity with other platforms, how can we make sure that our monetary contribution will fully go to the Windows work? Or, is it so that only the 1% of it will make it to the Windows budget?
I can't imagine donations working that way for any organization unless you're donating a considerable sum. Every organization has its own priorities and donations help them meet those priorities. If you have a cool million lying around it might help to convince them to make Windows support a priority, but if not, then all you can do is to donate in hopes of helping them focus on knocking out priorities so that they can get to your pet issue sooner.
True in that small individual donations are unlikely to fund it. Sponsoring a feature is a thing in open source. Either through a bounty site or a fund me site.
Maybe there just isn't much interest in windows support?
Crystal is a fantastic language for server-side programming where it pairs the performance of Golang with the expressiveness of Ruby.
I imagine most Crystal users love it for exactly that reason and have little interest in development resources being diverted to a platform that they have no use for.
IMO, even if 100% of the donations would fund exclusively the Linux version, it would help Windows development anyway, although indirectly. More projects using Crystal on Linux would create more media coverage, hence in the long run more interest for better Windows support, either from the core devs or from external entities. Unless one desperately needs feature X by tomorrow, which would of course be a different story.