What needs to be improved in Red Hat Fuse is on the development side because when you use it for development purposes, it lacks a user interface compared to what MuleSoft has, so it's a bit difficult for users. There are good and bad points in Red Hat Fuse, but mostly the solution has good points.

There's also another similar product in the market: IB Information Builder which is a product that has recently been taken over by TIBCO, and TIBCO has a similar integration product. It's similar to MuleSoft because both TIBCO and MuleSoft have user interfaces on the development side, so if I have to define a route where one particular flow should follow a particular way, for example, service should be consumed from this point, and these are my source and target, I'd be able to do those on MuleSoft and TIBCO more easily, but not in Red Hat Fuse. The development features of Red Hat Fuse need improvement, but I feel the team has done a lot in the latest version, and now Red Hat Fuse will be removed from the market and the focus will be on OpenShift purely. There is also a new product called Red Hat Integration and there will be a movement towards Docker because a major drawback of Red Hat Fuse is that it doesn't have small containers, so every time, you'll need dedicated virtual machines on top of those you're running, but now, it seems Kubernetes will be used.

In the past, in the older version of Red Hat Fuse, you have a full container and the whole application is deployed on containers one, two, and three, so you don't have the option of splitting. It's similar to microservices, but now those things are taken care of in the latest version, and the older version of Red Hat Fuse will come to an end.

An additional feature I'd like to see in Red Hat Fuse is a direct integration, particularly with CI/CD, which can help reduce overhead because you won't need to have a big DevOps team for building, preparation, and deployment. Dockers and microservices support are also additional features I'd like to see in the solution. More successful deployments will also help make Red Hat Fuse better.

My company doesn't have any experience with other messaging tools, so it's difficult to mention what areas could be improved in Red Hat Fuse, but it could be pricing because I find it expensive.

An additional feature I'd like to see in the next release of Red Hat Fuse is a better UI to control all configurations better.

The current solution depends heavily on fabric profiles, which we want to disconnect from and be more containerized. This is why we are implementing Kubernetes, whereas now, it is Karaf-based.

The initial setup and configuration could be more straightforward.

Red Hat is not easy to learn. You can learn it but you sometimes need external expertise to implement solutions.

Red Hat has the latest, cutting-edge features, but the learning curve is difficult due to its configurations. For the client, it has a good cost, but for developers, it is a bit of a grind.

If a new company is doing Red Hat Fuse development for the first time, there is a bit of a learning curve. They will need to spend time on getting some things ready. 

As its learning curve is quite steep, developer dependency will always be there in the case of a Red Hat Fuse development. This should be improved for developers. There should be some built-in connectors so the grind of the developer can be reduced. 

Developers for Red Hat Fuse are scarce all over the world and the community is not well-built. That can be a problem for big companies.

I haven't experienced the online part of Red Hat Fuse. Red Hat Fuse doesn't have a lot of administrative control like other applications. Using administrative control, the operational user can view the process flow, do improvisation, and analyze where the problem is.

Then, they can show it in a real-time, graphical representation. On top of that, they can do additions and generate reports. These are really valuable for business or IT ops purposes that the solution must take care of.

As a bundle thing, it goes well.

The stability of the solution is an area with a shortcoming that needs to be improved.

We are still trying to learn so much from it. So, I am looking for my improvement since it is always one step ahead of me. So, yeah, I'm trying to learn so much from it.

It is always a surprise to get new features, but it is not something on top of my head where I could suggest a new feature.

For improvement, they can consider the way we collaborate with other applications, if that is something feasible, considering the way it has provided us stand-alone support and continuous like CI/CD support. So, if there is something on which the whole team can collaborate onto. So, when we merge our tools, we don't have to go to Azure services since we can just have everything under one umbrella. Right now, in Red Hat Fuse, everything is not available under one umbrella. So, I'm sure it must be something very huge and big to ask, but if there is something that can be done to bring everything under one umbrella, then it would be great.

