Lots of great discussion this weekend! I've changed the subject, since we've changed our subject and this may help with future searches on the ML archives.
No doubt. I had above conversation with a customer who I convinced to by > PE the very same day. I explained it's advantages, they decided to buy > it. But not before being assured that there is no hidden lock in. They > Of course there's lock in. You can't click a button and go from Puppet OSS to Chef OSS; it's no different with enterprise versions. I'm sorry, but I find this to be a really awkward concern to face. Even when you talk about something known for lock-in, like Oracle or AWS, it's about getting the data out. Some very well publicized stories about companies migrating away from both and it's never easy. Lock in is perhaps the most specious concern people have with software. > themselves. But they wanted to make sure that Puppet was serious about > being "open". By that time they have already been long time Puppet > Is their concern about being able to contribute to it or even fork? I suspect that's what most lock in concerns are really based on. > Btw, once there was "Live Management" a thing I tried to use that > feature as a USP to sell PE. Honestly, I never had a serious use case > for it. Some manager liked it, didn't work for tech people. Seen from > today, I'm happy that it didn't work, as I would have felt very bad > being forced to tell them that that promoted feature was going to be > deprecated. > Agreed. This looked great on the surface. However, every action was owned by the live management user which essentially made it unusable in any regulated environment. I hope they find a way to fix that and bring it back, but until then, it's absolutely best that it is not present at all. > without buying PE. Someone who comes from a Ruby-based Puppet world > already feels locked out by the Server being Java/Clojure, Facter a > binary and everything AIO-packaged. That's what they only know from > non-OSS vendors. Non of this is a problem on it's own, but together... > one might get mixed feelings. > This is curious to me. Most I hear are happy to not have to worry about passenger/apache/nginx changes and just let the vendor worry about that. And ruby versions? That's a circle of hell on its own that no-one wants to dive into (someone earlier mentioned getting things to work with ruby 1.8.7, but on those distros its possible to lack support for SNI and TLS 1.2, which are significant problems in 2016). I live mostly on the Ops side, however, so may color my experiences far differently than others. > versions. But because I see that there is quite some uncertainty amongst > Puppet users regarding the direction OSS Puppet might take. And in my > believes this is absolutely related to what Alex brought up. Unrequited > love, feeling betrayed, not sure how to name it. > Uncertainty is bad. But I do sympathize with Eric - how to alleviate that concern among users who don't engage with Puppet in the dozen different ways available to them already? Rob Nelson rnels...@gmail.com -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAC76iT88_-deGf5eNLRZqHdvAQtuHOQwzKC_%3D52LX5ctUz01-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
