RE:
Note: All replies and discussions deleted regarding this technical topic over at meta, here is my reply to timwis who was felling intimidated while asking questions about a custom macOS dev environment setup:
Hey Tim,
Thanks for posting your views.
I tend to agree with your assessment, with caveats. I think the developers here are extremely talented. If you go back and read their posts during the “early days” of Discourse development (and the commit comments) the intimidation factor was much lower back then. I have read a number of Discourse legacy discussions about early design decisions and those discussion were much less tense, considerably flexible, and less intimidating, for sure.
In my view, one of the key and most fundamental precepts on Rails is to separate the Model, View and Controller (MVC) logic. Among other key design concepts, this also means that the underlying database should be decoupled and very loosely coupled with the underlying MVC DB.
As an example, I’m currently developing a Rails back-office application for a client and we are using the SQLite DB for development because the DB is a single file and easy to configure and test on other sites without any install headaches to speak off (the tradeoff is that performance is poor, features are limited, but that is OK in basic MVC Rails dev). When we move to production, we will more-than-likely use MySQL.
Regarding Discourse, I often read that users here (including our team) would like to run Discourse on databases other than Postgres in a similar manner; but the development of Discourse is tightly integrated with Rails, and all will meet a lot of push-back and strong resistance to suggest supporting anything other than PostgreSQL. The odd thing about this push back is that for MVC architectures, like Rails, the basic premise of Rails is to have the ability to run on any supported DB and so the DB should not be tightly integrated into Rails projects.
I strongly applaud the Discourse design team for such a solid design, especially on Rails (MVC) and Docker. In addition, I also applaud the Discourse team on their integration of GitHub into their software design work flow. Before any upgrade, I find it is always good to read the commits and interesting to see if the commits effect the DB, Rails or EmberJS and how upgrading would effect things important to me and our deployment.
We “late to the party” technical folks often run into unexpected strong push-back, as you have noticed, and it is easy to feel intimated at times, especially for suggesting changes to the core design principles (like this one example, supporting other DBs). My understanding of MVC is that a core design principle is that MVC designers should be able to choose the DB in a Rails deployment. Of course, there can be a preferred or recommended DB or OS; but many users think it would be a very welcome improvement for users if Discourse supported other DBs; like Maria/MySQL.
I honestly do not thing that any long timer here is intentionally intimidating those new to the party. Many have strong opinions and those opinions have crystalized over the last decade. If you go back and read the discussions from many years ago, discussions about dev and design were much more flexible and open minded regarding core changes and new ideas, especially at the system and MVC (Rails) level. Much of the architecture has crystalized over the years and this can be quite intimidating for those “late to the party”, for sure.
I think one useful thing to keep in mind is that the core developers here are busy and they have areas they are willing (and passionate) to work on; and they also have areas they have strong opinions about and do not want to consider changes. If you read the current daily commits, they are all generally in “fine-tuning” mode and, for example, I do not see any serious work on redesigning the plugin system or insuring the underlying DB change can be few lines in an environmental config file.
The core team has a clear idea of what the meta team consider “frozen” (for the most part) and what they consider “tunable” and it does take some time to learn the culture. I find reading the old discussions helpful as well as the commit commits from “way back when”. The overall architecture has been optimized (for performance and the end use experience) for many years and many of the trade-offs from years of this optimization process, will constrain the system today.
Again, I do not think anyone here is trying to be intimidating, so do not let that normal “forum talk” get you down. It takes time to learn local customs and cultures. Furthermore, there is always the very much appreciated option of developing your favorite environment or feature and if you get to the point you think it is ready to share with the community, like setting up a different macOS dev environment please do. I hope you do; because when I jump from a Rails dev project (not Discourse) back into Discourse, there is always something broken when I re-bundle and run Rails, and I think to myself “I must set up a Discourse dev environment on a different machine only for Discourse”; and then I go back to my plain-vanilla Rails project thinking “those Discourse developers sure have done a great job, considering the complexity of running EmberJS as an SPA on top of Rails as an MVC framework!”
Rails is Bliss 
Welcome to Discourse!