MidPoint 2019 Survey Results

This is a summary of survey that Evolveum has conducted in October-November 2019. This was the first big survey about midPoint. So far we have been happy with discussions and personal interactions with midPoint users. However, midPoint community has grown significantly during last few years. We need to rely on the community feedback to guide the development of midPoint in the right direction and lately we had some doubts whether community opinions are well represented in our decision process. Therefore, the results of this survey provide essential data for us.

The survey was quite long, so this summary is, quite understandably, not very short either. But there are interesting outcomes below.

We are more than pleased that you have very positive opinions about midPoint and Evolveum. There was a couple of neutral and negative opinions, but vast majority of opinions were positive. We deeply appreciate your trust and we will try to do our best in the future.

It looks that almost all of you are deploying midPoint because of provisioning and deprovisioning automation. Information security also seems to be a very strong factor. Identity governance and organizational structure management seems to be interesting as well.

However, it looks like cost saving is not a significant motivation for midPoint deployments. Similarly, compliance seems to be very weak motivation. And midPoint is almost never seen as "enabled" for new services.

When it comes to importance of midPoint features, the differences are less obvious. Provisioning features are, quite understandably, considered to be most important. But RBAC, REST and performance are also considered to be important. On the other hand, reporting and CLI seem to be less important to midPoint community.

XML seems to be the preferred language by almost a half of the community, even though many of you are using XML just because examples and sample configurations are in XML. However, JSON and even YAML is obviously getting some adoption. Groovy is the champion of midPoint scripting languages, used by more than a half of respondents. Python seems to be also used, but JavaScript is almost not used at all.

Integrated development environment (IDE) questions produced some very interesting results. It looks like IntelliJ IDEA is the king, used by almost half of the respondents. Eclipse and generic text editors are also used in some cases. Visual Studio is almost never used and NetBeans are not used at all.

Which means that it is perhaps no big surprise that most of you are looking favorably on our plan to switch to IntelliJ IDEA as midPoint IDE. More than a half of the community either favors that plan or is OK with it. In fact, there was only a single vote to keep Eclipse support. It looks like there is a very strong community consensus.

This means that we will move ahead with our work on* IntelliJ IDEA plugin for midPoint*. Most of you indicate upload/download and syntax highligh as most important features and we are pretty close to get those in the current plugin prototype. IntelliJ IDEA has a community edition which is an open source project, therefore IntelliJ IDEA can be platform for future midPoint Studio. Eclipse plugin for midPoint will still be there for some time. It was never officially supported. But it works and we do not plan to make any change that would break Eclipse plugin in the near future. This should give Eclipse users sufficient time to migrate to IntelliJ IDEA. But I will bring more information on that plan a bit later when we will get more data from prototyping on IntelliJ platform.

Our old resource wizard didn’t fare well in the survey. Very few respondents consider wizard to be a good tool. Many of you consider wizard to be too simple and it very obviously needs an improvement. Such feedback is not really surprising for us, we are aware of the drawbacks of the wizard almost since it was first used in practice. But it is very important for us to have this opinion confirmed by the community. The problem with the wizard is the sheer amount of settings and configuration that it needs to handle. The current GUI-based approach obviously does not work. We will have to consider options for future evolution of the wizard and/or its replacement.

We have also got a lot of suggestions and ideas in this part of the survey. I would like to thank to everybody who took the time to write them down. Some of them are really interesting. We will be discussing that in the development team during next few months.

MidPoint community has often diverse opinions on many topics about midPoint. But this is a rare case when almost everybody agrees. However, that is not very good news for us, because most of you seem to agree that midPoint troubleshooting is painful.

This is not very surprising. MidPoint is a substantial product. There is a lot of complexity and huge amount of flexibility. This makes midPoint behavior inherently hard to diagnose and troubleshoot. Everybody that has ever worked with any similar IDM system would surely agree. We have been aware of this "troubleshooting problem" since the beginning. That was the reason we have paid a lot of attention to good logging, troubleshooting documentation and so on. And according to your responses, the logging is still the most important troubleshooting mechanism for you. But it looks like the "industry standard" practices are not enough. We take this feedback very seriously and, obviously, we have to do something about it. We already have some plans and there will be small troubleshooting improvements in every midPoint release. But this is a deeper and larger problem. It has to be taken to the drawing boards and it needs to be properly planned. And that’s exactly what we’ll do.