What could be improved in Red Hat Fuse is the deployment process because it's still very heavy. It's containerized, but now with Spring Boot and other microservices-related containers, deployment is still very heavy. Red Hat Fuse still has room for improvement in terms of becoming more containerized and more oriented.

As we work with containers, it takes about a minute or so. Red Hat Fuse is much faster than the traditional web application server, but it's much slower than the latest modern technologies such as Spring Boot, so there could still be some improvement there.

Red Hat Fuse also doesn't have a UI navigator and a UI-based workforce filter, and though those are all external, they could help improve Red Hat Fuse.

An additional feature we'd like to see in the next release of Red Hat Fuse is the UI resource wizard that would allow us to easily drag and drop tools. They should have a UI-based wizard where we can just drag and drop connectors, connect them, and do the graphics. We can always do coding for deeper requirements, but having a no-code, local setup in Red Hat Fuse, where we can drag, drop and build our workflows, connection instances, and services, and also design an entire workflow would be a good addition to the solution.

Red Hat Fuse doesn't have UI really. It's a package that is used for development purposes. The UI is coming in place during the development process, you can create a skeleton of your orchestration when using the solution, and it'll generate your code. So basically we can have an ID with a plugin for the solution, and this will generate a skeleton or a simple flow. But of course, it's not enough for real sophisticated implementations, however, it works as a starter. A visualization plugin feature would improve the solution. Perhaps it is less connected to the solution itself, but to another tool that is connected to Red Hat Fuse.

There is definitely a bit of a learning curve. We're still on the learning curve now and still trying to figure things out. We might be understaffed to really take advantage of the solution. 

The documentation for Fuse can be improved because, while it is very detailed and extensive, it is not too intuitive for someone that has to deliver some kind of troubleshooting services. In particular, for installation, re-installation, or upgrades, I find that the documentation can be improved.

In some cases, resource consumption is an issue. It depends, of course, on the amount of bandwidth, memory, CPU processing power, et cetera, that you have. But time and again, we require more resources. An improvement in this area would be desirable.

The testing part, specifically when running it in the cloud, could be improved. It's a little bit complex, especially considering its cloud nature. 

Apache Camel has many components that are challenging as well. For example, Apache Camel K is difficult to test because they are dedicated to cloud infrastructure.

In the future, I would like to see more up-to-date documentation and examples from Red Hat Fuse. It is fairly new, so there is not a lot of information on the web about it right now.

Some of the official Red Hat documentation could be improved a little bit. It was a little difficult to find exactly what I was looking for. I was eventually able to find it. It's there, but it was hard to find. 

It might help if, in the documentation, there were a comments section or some kind of community input. I might read a page of documentation and not fully understand everything, or it might not quite answer the question I had. If there were a section associated with it where people could discuss the same topic, that might be helpful because somebody else might have already asked the question that I had.

We deployed Fuse on JBoss EAP and the user interface could be improved with some type of dashboarding. That would be useful because, when we got it set up, there wasn't anything that we could readily just turn on to monitor its performance. It turned out there actually was, and I eventually found it, but it wasn't quite handy. It would have been really great if, as part of deploying Fuse on JBoss EAP, we could easily get to measuring performance and have the ability to monitor things, without having to dive into configuration or to deploy other stuff.

When we access the container, it crashes and then we have to kill that container, restart, and log in again. The solution should work on preventing this. 

In the next release, I'd like more stability and more security overall.

The monitoring experience should be better. I would like the ability to monitor the flows and be able to retrieve runtime information about their execution. The UI could also be improved.

We have not found we are missing any features. 

While it's a good platform, the pricing is a bit high.

The web tools need to be updated.

The main issue with Red Hat Fuse is the outdated and scattered documentation.

Currently, the main point of concern for us is how flexible it is to cater to different requirements. It should be more flexible.

The pricing model could be adjusted. The price should be lower.

Our clients would like to see the user interface improved so that it is more user-friendly.