Umbraco 8 has been out a year now and it's really shaping up to be a great version. I think Umbraco can now rightly shout about it being a great release.

I've been having the following conversation with several people and I thought it would be easier to just put my thoughts down to share. This blog is going to be mainly focused on the next steps for Umbraco which is moving to .net Core and hopefully a new back office and what effects I believe it might have on the product, some good/some bad.

As a mountain biker one of the best bits of advice I was ever given was to look further down the trail when going fast. There is no point looking at that big pothole/rock right in front of you as there isn’t enough time to react or position the bike to avoid it. So lift your head up and look further ahead to give you more time to pick the best line, the smoother line, the faster line and sometimes the fun line with a nice jump in it :)

So .net framework (as we now have to call the artist formerly known as just .net) is the framework Umbraco is run on is now considered “fully baked” by Microsoft. Its done, no more development will come its way. Microsoft have for some years now been working on their next play thing that is similar but also very different. I’ve not really had my finger on the pulse of .net Core mainly as it seemed like shifting sand, every alpha or beta release that came out seemed to have too many breaking changes so keeping up seemed like a fools errand. So I never understood the calls from some people in Umbraco land for the last 4+ years asking “what about .net Core?” at every opportunity it just seems like a waste of effort, kind of liking asking “yeah but when are we going to colonise Mars?” when we haven’t even been back to the moon yet.

However all of a sudden, like a rock on the bike trail that I didn’t see, .net Core is here with a jolt and it feels a little like I was sleeping on the job. Net Core seems to be everywhere and it is the new craze causing some new problems:

• New developers don’t want to learn the old “legacy” .net framework so this limits attracting new talent.

• Cloud hosting providers are leaning towards containers which .net Core supports well (so these will get cheaper) over virtual servers which we can expect to get more pricey on “legacy” hardware I guess.

• New OSS projects that add functionality or code we could reuse are less likely to be written in .net framework as its lifespan is considered to not be as long as .net Core.

So the writing is on the wall for long term web site happiness, it is time for us developers to start to retool and get reading up on .net Core. It is also time for our favourite CMS to come up with a plan on how to go about getting Umbraco running on .net Core. The .net Core event horizon looms closer waiting to suck us all in.

Thankfully this isn’t something that Umbraco has just started to think about, they have been doing some work on this for a few years on and off. It was the reason that V8 was first proposed, a stepping stone to getting to .net Core. It removed a lot of older code and technology that no longer had to be supported (or couldn’t be in .net Core) so the surface area of what needed porting/touching was greatly reduced. However it was more than just the “tidy up” version as it introduced some new features and breaking changes which is what made it a major release. HQ have also setup a new team (it’s all about teams at the minute at HQ) who are over-seeing some of the work/discussions on how to actually go about getting Umbraco on .net Core in a reasonable timeframe and with community involvement. From now on I’ll refer to the .net Core version of Umbraco as vCore for ease.

I’m told the aim is to have something out for vCore by the end of the year, I think that it is more likely to roll on until March 2021 sort of time which would be more likely as it gives more time to get it done yet still released before Code Garden the annual Umbraco Conference in May (marketing baby!). Even then I would expect it to be more like 2022 before it's battle ready. Once released to no doubt much whooping and cheering we will enter a funny time, a fork in the road if you will. There will be two versions of “the same” Umbraco alive at once...effectively offering the same functionality (so far anyway) and giving the community a choice as to which to go for. This could pose some interesting problems/discussions/times for us all.

V7 sites are still around (and are still being made for fresh sites) and V8 is likely to stick around too. The problems ironically will likely come of the old timers, the “white middle age men who know it all”, the ones that run the IT departments/hosting of our clients and want to stick to what they know, the ones that want to sign off on known tech and the developers who want to work in a framework they can be productive in as they have used it for 15 years, the ones that hire those developers and know the budget doesn’t allow for much venturing into the unknown.

For instance which version do you start a new site on? The tried and tested .net framework that you know well, the team is quick to work with or the new .net Core one that you are still pretty green on and the code base itself is green too. We've all got to dip our toes in the water some time, but is this the project to do it on? As usual it depends on the site, how long is it going to be alive, size of it, etc. But for each site we will now have to make that choice.

This isn’t new of course, we’ve had to do this for the last year between V7 and V8. But they offer different features with V8 having variants, nucache, content apps, etc but they are the same tech (well framework) underneath. V7 isn’t actively developed anymore (more on this in another blog post) so that sort of makes the case stronger for the switch to V8 especially now it has had a year out in the wild to mature. So V8 would be the right choice for future proofing if you had to build a site today but even then...it depends.