LDAP and Active Directory are the most frequently used connectors. The number of answers indicate they are used in almost every deployment. No surprise there. A small surprise is that DatabaseTable connector seems to be popular as well. I have considered this connector to be too simplistic to be practical. But it obviously is practical. This is an important insight, because the code of the DatabaseTable connector is very old. Therefore, it would be perhaps a good idea to prioritize rework of this connector. Scripted SQL connector is slightly popular too. Which is also important to know, as we were not sure how much time we should invest into that particular connector. This survey tells us that this is probably a worthwhile investment. The other connectors are much less used. SAP connector is used a bit, UNIX connector is almost not used at all.

Remote connector server seems to be used only by a very small part of midPoint community. And in almost all the cases, it is Java remote connector server. However, those data are also very important for us. Even though the connector server is rarely used, the amount of usage is significant enough to lead us to conclusion to keep the connector server supported - and maybe even invest some time for improvements. However, it is almost certain that while Java remote connector server will get some improvements, the .NET connector server will be deprecated and it will become completely unsupported in the future.

We have got whole lot of interesting responses about ConnId connector framework. Nobody thinks the ConnId framework is perfect, which is not really surprising. Most people seem to have very mixed feelings about ConnId (including myself). You seem to like especially ConnId support for schema discovery. ConnId compatibility, simplicity and community also seem to be positive traits of ConnId framework. However, almost nobody likes the __UID__ and __NAME__ attributes in ConnId. In fact, these are even hated by some respondents. The thing that people seem to dislike most about ConnId is missing functionality. It looks like you would like to see better support for asynchronous and event-based interactions. People also hate result handlers - and I can easily understand why.

When it comes to ConnId improvements, there is one thing you seems to want more than anything else: support for complex ConnId attributes. This was the most wanted improvement, but it was also indicated as the highest priority improvement. The second thing on the ConnId wish list is improvement of ConnId schema. It is not really surprising as that goes hand-in-hand with complex attributes. We have already taken some steps as a reaction to those data and there will be some activities early next year. Stay tuned. When it comes to other ConnId improvements, almost all of the suggested options got some attention. As for priorities, they get only a very low percentage of votes.

This is the part I was really wondering about the results. However, it looks like we have a reasonable consensus in the community.

PostgreSQL is clearly the winner. It was indicated as the database that is most frequently used in midPoint deployments. You also seem to consider PostgreSQL to be the best database for midPoint - by a huge margin. I’m glad about that because after years of "database neutrality" we have made PostgreSQL the recommended database for midPoint 4.0.

When it comes to other databases, MySQL, MariaDB, Oracle and Microsoft SQL seem to be also used for midPoint deployment and the number of such deployments is not negligible. Therefore, those databases are likely to still be supported in foreseeable future. However, their usage is significantly lower than the usage of PostgreSQL. Therefore, it will be PostgreSQL that will get most of our attention.

This is confirmed by your opinion about our plan to create a special repository implementation for PostgreSQL. Most of you seem to love the idea. We do not have specific plans about this. But your opinion clearly indicates that this is the road to take.

Reporting is one of the pain points in midPoint, therefore I was really curious about your opinions in this part of the survey. But once again, there seems to be a clear consensus. It looks like nobody really likes JasperReports in midPoint. And I have to admit that this is not surprising at all.

You use midPoint reporting functionality for all kinds of purposes. Most of you seem to create reports of moderate complexity. Almost half of you need some kind of printable report output, but it looks like it can be something very simple, such as printable HTML. However, the most popular output format seems to be CSV and most of you seem to favour with processing of midPoint data in a spreadsheet processor.

Out suggestion to replace Jasper Reports with native reporting was received in a very positive way. There were some (very legitimate) concerns about continuity and we are not taking those lightly. Now it is quite clear that JasperReports is not the way forward. However, we will not remove Jasper without having a suitable replacement. Therefore, Jasper will still stay for a while. We will get back to the drawing board and we will need to design a better solution. That will take a while, but I strongly believe that it is worth it.

Our removal of embedded workflow engine in midPoint 4.0 was received in a mildly positive way, with most of the respondent choosing the "This remains to be seen" option. This is quite understandable, as this was a very bold decision and it perhaps needs some time to sink in.

The question about integration with external workflow engines received some attention. And Camunda seems to be a preferred choice. However, the interest for this features was relatively low. We think that integration with an external workflow engine will be necessary, sooner or later. But it is likely to be later than sooner - unless there is a subscriber to raise the priority.

