Hi @dongrentianyu, I also agree that more editions would be helpful to ease the onboarding experience, but I also disagree that what’s known as “empty” should be “replaced” or “hidden”, as that’s exactly what some users want.
Here are just some thoughts to consider:
1.Expanding to user bases is important, but so is NOT discouraging the new users we ARE getting.
You seem to be implying that your recommended approach can only be positive, and that more is always better. This doesn’t consider that some people like “lightweight” options and that having a smaller set of features makes things less overwhelming and less intimidating. There are many examples in the software world of this. Some people prefer “Paint” to “Photoshop”, “Google Sheets” to “Excel”, and so on. People have different preferences, and so having a “Base” version is going to be preferred in a non-zero subset of people we’re trying to attract. Hiding the “base” version only hurts adoption of people like that. And, it’s worth mentioning that due to selection bias, this community may have MANY of those types of people, otherwise they wouldn’t be here 
.
2.Empty is not that empty
You refer to the fact that there are few plugins loaded by default, and that the name denotes that it’s empty, but just to illustrate the point, there are a few features in it that frankly I’d rather be official plugins instead of core features. Does “empty” really need a bitmap editor? Who’s using this?? 
How much smaller of a file could we have if this was split into a plugin? Going even further, note that some people are so passionate about a minimalistic approach that they have their own “editions” where the selling point is less features - like Feather Wiki which is only 58KB (Empty TW is 2554KB). There was also a post very recently about a wiki bragging about less than 2KB!! To that end, I might suggest “empty” be named “base” or “standard” or something less negative sounding.
3.Community Editions are not supported by the core team, which adds downstream risk
I’ve been using TiddlyWiki for a very long time (was introduced by this article on Lifehacker back in 2005). One of the hard lessons I’ve learned along the way is that this is a strong but small community, and relying on non-core plugins is risky. Many plugins, savers, and other things we come to depend on that are not core expire when the authors move on to other things. It’s sad, but part of open source software, this is basically all volunteer work. Timimi has been mentioned a lot recently, I’m still mourning Jed moving on from BOB, and there are other examples. If we’re going to heavily promote a community edition, we better have a robust plan of maintenance for the long-term, or we avoid bring people on and then having them go through a painful process of plugin abandonment. That’s why every couple of years I also try to bring up Relink in particular, I agree that is one of the plugins it would be most painful to lose. Not only because of it’s usefulness (and frankly filling a need that a naïve user would assume is core), but because it’s too sophisticated for me to rebuild myself. Something like Commander is very helpful, but that would be much easier to rebuild - in fact I use my own version that I prefer.
That all said, I agree with many other points you bring up, more editions, a better “core” way of managing community plugins (Community Links needs some love), and I hear you on the language struggles. I’ve recently moved abroad and this is a big challenge. Luckily there are small ways we can all contribute to get incrementally better, and keep this great little invention going.
