Development resources

[Usnul]

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 :)

[pailhead]

This is already somewhat the case. For a while the focus of three.js has been to better integrate VR, which seems to be influenced by the likes of google, mozilla and such. I'm not sure how can this be good if it biases the development of the library. It would deter people from contributing, as it's already much easier for a maintainer to land something than a random PR to be accepted. Why would one not on the payroll even bother then, if it may be fruitless effort, and if three's roadmap is internal knowledge to some company.

[Usnul]

@pailhead That's hard to say in a way. I know, for example, that blender works this way, they have a core paid team that takes care of a lot of the hard work.

I understand your worries, and it is certainly something to be taken into account and addressed, but as it stands - I see three.js suffering quite a lot because of the issues I have mentioned.

Let's say i contribute a sick kick-ass shadowmapping system to three.js based on some cutting edge research, and then I figure that there are more dimensions that three and I move on to other pastures. Let's also suppose that this system is greatly appreciated by the users of the library and people really want to have it, but nobody understand it well enough, and nobody invests the time and effort to maintain it. At some point - that code dies. This is a hypothetical. More concrete, there was a guy called @alteredq , he's done a bunch of amazing stuff in three.js, after he left - a lot of that amazing stuff has gradually died. 2 notable examples are: Cascaded Shadow Maps and DeferredRenderer

[pailhead]

I agree with the problem you described but i don't think that this is the best solution.

I think the process itself can be tweaked. In the case you referenced with @alteredq things shouldn't die with him. Imagine if he had to commit change logs, road maps, and actual comments in the code all along. His departure wouldn't make those features die. Three.js suffers from something called the bus factor.

[pailhead]

I also found myself reading and answering a lot of really senseless questions on Stack Overflow. I can't command anyone what they should do. I feel that I can contribute to three.js and that my time would be better spent writing some documentation or comments in the code as to avoid all those SO questions. Unfortunately i can't measure this in any way other than publishing npm modules, since none of my PR's got accepted. So in the end, i don't know if i'm contributing anything here.

I can though express my opinion that a maintainer has already proven their worth along this axis, and that it can objectively be said that their time would be better spend maintaining the library. This feels like a really simple tweak, that doesn't have to involve large corporations and $$$.

[makc]

I bet no amount of comments in the code will force anyone to actually do the work. Comments maybe save 5 minutes of time on a good day. And change logs, I don't even remember when I needed to check them - you just upgrade 3js and things that changed immediately stop working in your project, so you notice )

[pailhead]

@makc it's not about breaking your projects but turning various examples and parts of /src into projects.

[Usnul]

@pailhead

I think the process itself can be tweaked. In the case you referenced with @alteredq things shouldn't die with him.

Oh my! I Believe he's alive and well, simply not a part of this community any longer. https://twitter.com/alteredq?lang=en

His departure wouldn't make those features die. Three.js suffers from something called the bus factor.

Now, I'm going to come off as a nazi or something, but here it goes :D
I believe there are 2 key factors to working on complex topics:
1 - time
2 - ability

When it comes to time - I believe there are enough interested individuals who are willing to commit their time, when it comes to ability - I don't think that everyone here has a PhD in real-time computer graphics, myself included (at least last time I checked.) Which means that some individuals can write a for loop, but not a deferred renderer.

As it happens, more capable the individual - less free time they have, you can still buy that time in my cases. Hence my proposal.

@makc

I bet no amount of comments in the code will force anyone to actually do the work. Comments maybe save 5 minutes of time on a good day.

True, many people are going to respect your time less than their own and ask a question even if typing it in google would yield the same answer, simply on an off-chance that latter might involve Work™. I personally think that this community has done an amazing job with respect to documentation so far, and that it has saved a ton of time to many, myself included.

[pailhead]

Oh my! The @alteredq comment really did come out wrong, i hope he is alive and well!

I found a perfect illustration of what i'm talking about.

1. A user (myself in this case) spends time working with the library and notices odd behavior.
2. User spends their own time and effort to research the behavior
3. User spends their own time and effort to categorize and explain the behavior (issue Ambiguity with texture transformation and texture cloning #12788)
4. No other users or maintainers have the time to check it out.

But then, in #14214 which deals with something else, the discussion around issue #12788 is had.

All i'm suggesting now, and what i've suggested in the past, is to better document this. How are textures wrapped, transformed and optimized has been a long standing issue, and it should be easy to find and search for, not buried in some unrelated PR. Issues should be given visibility.

[pailhead]

In short, for this particular example i suggested something like this #13135.

It also looks like there is no one who can shed some light on why Texture was designed to be as it is today. This i'd like to change, i'd like to be able to look somewhere and know what was the reasoning behind this decision.

[Usnul]

@pailhead I understand your concern, but I think we're talking about largely different subjects. I'm talking about resources for implementation of features that three.js would most benefit from but that no one in the community is either:

1. willing to do
2. able to do

there are lots of proposals and requests that, if you read, go something like "yeah yeah, that would be wonderful" and then nothing. I'm suggesting a way to move those things along. You can't have a roadmap without dedicated development resources, and those cost money. My suggestion is to create a process through which such resources could be secured for three.js.

[makc]

@Usnul you might want to review how the previous thread went down #11318 (tho it seems some comments were deleted)

[pailhead]

I see what you're saying @Usnul. By "resources" you mean actual fuel for the devs? :)

I think road maps could be written without sponsorship, it would just require slightly more discipline.

[Usnul]

@makc that was quite useful, thanks, I remember reading that at the time. It would have liked to see a different outcome for that discussion.

@pailhead I agree, writing roadmap is not so hard. The problem I see is in the commitment. Let's say I'm a cow, and I promise you 100L of milk by the end of the year, but as the year goes on - I end up feeling a lot of my milk to poor starving orphan kittens, and I fail to deliver on my promise. In practical terms - plans without dedicated resources are unreliable, to put it lightly. Having dedicated resources on the team would allow us to create plans and have a reasonable certainty that those plans will be realized, on time and in specified scope. That's a commitment. Does this make sense?

[haroldiedema]

Seeing how popular this library has become over the years, I honestly doubt funding is a real issue.

Why don't we have a donate option somewhere (on the readme / front page of the GitHub project) where people (read: companies) can donate funds? Let @mrdoob handle the funds - if he's willing - and set out a development roadmap. Offer bounties for certain features. I'm sure that this way there are more than enough people (and companies) willing to dedicate their time to developing said features.

I believe there are probably companies that provide services that manage funding and pay-outs to developers if we're not willing to get into this administrative hassle (which I find completely understandable).

[donmccurdy]

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

[pailhead]

Why don’t he just write they down on a wiki somewhere? What’s r99 what’s rxx what’s no milestone. Might be better than guessing :)

[Usnul]

@donmccurdy
I see milestones as part of the problem that I believe funding would address in part. Right now "milestones" are what we basically have already, it just needs a few finishing touches and to be merged into dev branch so that it can be a part of the next release.

That's not planning, that's just reacting on what we have and communicating "basically, we've changed X,Y,Z so far, and it will be a part of the next release".

To me this is reactive and not strategic. Having funding would allows the project to dictate the future, not just communicate changes already made and not-yet-rolled-out.

[donmccurdy]

I think that's exactly what the r94 (or next release) milestone is and should be, but not what the rXX milestone denotes. There are many things in rXX, including several of your own suggestions, that are more longterm/strategic.

Again, I'm not commenting on funding, just pointing out that roadmap-like information is there for anyone interested.