ITSM integration is a similar case. There is some interest and several respondents indicated that this feature is essential - and of course, this feature is here to stay. However, there was not enough interest to motivate further development of this feature. At least not yet.

It looks like midPoint community is comfortable with both graphical user interface (GUI) and command-line interface (CLI). There are very few extreme opinions preferring GUI or CLI for everything. It looks like the preferred approach is "GUI for business, CLI for system" - and that is exactly the approach that we are going to follow.

You seem to like MidPoint CLI in general, but it obviously still needs some improvement. Our Ninja tool was received in a positive way. However, many people are not aware of its existence. It looks like our documentation needs some updating.

The Midpoint-CLI in Python that was created by Yannick Kirschhoffer was also received in a very positive way. Yannick and I have already discussed the possibility of bundling this tool with midPoint distribution. The results of this survey suggest that we should increase priority of this task.

MidPoint REST service seems to be generally liked by the community. Vast majority of you are either happy with the service or you miss just a few pieces that are not that important. The interesting thing is that almost everybody is using the REST service in some way.

The opinions are not that good when it comes to documentation of the REST service. Obviously, there is still quite some room for improvement.

MidPoint has started with a SOAP service, long before REST took over the world. The SOAP service is deprecated in midPoint 4.0 and it will be eventually removed. Vast majority of you consider this to be a good move. There were some voices to keep SOAP for some time or provide an ability to create custom SOAP services. Even though there was just a couple of such voices, but they were quite important (e.g. because of midPoint subscription). Therefore we will be doing both: we will be giving SOAP users some time and we will make sure that we have an alternative way to create custom SOAP services.

When it comes to client libraries for midPoint services, Python seems to be very popular choice, followed with CLI tool and Java. Other languages received just a negligible share of votes. Luckily, there is already the Midpoint-CLI in Python and the Python client library is part of that project. And we already have Java client library. Speaking of which, the Java client got mildly positive reception, but we are aware that it still needs some improvements.

Identity governance and compliance is a way for midPoint development for the future. There are two features that seem to be high on your wishlists in this area: Simulations and lifecycle. You would like to see a feature that can simulate complex changes to evaluate their impact. You would also want better support for identity lifecycle. These two seem to be of approximately the same importance to you. Other features seem to be less important: RBAC models, case management and remediation. Then there is a set of low-priority features: compliance, identity intelligence, role mining and risk management.

Questions about midPoint auditing were more-or-less confirming what we already suspected. MidPoint was originally designed as a pure IDM system. As well-designed IDM system, midPoint keeps very detailed audit trails. But we had no ambition to re-implement SIEM or data warehouse systems, therefore midPoint was designed with only the minimal abilities to process audit records. However, it looks like majority of you keep audit trails in midPoint. Approximately a third of the responses indicated a presence of a data pump or a SIEM system, however this does not seem to be a dominant approach. These answers provide a lot of food for our thoughts and it looks like we will need to get back to the drawing board on this one.

MidPoint has a Stand-Alone Deployment for several years already - and the stand-alone deployment is generally preferred by the community. However, many people still deploy midPoint into Tomcat container. This is now a real minority, but it is still enough of a crowd to keep this option supported. At least for some time.

When it comes to features that are important to you, stability and flexibility/configurability is often mentioned. MidPoint is a flexible system that can be adapted to a variety of use-cases and you seem to like that. We are more than aware of it and we do not plan to limit the flexibility of midPoint in any unnecessary way.

You seem to enjoy many things about midPoint. But what came as a surprise to me was that Metaroles were mentioned quite often. Don’t get me wrong, metaroles are super-exciting to me and also to most of our team. I just though that we are quite alone in that geeky obsession. It looks like opposite is the truth and metaroles seem to be quite popular.

There is similar diversity in things that you hate about midPoint. Many things are mentioned. But the difficulty of configuration and troubleshooting seems to be a leitmotif in many of your comments.

You seem to really like midPoint! Vast majority of you think that midPoint is a good product. And you generally consider midPoint to be better that other IDM systems! While there is significant survivorship bias here (you take this survey because you think that midPoint is better), the results of this part of survey are still like music to my ears. Thank you so much for all your opinions, encouragement and support!

