Development resources

Ha, so I have a humble proposal, to make it relevant, I would like to provide a motivation first; here it goes:

  • Many good features are proposed, but rarely are these features implemented unless the original author of the proposal does so.
  • Good changes are proposed, but again, unless the author of the proposal implements those – it’s likely that the change will not see the light of day.
  • Good existing features fall victim to bitrot and lack of maintenance and end up being cut from the source. Main reason usually is that original author leaves the project and stops maintaining the code.

Good is used here to mean something that is favoured by majority of the community

This boils down to the nature of open source development. Typically there’s no money involved, so people contribute their time voluntarily, this requires interest on part of the contributor and ability to pay for that time out of one’s own pocket, since that keyboard, electricity and internet cost money, and calories you’re burning typing the code vigorously need to be purchased at a local food merchant. No big revalational here, I hope 🙂

Why do I bring this up? I believe that for three.js to grow and mature – it would be beneficial to have a paid development team. Having a development team could be achieved by hiring some guys, either from the outside or from within the community, or by negotiating with companies, that find three.js worth their while to support, to donate development resources. Such a team could be used to work on long-term project as well as on addressing the problems I have pointed out above.

I’m not a business guy, so my knowledge on this subject is very limited, but I hope that others could contribute their knowledge 🙂

Author: Fantashit

1 thought on “Development resources

  1. I can’t comment on funding or donations, but I think the roadmap question is at least as important, and it’s worth noting that @mrdoob has already been organizing issues and PRs in a way that provides a pretty functional roadmap: milestones. There’s no official description of what each milestone means (probably rXX should have the description filled out?) but here’s my working assumption:

    • r94 (or upcoming release) lists issues and features that are prioritized for the next release, and PRs on these issues are more likely to get prompt attention.
    • rXX lists issues and features that are of long-term interest for a future release. PRs on these issues are very welcome, but may take some time to review and merge.
    • no milestone — issues/features without a milestone assigned are not necessarily things we don’t want to address, but are less likely to get a prompt review and may be at higher risk of not being merged.

    @mrdoob if this is not consistent with how you’re using milestones, please correct me. 😇

Comments are closed.