Clover13

There are automated tools that can be run against code bases to scan for vulnerable code and libraries. Reputation and trust alone are not enough when it comes to software. Developers with the best intentions can still unknowingly use something they are unaware of has an exploit (in deep dependencies, it can be something they aren't even using directly, but is included in their code base). It's simply good practice to run scans (code, infrastructure, app testing, etc) regularly to ensure security. Doesn't mean there's no risk, but it does greatly reduce it.

Chargebacks and tickets are the least of their concern. Legal issues jump right to the front of the line. Again, this could be an added reason for them to effectively exit all responsibility by closing their Marketplace. They reduce their own cost of maintaining it and eliminate their own risk (as noted in their own notes in the Provider directory).

I think that's quite a bad gap to have. With PII on the line, it's important to check for any potential vulnerabilities that could put it at risk. IPS clearly has a security and PII focus in their own code (right?), meanwhile you're saying they blindly host apps/plugins in their own Marketplace with the only requirement being not exhibiting any IP theft, while at the same time facilitating the sale of unchecked code? Why is that a good thing to not be their responsibility? Clearly, IPS is moving entirely away from any level of responsibility (IMO a case could be made they do indeed have responsibility in their current Marketplace). Now, how much of an issue this WILL be is debatable. How much of an issue it CAN be is not. Third party code is a risk and always will be. We can rely on trusted developers, which is great for those who exist already and have built up such trust. It's quite bad for new developers trying to enter the game and raise the level of competition and quality in applications. We are still taking risks using unchecked third party code. I am trusting the IPS Marketplace, reviews, etc on my own sites currently, but it certainly doesn't make me feel warm and fuzzy inside knowing it hasn't been vetted at a code/exploit/security level. It's more of a "I kinda need this functionality and sure hope nothing bad happens" and that honestly isn't a good mode of operation. I'd be curious to know what IPS has observed with their corporate clients. Yes they are built in house or by private consultants, but that doesn't mean it's immune from human error, outdated libraries, exploits, etc. Are they doing any level of suite wide testing to guarantee their own security?

The problem is, without the current IPS scan/approval process of apps/plugins, any new development is a risk. We also don't know how many iterations of scan/approval a given version of a given app had to go through to get final IPS approval, nor what those rulesets/barriers were for good practice per IPS standards. We just know the end product from the Marketplace dev. Now clients are subject to the intermediate iterations and any issues they expose. This is particularly concerning when we get into PII and any level of security risk to our sites (which we had a confidence level IPS was protecting us from with their scan/approval process).

Right, so this bodes well for well known and established devs as they have already created a foundational trust model with clients. For new devs, that's a barrier they'd have to create over time. Meanwhile, clients either have no way to validate new devs work like IPS previously did to guarantee the safety of the app/plugin. I think this greatly elevates the risk for clients and subsequently harms the potential for developers to grow the product. Hobbyist sites will suffer the most as they simply don't have the resources to invest in robust security evaluation. Perhaps another opportunity for a dev to provide some level of AppSec and InfoSec scanning of applications to lower the risk.

One potentially large gap is the validation and approval process done by IPS to guarantee the Marketplace developer's app/plugin aligned with IPS standards before it was approved for client download. How will this be managed moving forward?

v5!!! Time traveler!!! He could at least give us insight into what else is in there! 🤣

Regardless of the percentage that is actual or perceived (unless it's 0% being lost), the questions still remain. They are important questions from both a client and Marketplace developer perspective. What is the roadmap of the IPS suite and developer toolkit relative to these questions? IPS is developing the suite, the Marketplace devs are just adopting it with whatever tooling they are provided by IPS. IPS knows whether Marketplace devs will be able to achieve the same things (even if it is in a different way/method).

So regarding this assumed 80% of plugins being lost, the main questions I have are: Can similar results (i.e. a client wants X added/enhanced to any part of the suite) be achieved with whatever IPS is developing for v5? Maybe in a different way, but the same end result/solution for a client? If so, will the solutions be Marketplace sellable assets for developers? If not, how does IPS plan on addressing this clear gap in providing functionality to clients that Marketplace devs previously filled in v4? I can't imagine IPS removing the ability for devs to enhance the IPS suite in ways that IPS isn't willing to invest in doing themselves. That would be detrimental to all parties involved. And history (per the number of Marketplace assets) shows there are A LOT of assets/resources clients want and use that aren't part of the suite.

I may have missed the pre edit request but what is this type of info? AWS does have a health status history of their own but it shows no issues in this time frame https://health.aws.amazon.com/health/status

With multi-region and multi-AZ redundancy and availability promising upwards of five 9s (assuming the application is built to conform to these requirements) how exactly does this happen and AWS not know why nearly immediately, nevermind many hours later? I'm baffled by their response especially given the reliability they claim as a major selling point of not just the cloud but specifically their offerings to mitigate this even reactively. Something is tremendously off with the situation and hoping to hear some discovery, lessons learned, and mitigations from IPS as this undoubtedly impacts their own selling strengthen of their cloud solution.

I'm confused by the NOT part of YouTube, Vimeo, etc. Have you ever seen them block or throttle embedded playback? Why would they care? Their ads are embedded within the videos, no? Sure they want you to be on their site to get eyes on other videos, but I've never seen anything that would prevent one from using them as a FREE video hosting provider (in fact that's what everyone does who uses them) and sharing it in other ways whether that's on a separate website, an IPS based site, Wordpress, or whatever. What are the disadvantages you've identified with using YouTube or Vimeo for these purposes? The one that does indeed have merit is what @Chris027 alluded to regarding ad payouts, but the benefit of FREE storage and simplification/mastering of video processing and analytics may outweigh that for many. I totally understand IPS' desired approach to the video hosting solution and the set of applications available on AWS to support the desired workflow, but making it a cloud-only feature once again puts self hosted clients in a corner. This is going to be the continued nature of cloud based hosting as it will have cloud specific features available to it that self hosted does not. It puts IPS and clients between a rock and a hard place when product decisions are made that only benefit cloud clients. On top of that (and maybe the bar is lower today), doing video "well" has historically been a challenge. Is this an area that is worth IPS' development time when others have already mastered it? Again, I'm not clear on the benefits to an IPS approach, but I do see the downsides (maybe too much devil's advocate in me).

I get that side of the coin too, but you can monetize YouTube. Does IPS have video monetization built into video? I haven't seen it. You can also embed your YouTube videos into IPS and monetize around the video (literally around it), while also monetizing the video itself (within it). I've posted an enhancement request in the past, the goal isn't to direct traffic away from our IPS communities to YouTube, it is to interface with YouTube for video handling, processing, storage and browser agnosticism...and then embed that video within our IPS content automatically. When you upload a video to IPS (say in forums), leverage YouTube's API to upload it to a channel, then embed the YouTube URL where that attachment would otherwise go. This is an oversimplified workflow not accounting for asynchronous behavior and post submission updates, but it seems feasible and offers stronger benefits than IPS trying to become YouTube IMHO (unless video processing/handling/storage/presentation has become easier). Either way, video storage alone is a high cost, and YouTube frees you of that. On top of that, YouTube has strong analytics to leverage viewership, trends, etc to learn and adapt your content.

Pretty disappointing to see this proprietary cloud-only video approach. Video IS the wave and it's one of the biggest gaps to IPS. Video is HARD, so I'm baffled as to why IPS would want to incur the cost of enhancing this with a cloud-only solution and also incur the resource and storage cost for cloud customers (driving cloud pricing up in all likelihood) versus leveraging YouTube, Vimeo, etc and their APIs to make a cloud and self hosting solution that saves everyone time and money, as well as ports video handling into the hands of companies that have already mastered it.

I get it, but getting client feedback early in the planning process promotes optimal feature targeting directly tied to established client value. Otherwise you're operating in the silo of your company's opinion only, which IMO could cause you to fall short on meeting some requirements your clients actually have/need/want. Iterations are on compounding enhancements with minimizing tech debt incurred, however if you pattern a solution that couples you to your vision (without consideration of the clients'), shifting to meet additional/different requirements may prove difficult (or simply costly that could have otherwise been avoided). Just my .02, been through it in a different industry a number of times.

Good point. The Enterprise clients are the highest yielding margin, so it makes sense to prioritize their work for profitability. The use cases driving features are certainly going to be different, and those conversations could be happening in private with Enterprise clients (who are unlikely to join the community here and start posting with hobby site owners). I have seen a few pop up here and there but mostly when it's a pretty disastrous scenario for them and they want to voice it openly (having reached their tolerance threshold).

Also to add the Block Submissions is a great example of had it been shared ahead of time, you'd have received a bunch of feedback that could have influenced the design. Post initial release, in the event you receive feedback that drives high value and look to implement it, you are now in a likely higher cost of refactoring of the existing code base versus designing it to accommodate those aspects up front. Maybe easy to overcome if the code base is hyper abstracted and extensible, but at least historically I've seen a lot of references to "that's not easy to do in the current code", which again could be mitigated by a balanced transparency driven feedback loop with clients.

I definitely understand not wanting to prematurely share an initially targeted feature only to find it's not viable/possible and won't ever be done and having to deal with the fallout from clients (in which case you should be reconsidering if there is enough client interest [$$$+] there). However, when you share at least roadmap candidates (not definitive/approved) you can establish a feedback loop with active clients to garner value which drives investment and development priority. Without that, you're reliant on parsing through comments on your forum in unrelated topics or in piecemeal to try and conceptualize what may be valued by your clients (without actually tracking it well, although you could have something behind the scenes that is tracking it in some way already). Likewise without that, you could wind up investing in and developing something that you envision is high value but turns out not to be highly adopted or accepted. There's definitely a balance to be had, and it's somewhere in the middle of transparency and secrecy. Being on either polar end is likely not optimal.

F the PHP is also lit! Do you guys ever consider sharing your feature roadmap and bouncing it off the clients in a private forum/blog/whatever? Seems like there's a lot of interest in what's on the horizon, and clients being in the dark about it waiting for the surprise. How does IPS determine relative value of a feature as it relates to their clients' needs without establishing that feedback loop (PS the comments here aren't a good feedback loop)

TIL I learned Phil Hellmuth works for IPS and goes under the pseudonym of Matt

Well that's a good example @Sonya*! Kudos to @Marc Stridgen on that 10 minute response time! 🙂 Also saw @Mark H opened a ticket to track it within 30 minutes and stayed on top of the ticket all within an hour, nicely done! I think if the future support works in that responsive and cohesive manner between IPS Staff and clients, it can work out well, however there will probably be a lot of duplication (which may be unavoidable anyway and likely the situation today with tickets).

@Matt@Jordan Miller Can you walk us through a support scenario where a customer without priority support has a downed site as a result of an IPS upgrade or some other unexpected IPS behavior with corresponding error message (i.e. it isn't immediately correlated to a server resource issue or configuration change)? Old process (PRIORITY SUPPORT): Customer opens ticket with IPS and mark as highest priority (site down) Within 24 hours, IPS evaluates via ticket information and updates ticket with resolution as to what they fixed or what was identified outside the scope of their support that needs to be fixed Customer verifies issue is resolved and if not, returns to #2 and may wait up to 24 hours (usually less) for an additional followup review? If verified, customer addresses/closes the ticket. As I had priority support before, I had generally heard in a few hours from IPS when it came to critical issues and even high issues. In general support, are you saying this could be up to 3 days of waiting while your site was down? New process (NO PRIORITY SUPPORT): Customer posts in a community forum indicating their site if offline, posts corresponding error messages and related server information, and de-identifies anything specific to their business/site if they wise to remain private OR simply requests a ticket be opened to review the issue privately? Within 3 days, IPS evaluates the issue via the topic information or private ticket and updates ticket with resolution as to what they fixed or what was identified outside the scope of their support that needs to be fixed Customer verifies issue is resolved and if not, returns to #2 and may wait up to 3 days for an additional followup review? If verified, customer addresses/closes the ticket. I think the crucial aspect of support is availability and SLAs around resolving major issues that either result in the site being down or have a significant impact on its functionality. I'm not sure what IPS' position is on this that drives the increase from $200 (I believe it was $100 per 6 months) to $1250, but it feels like the sites that are hobby oriented and have small/no revenue are priced out of the priority support and may have to sit waiting for days on end for their site to get back into an acceptable operational mode. This shouldn't happen often, but I feel there should be an exception for these critical outage type support issues that mandates a faster response time even for smaller sites. Or as I noted in previous reply, maybe some kind of scaling in pricing that make priority support more affordable. IMHO, "Enterprise" (corporate) level pricing shouldn't be the same as "Small business" or "Hobby" level pricing. However, across the board we have one single pricing model (particularly impactful at the elevated support pricing). This just doesn't fit your customer base well: Easy for mid/high revenue customers (corporate, bigger businesses, high traffic sites, etc) to afford, difficult for low revenue customers to afford, and impossible for no revenue customers to afford. There simply has to be a better pricing calibration model to apply here that quite honestly gets you MORE from your Enterprise level customers and less as it tiers down to the no revenue customers. ADDENDUM: IMHO the goal of IPS should be enabling and expanding their customer base (all of it). This seems like an obvious, but the current pricing increase deviates from that objective. The more of IPS that is out there, the more visibility it achieves, the more interest it gains, the more developer incentive and recruitment there is, the more enhancements and growth are experienced. Everyone wins in that case, and the path there is finding a comfortable pricing model that offers affordability based on the type of site and its inherent revenue, as well as rewarding IPS for the product suite they are creating. There is a balance, but I don't think this is it as it's now impacted a subset of your customer base that you really should care if you lose. And honestly, where it was at before wasn't it either because IPS was getting the short end of the stick not having raised prices in 10 years.

My take so far reading through all of this... Don't lose your marketplace developers. They're a key to your success and help build your suite of products. It's a win for customers in getting more robust features, it's a win for developers in earning revenue, it's a win for your company/product suite in both revenue and features that can be adopted. It's a tough balance to be had, but I can certainly see a credit system whereas developers are credited back license costs once they contribute X (whatever X is deemed to be). This incentivizes them, and should be coupled to a quality metric to ensure they aren't just throwing something out on marketplace to get the credit but that their offering provides verifiable value to the consumers. There is a huge gap in affordability between hobby sites and business sites. To have the same pricing model apply to both only serves to make it unaffordable for hobby sites entirely. If IPS has an interest in being the forefront of online forums/CMS and gain correlating exposure, this approach is leaving hobby sites out of the equation and that is a net loss for IPS in gaining visibility which translates to future sales/adoption by new hobby/business sites (penny wise, dollar foolish). Not to mention the immediate loss and future visibility from hobby sites that migrate to another solution and popularize it will negatively impact future IPS sales/adoption. IPS needs to find a way to balance the affordability based on the target customer, but not at a reduction of features (as that inhibits marketplace incentive and adoption if that feature set can be found elsewhere) Support. You need to address the turnaround SLA for support and customers need an appropriate path to solving site critical issues within a reasonable SLA without it costing $1250 or waiting 3+ days for a resolution to take effect (note, not 3 days to respond, but 3 days to resolve it and have the site properly operational). Unquestionably, the PR around this specific case needs (and is getting) review. Moving forward IPS needs to do a far better job in broadcasting the roadmap of these changes and provide their customers the opportunity to assess them, which avoids customers being cornered ala "big bang" like we've seen here. I can see MANY are quite upset by these changes for a variety of reasons, but I also see opportunities for IPS to revise their approach for their benefit and for their customers' benefit. It's a complex situation, and there are fair arguments on both sides, however there is a big void in the balance in the current solution and it WILL unquestionably adversely affect BOTH IPS and its customers. - "cannot see the forest for the trees"

The one huge gain would be reuse of the solved issues that are common among clients. I've seen this has increased in the community over time. I just think when it comes down to a site outage, there has to be a better way to get immediate support than footing $1250 a year up front. This is particularly important when it's related to an upgrade via IPS (I know Priority support covers IPS doing the upgrades, but I think that's overkill as almost every upgrade goes smoothly *knock on wood* for us but that one time I need it, I don't want to be offline for my members for 24+ hours). Maybe a per ticket or per hour pricing model or something similar?

This is an excellent point, as those who are using Google ads are getting effectively penalized for something I don't believe is within our control. If it is, I'm not sure of how to resolve these. If you're going to increase prices, you definitely should prioritize integral parts of the suite that affect client revenue (in order to afford those price increases).