Most of you consider performance and scalability of midPoint to be important or even critical. These are very important data for us. MidPoint was designed as an IDM system. Given the requirements for IDM systems at the time when midPoint project started, performance and scalability was not high on our list. However, that is changing during last few years and we are investing a lot of effort to midPoint performance and scalability. Your answers indicate that current midPoint performance is acceptable for majority of midPoint deployments. Yet, the level of importance you indicate here suggests that perhaps we need to make even more substantial performance improvements in the future. This question is an excellent example of midPoint community influencing the priorities of the development team.

Note: Nobody indicated that midPoint is too fast for their deployment. Surprising, isn’t it?

There is no big surprise that you consider open source character of midPoint to be important. We have already knew that. What we wanted to learn from this questions is how much difference open source makes. And even though we have expected quite a lot, the answer was still a bit of a surprise. More than 40% of you would not even consider a system that is not open source. In addition to that, almost 50% of you consider open source to be a major advantage. We had never any doubts that going "full open source" is the right path to take. But those numbers are still much more than we have expected.

Software products are not frozen in time. They change and evolve. But every change is also a risk that something breaks. Therefore, I have expected that there will be two groups of users: featurists that want new features and stabilitarians that prefer smooth-running system. But it looks like this is not the case for midPoint. Most of you prefer a balanced approach: you can tolerate some troubles in exchange of new features. There are almost no extreme featurists or stabilitarians. Most of you seem to be somewhere in the middle.

This also applies to upgrades, also this is significantly shifted toward the stabilitarian side. You generally prefer easy upgrades. Which is quite understandable. However, it is slightly surprising that you are willing to upgrade quite often. More than 70% of respondents are willing to upgrade at least once a year. It looks like we have got our Long-Term Support program quite right.

There is no big surprise when it comes to our policy regarding security fixes, namely the fact that we are fixing security issues for everybody, subscriber or not. Vast majority of you share our opinion that this is the only right way to do it.

It looks like you generally like the way how we communicate. Most of you would like to see more informal technical communication such as description of new features, suggestions, HOWTOs. Informal business and developer information is also wanted. This is very much in accord with the things that we are going already. There is also a small desire for more formal business communication. We will try to adapt to that as well.

When it comes to communication channels, the situation is more complex. There seems to be some kind of love-and-hate relationship with the mailing list. Most people like it, or at least tolerate it. But there is a significant portion of respondents who do no like it. The desire for more communication on github/gitlab is small. But there is some desire to use StackOverflow or a similar site. Therefore, we might want to explore the possibilities there. Our blog seems to be quite popular and there is desire for more posts. Let’s see what we can do here. On the other hand, there is almost no interest in social network and newsletter.

The interesting thing is that many of you are willing to share your story with the community in a form of a case study. However, most of you still need more time to get ahead with your deployment. Sharing deployment experiences in midPoint community can be very helpful, therefore this is definitely something that we will be looking into.

You seem to like midPoint book quite a lot! The book seems to be going exactly the right way. The only problem seems to be that it is not yet there. Most of you would like to see it finished. So do I! If only there were more days that I could dedicate to writing.

We could not resist to add a few business questions to the survey. Even engineers need to eat, therefore business and technology are very hard to separate. But I’ll try to provide just a very short summary of the business side of the survey: Although many of you did not answer the business questions, it looks like pricing of midPoint services is quite right. Most of you are happy with industry standard levels of service and do not need anything luxurious. There seems to be some confusion about the scope of our services and that is something that we definitely have to look into. Overall, the data that you have provided are very useful and they will guide the development of our services in the future.

Interesting data came from information about midPoint deployments. It looks like typical midPoint deployment has 10 000 - 100 000 identities, but it looks the deployment range goes all the way from almost zero to millions. When it comes to connectors, typical deployment seems to have 10-50 connectors. In this case there seems to be upper limit. No response indicated more than 200 connectors.

Provisioning, livesync, entitlements and organizational structure seem to be the most frequently used midPoint features. But it looks like all midPoint features are well used in the deployments. There does not seem to be any useless major feature.

This survey was quite long one. Looking back I appreciate (and admire) the time that you have dedicated to filling out this survey. The data that the survey provided are essential to guide the future of midPoint development and Evolveum business. Many of the results were not really surprising, but it is essential to have confirmation of our opinions in the community. MidPoint community is quite large and discussions only get a limited amount of data. Therefore, thank to all of the respondents once again. You have used your power to influence future of midPoint!

P.S. The survey was done by using LimeSurvey, which is also open source product. I can more than recommend using LimeSurvey.