Perch v4 license model

  • Hello,


    On Perch's 10th anniversary Perch v4 was announced. The announcement also mentioned how the current license model has become unsustainable and that a new license model was proposed:


    To make sure we can dedicate developer time to supporting and updating the software, Perch 4 will be a charged upgrade and will include 12 months of support and updates. After those 12 months, if you wish to continue to receive updates and support, you’ll need to renew that contract at an additional cost, just as you’d renew your web hosting.


    In case it is not clear, to paraphrase:

    1. You purchase a v4 license
    2. You get support and updates for 12 months
    3. After 12 months, if you still want updates for this license, you can pay for another 12 months worth of updates. If you don't need the updates, you can keep using the license with the last Perch version that was released within the 12 months in (2).


    The announcement post discusses the reasons the current license model has become unsustainable, one of which is the fact that many older licenses are being reused for newer projects.


    With the new proposed model you would most likely pay for an additional 12 months worth of updates for a license if:

    1. the project requires on-going development/maintenance and you want to keep using the latest version of Perch
    2. you want to re-use an old license with a much newer Perch version (e.g. a project build on v4.1 (latest at the time). The project no longer exists a year later and you want to re-use the same license but with v4.5 which got released 12 months after v4.1)


    A lot of the Perchology Slack group members thought this was reasonable, but we recently found out that the proposed model got a lot of push back:


    Quote

    What about Perch 4?

    When we announced the upcoming Perch 4, one of the significant changes we outlined was to the way Perch is licensed. Since then we've had a lot of feedback from our customers that a subscription model isn't something that will fly with their clients. We're listening, of course, and are currently investigating ways to move forward with Perch 4.



    So I created this thread for us customers to discuss the proposed license model here publicly.

  • I personally think it would be a reasonable change. It is not a model where you have to pay to keep using the software. You can use the software forever. You just don't get free updates forever. There are a number of software companies that started using a similar pricing model including Sketch and Craft CMS.


    Based on what I read on the forum, many don't update Perch regularly. If it wasn't for PHP 7, many would still be running versions that predates v2.8.34. So the proposed license model may not even affect all customers.



    I understand that some customers who run agencies may have a very large number of licenses so paying for updates per license may be a big turn off. Perhaps additional options could be provided:

    • (A) Pay updates per license (suitable for those who have a small number of licenses and/or those that do not need to get updates for all licenses). You don't have to pay if you don't want the updates.
    • (B) Pay a single fixed subscription fee to get standard Perch updates for all the licenses in your account. Use (A) for your Runway licenses.
    • (C) Pay a single fixed subscription fee to get standard Perch and Runway updates for all licenses in your account.



    This way if you are running an agency and have a lot of licenses, you would probably go for (B) or (C). It would be another cost of running the agency (just like you pay for an accounting software, backups, project management tools, etc).


    With (B) and (C) the agency is responsible for the updates cost, not their clients. After all, Perch targets the developers and companies that build sites with Perch, not the end client. We are the ones that benefit the most. If you run an agency and rely on Perch to deliver your work, this model seems reasonable in my opinion.

  • I'm happy with the one-off cost and yearly update fee/sub model; as long as it means that product development can be resumed and online support is fairly responsive, rather than solely relying on the community to answer questions.


    When more support is required then a yearly dev-to-dev type subscription could also be introduced.

  • There is so much support for Perch, everyone (in the Slack group) wants it to succeed and grow. The current buy once and receive free support/updates forever obviously isn't sustainable. I welcome a move to an annual license update.


    However, it really needs to be backed up with an increase in development for both Perch and Perch Runway. There's a lot of uncertainty in the Slack group regarding the future of Perch CMS. Ongoing development seems to be in maintenance mode, a look at the update history page isn't very encouraging.


    The Perch 4 announcement earlier this year, followed by radio silence until this week has only made that uncertainty worse.


    Can we expect a return to the 'glory days' of Perch back in 2015/16/17 when development was very active and there was a real buzz about Perch?

  • I wonder if the so called subscription (but isn’t a subscription ) model will actually sustain development any more than the current model. If you don’t actually have to pay yearly and the vast majority of people don’t seem to actually update regularly what incentive do they have to fork out the extra to update? I would bet it wouldn’t make a huge increase in revenues.


    If you create a monthly(yearly ... whatever) subscription plan for those larger agencies, is that really going to bring in more than the regular licenses themselves? I think it would need to be a decent amount per month to make it more profitable.


    I’d like to see someone (smarter than I am) put together some quick numbers to forcast revenue over the short, mid and long term vs maintaining the standard model.

  • If you don’t actually have to pay yearly and the vast majority of people don’t seem to actually update regularly what incentive do they have to fork out the extra to update?


    I don't know whether the vast majority don't update regularly. What we see on the forum could be a small number of Perch customers.


    Also even the developers that care about keeping Perch up to date for their clients are likely not to regularly update it for all clients if they are not paid to maintain the site. So if freelancers/agencies only update Perch when they are paid to do so (e.g. maintenance as part of a retainer), they can take the updates cost into account when pricing their services.


    If a developer/agency does not get paid to maintain Perch sites (and hence don't need the updates), then the proposed license only affect them in the way that they cannot re-use the same license (with the latest version) over and over again.



    I would bet it wouldn’t make a huge increase in revenues.


    Since the proposed model would prevent someone from re-using the same license for a new project every x years for free (assuming they want the latest version whenever they start a new project), customers may potentially pay to get updates for an old license to avoid paying the full price for a new license.


    So we may see:

    • customers paying for new licenses
    • customers paying for updates because their clients pay them to maintain the site
    • customers paying for updates because they want to re-use licenses (with latest version) on new projects


    That would be better than what's happening right now. Whether that would meet their goals in terms of revenue is for Drew/Rachel to study. If they ultimately decide to keep updates free, then at the very least they can do something to prevent the free reassignment of older licenses like ex-jedi suggested.

  • I'd like to echo everyone's sentiment here – I'll be more than happy to pay to renew a license every year to get the latest version – BUT, like Stephen says, I'd want assurances that support and update rates are going to improve. 1 update in the whole of 2019 is not okay in my opinion, especially when looking at competitors who are pulling further and further ahead.


    I'm now choosing to work with other platforms out of concern for Perch's future but would love a reason to use Perch again more frequently.


    Also, just a little bit of transparency goes a long way. You will lose more customers by staying silent, instead of just saying: "sorry folks, it'll be another 6 months, but here's a sneak peak of a new feature". We all work in an industry where it's commonplace for anticipated dates to slip but poor communication is far far worse.


    Perch is a great CMS already and has bags of potential; and with a bit of TLC from the core team and the right tools for the community to build some amazing apps, it could start making ground on other popular CMS's in no time!


    If this is seen by Drew or Rachel, then please consider a short reply acknowledging this thread (or even just a tiny blog post), it would certainly go a long way to reassure a portion of the Perch community.


    Fingers crossed!

  • I might be in the minority, but I spent a great deal of time researching CMS systems about 3 years ago because I wanted to find one solution that would work for my small practice. After spending literally days doing cost/ benefit and pros / cons I went with Perch. I haven't been disappointed. Even today I am anxiously awaiting Version 4 but I'm not disappointed with Version 3 as it does everything I need it too.


    Is it perfect? No it isn't but for the price I pay and my clients it is just what I need. I am a user of regular Perch and not Runway so that is my frame of reference. I have made adjustments over the years and spent time learning the way Perch works. I have customized it to fit my clients and I have heard nothing but great reviews from my clients.


    I fully understand the need for Perch to change it's model so it can be more sustainable. Also, I want to thank Drew and Rachel for their work in putting together a great product.