MKPs
This is another topic where we think its moving into the wrong direction.
Tribe29 has announced at the last conference that they plan to free up more resources for core development and therefore customers should go to the business partners
for check development in the future. We understand the intention behind it and don’t think it’s a bad idea in principle. However, we think that MKPs are the wrong way to achieve this goal longterm:
developer guidelines
Many details are still missing in the guidelines for coding check plug-ins, such as example the whole inventory part. For an experienced developer who reads the git commits
and can reverse engineer the code, this may work. But for an ordinary customer/programmer, it remains a challenge even after attending your course “Programming extensions for Checkmk”. In many places the
check developers are dependent on the way Tribe29 implemented general functions (example cluster), but you don’t get support if they don’t work as expected or when important functions are missing.
Partners who develop the same things, without knowing from each other’s (same without bug tracking, some of you customers opening and reporting the same bug)
As now being forced to go to a partner to get new checks, its also clear that most of the customers not having 2-3 partners and its also clear that partners not talking about everything between each other’s.
That’s leading to the point that partners developing the same check for different customers at the same time and at least one of them is “wasting” time. Sure, from partner perspectives everything is fine, as written above, more revenue which is good. But for the community its bad and customers its bad.
- the time from one partner could be used to develop something else, not existing
- it seems that not all partners releasing there MKPs (different reasons and also understandable), but again bad for the community and CMK it self as its not available to the public
Not all customers have a partner they trust and not all partners have the resources or are willing to accept new customers only to develop new checks.
When different customers talk to different partners, you end up with a lot of individual solutions fitting only the need of one customer and no common development.
MKPs and CMK Updates
As we had many many MKPs send in the past by you, for example because it was possible to extract that feature we could*t wait another 9 month for, we know also very well about the problems MKPs can come with and over time WILL bring.
.
-
code changes
If Tribe29 no longer has the checks under its wings, you can no longer evaluate the impact of your changes and you lose the connection to your customers and what is really needed by them.
It will also be extremely burdensome for all your customers to test all MKPs before implementing any patch release because you no longer can ensure that everting works as expected.
This will costs some of your customers monthes of preperation before a major release and even a lot of extra time before a patch release.
And again, the number of MKPs supposed to grow in the future due to the changes regarding feature requests -
loosing track if MKP still needed
Sometimes you receive a patch by MKP, but its still not implemented in the next checkmk patch release - you need to track it somehow.
Same goes for Major releases where you might have received a workaround for the actual release, for whatever reason but you have no clue if its implemented or still needed.
Means again, huge amount of our time, and some of yours as well in terms of communication and testing. The same applies to the workaround MKPs we received sometime for the current release.
We as Customer never know if it will still work properly or as expected when the next major is released, because you didn’t have it on your screen when working on the new release and there seems to be no
process about notifying any of your customers you developed and send MKPs if something changed related to it. -
CMK Support
As a paying Enterprise Customer, it’s important for us that we have full support for everything including the QA. We are counting on you to make sure that everything works after a new release, and if not, that you take care of it.
Who is taking over the support for all the MKPs which are not working after an upgrade? -
3 party developers and Enterprise Customers
This is related to point 3.
For many its not allowed to install 3 party “addons”. The reasons are mostly because of lack of support. So if you are installing 30 MKPs, from 20 different people
you can imagine where this ends up in terms of support and major upgrades or “developer guidelines” changing.
Same with other, “self-written” code/projects, people move on, get a different job and not maintaining their stuff anymore. most of the time anyhow, written in there freetime -
MKPs vs. CMK
Sometimes it starts with MKPs and by coincidence, CMK develops the same and actually having similar and even the same names.
Problems
5.1. Same name, but not same features
Speaking from experience from us and some of our customers, the problem is that that often parameters/details are missing so on the one hand site its clear you want to use whats fully supported by CMK, but on the other hand you cant wait for another half a year or even longer, IF your feature requests will be developed to add the missing “features”
5.2. amount of time to spend
For merging/rework your own checks.
Dont get me wrong, the idea of MKPs in general is great - really! Its a way where you can include the community and its possible to easily extend checkmk, with simple things.
BUT I believe a majority of people would love to have more of them included and supported by CMK, for many reasons written above. It’s clear that it’s a lot of extra work and nearly
impossible to add and support all. On the other hand, it would also create more jobs? We had the discussion about code quality in the past. Proper developer skills (from users perspective) and
proper developer guidelines will for sure help to reduce a certain amount of time to align with the main branch. We did this with you in the past and you’ve you’ve been surprised about the code quality and even adapted some of the unifytesting ideas our developer had.
Maybe there is a way to meet in the middle. Let’s say, picking 1-3 MKPs per month to include in the main release?
Just braindumping - could be top voted (but please not again like the feature portal) or top downloaded for example. That would decline the amount of MKPs by 12+ per year.
And if you add a better way for partners as well, who should anyhow know better about code and development guidelines, then we could add a huge amount of, at least, new checks and get the same dynamics back, which made CMK in the first place that great!
And with the right tools, partners could work directly on bug related tickets, opened up by customers not related to them. Of course this would imply that partners also have an interest on bug fixing and further developing their checks. (could be written in new contracts) But I think at least some, from what to see on github could be falling into that category.
One idea could be to certify Partners as CMK Code Developer?
- goal for Partners to get the status
- more revenue for partners
- ensured they have the knowledge to fully develope under your guidelines which cuts down your time involved (presupposed there are developer guidlines without any gap)
And its not only partners. A huge boost for the success of CMK been the first years where from every corner of the internet, bits and pieces been added. Family - Everyone contributed
here and there to CMK and made it this huge conglomeration of checks - which was great!
We fully understand that in terms of QA and maintaining code it’s a huge problem, but there are ways to handle and deal with it. Maybe you even might not know about, but chances are high, some of your customers with more then 20k employees faced it already.