I'm confident that if Theymos really wanted to upgrade bitcointalk he could easily do so in a much shorter time period.
That's correct but it doesn't make sense to introduce it before it has passed all of its tests
[it'll be a workaround that might introduce other problems as opposed to a solution].
I'm pretty sure he'd have all the coders he'd need, because if that were the bottleneck there would be tons of members stepping up to help.
The last time I checked, he was the only one
[not sure if that's still the case], and in regards to the latter part, I don't think it's that easy to hire a coder/programmer/developer without ulterior motives.
without an explanation as to why that's the case
Am I completely missing something?
Here you go:
Link~Snipped~
The things blocking a transition from the current software to the new software are:
- There hasn't been enough testing. I think that immediately after transition, a variety of small missed features, bugs, and performance issues would crop up. As a result, if the transition happened now (which is technically possible!), I'd expect the post-transition user experience to be poor for months while these things are fixed, which I don't want.
- I am the only bitcointalk.org sysadmin and on-demand programmer, and I'm used to the current software. Furthermore, I need to frequently make changes to the current software, but each change I make might require alterations to Epochtalk, which is problematic.
- The current PHP software, while ugly and sub-optimal in many ways, performs well, especially since I have extensively modified the backend to add features and improve performance. So I don't feel much urgency.
- The data-transition procedure still has a few known minor bugs.
~Snipped~