This won’t be the case for vCore though, HQ will have to keep developing V8 .net framework version AND the .net Core version at the same time as not everyone is wanting to or even can jump ship to vCore overnight. That is going to add some headaches to the mix. Increased development overhead, a fragmenting of training, how to manage bugs and pull requests, documentation confusion. I’m already getting this when I’m searching for anything to do with .net in general seems to return Core stuff first these days or makes the assumption I’m using it while not always making it clear. Then we've got training materials that will need creating and all that jazz, plus...what about Umbraco Cloud? I can’t see them launching without having it up and running on cloud. This might be an easy thing to do or not but it still needs doing (probably needing some new container magic?) and then supporting which means developers not working on other CMS related things.

Of course in the future everyone will eventually have to make the switch to vCore but in the short to middle term what do we do? For a while we will live in a world where there are 2 versions of Umbraco that are functionally the same but running on different frameworks. This assumes of course that they are functionally the same and from what I’ve read that is the initial aim. They will diverge at some point of course, HQ will have to switch all new developments to vCore (it is after all the future) but they probably don’t want to do that too soon until the market is ready for it when its robust enough, there’s enough support out there, everyone is trained up on it. This is the curse of a well established project I guess, you come with some baggage/user base and you take time to react/move. You can’t just start a fresh as a new .net Core CMS, you have to do it in a way to bring your audience/market/customers/users along with you if you want to keep your traction.

HQ could drop V8 development pretty quick if they wanted to but it would be self harm to do it only 2 years after it came out and forcing everyone's hand to either make the switch or just stick with V8 in whatever final state it is in (as it would likely go into security patch only mode like V7). Lots of us have migrated sites to V8 to ensure a continuity of features and fixes, we can’t keep getting that signed off every 2 years if we want to keep the clients nor can Umbraco keep forcing that if they want Umbraco to be on the short list with those clients, after all “if we are rebuilding anyway we might as well look around” is a fear all us agency folks have in the back of our minds when “rebuilds” are mentioned.

