Is it time for Jamf Pro to have a Snow Leopard moment?

[sdagley]

For anyone that doesn't get the reference, the focus of Mac OS X Snow Leopard (as macOS was spelled back then) was performance and stability rather than new features.

There are over 300 open Product Issues in Jamf Pro. Some for critical issues like DEP enrollment not working properly in a cluster, and some for annoyances like being unable to sort a Change Management Log display. I think it's time for Jamf to follow Apple's Snow Leopard focus, and spend at least one release cycle not adding new features to Jamf Pro, but fixing and cleaning up the existing ones. If you share that sentiment please vote up this Feature Request: Let's have a Snow Leopard release cycle (or two) for Jamf Pro

[tlarkin]

To give jamf some credit here, they are in fact doing this. Previously, especially at large scale, the jamf database would get bloated rather easily. This resulted in some large fleets having to prune database tables consistently. jamf has made efforts to improve this a lot over the past year. While, jamf does have flaws, as all software does, they are making some improvements.

The biggest issues are those PIs and bugs that have been open for 1+ years and not addressed, design issues that do not get streamlined, and so forth. That typically forces an engineer down another path. For example, jamf patch is just too much tech debt and hard to automate with out a high engineering effort. The first gotcha with jamf patch is, that if you want to control it or if you want to manage third party apps (or in-house apps), you must stand up your own patch feed server and use the community one. While, I have used it, and it does work, and you can build some automation around it, it is so much easier to abandon jamf patch and just setup AutoPKG JSS Importer some static code that is policy and smart group driven. However, you cannot stop there since there are things like software version checking and the fact that all inventory is server based and not local state based, means you can loop through uninstall and install on client systems that may upgrade before your automation takes place. So, once you get that far, you end up in a situation where you start to look at making choices of keep on bolting on that code to make something more functional, or just cut your tech debt out and look at FOSS tools like Munki to integrate. Once you go down this path, you likely won't switch back, unless jamf really beats what you have built. For me, right now jamf would have to completely change patch for me to consider it. It is not that it is the most horrible thing in the world, it is that my goal for packaging and software deployment is an engineering first perspective, meaning if I cannot easily automate and maintain my automation, then I am going to look at tools that allow me to do so.

I think jamf should bring back the customer council and expand it. I think they still have it, but I think it should be expanded upon. Certain customers, who are willing to participate and give feedback should have the opportunity to join in on these things and supply data to jamf to get these improvements built. jamf won't be able to please everyone nor will they be able to build anything that is for all their customers. This is why I think a lot of what needs to happen is more abstraction and integration options to build out what you need for your Org. I think this should be done more than implement feature foo, because in the end Org 1 and Org 2 will have different needs, and different use cases.

I also think jamf needs to build in more data collection. I think a lot of what is asked, expected, and thought to be "gold standards," are really false positives or just best guesses given anecdotal data sets. A lot of people want to put tons of stock into the "App Store Experience," and invest heavily into a Self Service model as an example. Now, that I am collecting more and more policy data, I am finding out my automation is not only running sometimes 10 times more than self service, is that now people use self service even less. I am not 100% sure why yet (still digging into that data), but my best guess is that people are busy, they don't want to click a dozen buttons in an app to do stuff, and they would prefer I.T. just automate it for them, so they don't have to think about it. If we could easily get this data, we could know these things and have more visibility into our efforts and the return on investment they yield. I think allowing more data to be shipped to a data tool, can be highly valuable for anyone and everyone, and this very much includes jamf.

Also, having better data collection and being able to have more visibility into these things allows the admins and engineers to validate their work and efforts more. If you find out people are constantly reinstalling O365 via self service you might more accurately infer that there is an issue, especially if you deploy O365 default on all macOS devices. Workflows matter as well, and if you see higher failure rates in some flows, then maybe you need to rethink or redesign it.

Thanks for coming to my Ted Talk, also sorry for hijacking your post. :-D