Package developers will once again have to rework their packages (some still haven't for V8 yet) to work on vCore which is all done in spare time that they might not have. I’d like to think that with the new packages team (told you it is all about teams) we won’t have the lack of packages in vCore that we had when V8 launched so the gap between the two will hopefully be narrow.

So let’s assume we now have something like 2.5 versions of Umbraco alive and well with V7 in security patches only mod (that’s the 0.5 bit btw), V8 and vCore have the same features mostly and this is the current expected holding pattern. Oddly we won’t have gained a single new feature to differentiate between the versions from all that work, just paved the way to move forward.

Looking further down the trail though we have some more hiccups that are coming along the way, more potholes and rocks to avoid or hit square on.

There is the new block editor that is meant to be getting worked on, it will be developed within the existing back office which is still on AngularJS. This is shared between both V8 and .net Core so it can be rolled out to each, woot! That will be ready and rolled out before the year is out I suspect so before vCore itself is done.

But about that back office...it's getting mighty long in the tooth, 7+ years its been running and added to. It’s been nearly 2 years exactly since LINK I wrote about the idea that we should be thinking about, planning and doing some ground work/tidying up to ready for a rebuild of the back office to a new tech stack. Sadly in that time nothing of substance has been done, promised or resolved as HQ have been working on other things like finishing and releasing V8, Headless, Cloud and now working on .net Core. At some point though a choice is going to have to be made about the back office ideally after a good audit has been done of what is there and what is actually still needed. All the arguments used to encourage the shift/work to vCore can be repeated about the back office (its old tech, no one wants to learn it, difficult to find developers, it’s a dead framework who’s official end of life is about a year away). The rebuild is not a choice we can keep pushing back. Marketing wise nothing shouts legacy enterprise like shouting about being on the latest framework while also being run on an obsolete one.

So if time is being spent on the new block editor I hope its done in such a way that its easy to port to a new framework otherwise its work that will have to be redone and then we will again have multiple versions of it to support and document.

Let’s assume that at some point the back office needs a rebuild or Umbraco risks just falling behind too far. Which version of Umbraco do you build it on and when?

I’m told HQ are keen to get vCore out quickly (but not rushed). They also don’t want to roll it out with a new back office as part of that initial release as that is thought to be too much for them or the community to cope with, vCore is a big enough job as it is. So where and when does it get done? Do we try to roll it out on both V8 AND .net Core? This would seem fair to both versions given their youth but also a technical headache and would also be a breaking change for both versions...we would in effect now have 4.5 active versions of Umbraco out there!

That doesn’t sound sustainable. So do we have to pick a version? Yes we probably do. Logically that version would have to be vCore as its the one with the best future ahead of it. That causes a problem though as no doubt since vCore got released some sites will have been made on it already and will include the old back office...so we now have 3.5 different versions of Umbraco situation and we’ve just killed off the upgrade path for 2.5 of them. Additionally those package developers now have to rework their packages AGAIN to work with the new back office in vCore version with the new back office. This is getting painful.

So how can we avoid that? I think we’ve got three options I can think of:

• Easy: Punt it into the future, kick the can down the road. Repeat “there is nothing wrong with the back office, it works for now” a lot, live with it as it is and hope I stop writing blog posts about it. Maybe it can be rolled out in the vCore version in 4+ years time and hope we don’t lose market share in the meantime.

• Bold: Decide that the back office should be included as part of the initial vCore release and together it just becomes a new thing as vNext. That would make it attractive and look like a complete “upgrade” of the tech and worth the jump and could open up the door to lots of new features. Package developers only have to rewrite one more time and then its “done” for a while. But this does cause some headaches and would likely delay the release of vCore (and so miss Code Garden!). Plus if its a totally new stack is it really Umbraco? Would it be worth looking around at other options if it is that different?

• Tricky: Come up with a way to roll out the back office to both. How about we separate out the back office from the rest of Umbraco? API’s would be the only way to get the back office to talk to the Umbraco data layer itself. The existing back office we change to use the new API layer (its mostly done like this now anyway). We do this sooner rather than later so that it’s in the vCore version before it launches. Then we can work on the back office “out of band” almost as a separate project. Create a whole new back office that talks to a consistent API. Then give you a feature toggle to opt in (or install via nuget or npm or the package manager) to the new back office on existing V8 sites (sorry V7 users, its not going to work that far back) and it would be included as default on vCore. Packages could cause some headaches unless we are smart with some compatibility layers of some sort or upfront about upgrading them so they work before its release. By separating it we can work on it at our own pace while getting it to work with both versions. This also makes it possible for everyone and their dog to get carried away making their own version of the back office in the framework of their choice over a weekend (Matt, I will be expecting a VueJS version done and dusted by Monday morning) and hopefully end the “framework choice wars”, everyone wins. It’s going to take some juggling though.

Being pragmatic I’d be quite understanding of any of these options coming out as the winner, they are all valid, but I think they all have different knock on effects to the project.

Personally I fear that the first one will win if we aren’t active to stop it, we simply do nothing for now and slowly start to shrink the user base rather than grow it (worst case obviously). The second is probably the safest choice even though it’s marked as “bold”, it would lose some fans but at least it gets the pain out the way (again) in one go and its ground that we’ve trod before. The last one gives us options at the cost of some work up front, it’s probably the one I’d like to explore the most and potentially keeps all users happy and making the project look like it’s giving a bright planned future rather than just playing catch up.

So that is the landscape further up the trail that I predict. Another big version might cause more headaches than we want if we aren't careful with the timings of the developments and releases. How we avoid these bumps in the road I don’t really know, I’ve just looked down the trail and spotted them. I’d love to discuss the back office and the ideas I have for it in more depth but that will have to wait for another blog post (or take a look at the latest issue from Nathan Woulfe github.com/umbraco/Umbraco-CMS/issues/7718).

In the meantime I think we have a greater need. That of needing some people to regularly focus on the back office and have it in the front of their minds rather than it be something we mutter about at meet ups but don’t actually do anything about. Or something we add yet more features to without thinking about if we should clean it up a bit first. In short I think we need a Back Office Team assembling with an internal champion (or two) from HQ to fight for it from the inside. It is not a problem that will fix itself and it is a big enough issue to need input from the community and HQ if anything is going to get resolved with it. Trouble is how do you even start a team? And how do you pick who to put on it? It will also need a lot of managing and a lot of work, ideally very small “achievable in the lunch break” kind of work, but it is doable as long as we don’t just end up arguing about which framework to use.

Together we can look further down the trail, pick the best line, the smoothest line, the fastest line, the fun line with a nice jump on it :)