Time-based licensing like WP add-ons. Monthly or yearly recurrent fee for the developers that maintain them. I think this would bring in more developers seeking greater riches.

In my point of view if there is a installation with multiple sites each site is a own instance and if somebody has purchased add-on's and / or themes he needs a license for each site.

Suggestion 1:
Furthermore it would be nice if another license model would be introduced. In addition to the standard license model, this license model would have permanent support. But the users also have to renewal their licenses every year.
Billing could be processed automatically via credit card debit or PayPal subscriptions.
This not only makes sense from a developer's point of view. I also think this would be useful for the financial development of the core.
I think some users who value support + service would make use of this offer.

Suggestion 2:
3-pack: In addition to the "Buy 5" I would suggest a "Buy 3" introduce. Why? Because three licenses make the most sense in my eyes. Almost every web project has a development, a staging and a production environment.

Suggestion 3:
My last suggestion would be some sort of billing system for support on concrete5.org. Namely that one can settle extra support hours directly over concrete5. Either in the form of prepaid packages or with a timer app and post paid payment.

I think all 3 suggestions would increase incoming and this is good for all 3rd party vendors like me and to support further development of the core :)

Posts I made on the referenced threads:

Copied fromhttps://www.concrete5.org/developers/pro-accounts/community-leaders-...

Seehttps://github.com/concrete5/concrete5/issues/6516...
Enable Multi-Site Functionality in Core
Q. "Will this handle marketplace licensing across multiple sites?"
A. "The marketplace license will cover a single concrete5 installation, which could host multiple sites."

(the below is cross posted from github)

I am concerned about the addon licensing w.r.t multisite. Licensing needs to be per site, and that needs to be baked in to multisite. The marketplace is already in decline. A service business providing c5 sites taking advantage of multisite could further undermine the viability of the marketplace.

For example, if multisite is developed for true one install flexibility, a service provider business or marketing agency could sell c5 sites on the back of a single c5 installation with multisite and host 10,000 or more actual sites within it.

That is great for c5, but awful for the 5 theme developers who sell one copy each so the hosting business can give their 10,000 customers a choice of theme. It would be even worse for the one gallery developer whose gallery addon is purchased, or the developer of an eCommerce addon who is paid one license fee for 10,000 shops.

I am not against multisite. The concept is great. But the idea of one addon or theme license being stretched to an unlimited number of sites really sucks.






Copied fromhttps://www.concrete5.org/developers/pro-accounts/community-leaders-...

Firstly, thanks for responding to our concerns and doing so in detail. It's good that we have been heard.

The single site vs Developer/unlimited split covers both extremes, but seems to miss out the middle ground.

Just speculating here:

- 1 * license as per current marketplace
- 5 * license, as per current marketplace
- 1 * multisite license for up to 5 site multisite (less than 5 * license above)
- 1 * multisite license for up to 10 site multisite
- 1 * multisite license for up to 20 site multisite
.... some other steps for multisites getting bigger, up to an unlimited multisite.
- Developer/unlimited license (would need to include a clause prohibiting resale as anything other than part of an integration)

All these steps would be a hassle to create/input, so rather than have developers create them, have some standard formulae that automatically create the stepped multisite prices.

However, I can already see a gap in my speculative thinking. It won't work for a multisite install with 100 sites that only wants an addon or theme for one of those sites.



Copied fromhttps://www.concrete5.org/developers/pro-accounts/community-leaders-...

Hostco point (1) could be the most important thing on this thread. That concrete5.org is looking dated and is built on an even more outdated core version does nothing to advertise c5. Existing makeovers of small areas compounds the problem rather than solving it.

A complete makeover on a v8+ core would do a lot for credibility. But care would be needed to ensure continuity of data. Repeating the continuity mistakes made when documentation.concrete5.org was created, but on a larger scale, would be a disaster. We cant afford to loose:
- Marketplace content and sales info (including the legacy marketplace)
- Private messages
- Forum history
- Bug tracking

For the forums, we need to reverse the dilution of information and community that multiple channels (forums, slack, stackoverflow,.... etc) has caused. The amount of useful technical content has atrophied over the last few years. A few years ago I was firmly in favour of continuity. Now I would use the upgrade as a chance to implement a modern forum/chat/knowledge system that will serve the purpose of forum, slack and stackoverflow all-in-one. The old forum content could be turned into a searchable archive. The new 'Community' part could become a separate site on a subdomain like documentation is.

Bug tracker could use the GitHub api, so we no longer have the confusing and poorly defined split between bugs (that get largely ignored) and GitHub issues. Issues on GitHub and bug tracker posts would just be separate views of the same data.

The marketplace could be also be split into a subdomain, or more likely 2 sub-sites, with the intention of making as much of the marketplace as possible into a community maintained project (hence 2 sub-sites, to protect the confidentiality of some marketplace data that is confidential to the developer).

With all this partitioning and splitting of sites, continuity of navigation, searching, user accounts and things like private messages between the various sub-sites becomes a key technical requirement. Get the continuity wrong, and it becomes an almighty mess that everyone will hate. The grouping should be for convenience of engineering, not for the inconvenience of everyone who uses the sites. As far as users are concerned, it should behave as a single integrated site. The API work going into v9 could be key to this

(The split of documentation.concrete5.org is a good example of getting it wrong - dispersed and largely ignored comments, lack of searchability, loss of author information, second login that is not sticky. Howto's used to have regular community input and high readership. Now they are lost in the background and largely ignored by both writers and readers. )




Copied fromhttps://www.concrete5.org/community/forums/themes/lack-of-loyalty-wi...

With the forums, in an attempt to direct interaction to appropriate channels such as Slack, Stackoverflow, Github (and other channels that have now atrophied), communication has been dispersed and diluted. (Search back and you will find a lot more about that). Unfortunately such dilution compounds the problem of many average developers being disenfranchised by the raising of the technical fence that came with 5.7 and continued with v8.

Many marketplace addons and themes are spin-offs from customer projects, where the project has covered development for a specific application and the developer then puts in a bit more work to generalise and toughen up for the marketplace.

With all the ongoing API changes, the work needed to get an addon or theme into the marketplace has increased, both for developers and reviewers. We need to ensure any new submission conforms to the latest, or it will break sooner. The work needed to keep an addon current with the latest c5 core has also increased as the core changes. The easy forward compatibility of c5.4/5.5/5.6 has long gone. Us developers complained about breaking core changes between c5.4 and c5.5 back then, but didn't realise how trivial they were in comparison to what happens regularly now.

Save for a few big sellers, marketplace sales volumes are small compared to what they were a few years ago, and even back then only a few items actually covered the developers' costs. With most addons and themes, if they were developed just for the marketplace, both price and sales volume would need to be an order of magnitude higher. But would 10 times as many sites pay $150 for an image slider?

So these days doing anything for the marketplace requires a lot of community dedication, or a naivety about making your money back. There are also developers that place items in the marketplace for convenience of supporting their own sites rather than any expectation of sales (but they still need to meet marketplace requirements).

Inevitably, over time, core changes and changes of personal circumstance, some developers just cant afford to keep on subsidising the web sites of others, which is what 90% of marketplace development ends up as. Hence the abandoned addons and themes.

Once something is abandoned, we have a choice. Take it out of the marketplace, and some existing users will be upset by its disappearance. Leave it in the marketplace, and it will attract new users who then become disappointed. The current best idea is to leave it in the marketplace, but remove its approval status and mark it black/bleeding edge. So its there, but buyers are warned.

We can only do that if those buying/downloading addons that have become buggy and are unsupported make it well known. Leave 1* reviews. Post on the forums. PM a member of the PRB. If any addon or theme gets enough bad reports, we can do something about it. But only if users let us know!




Copied fromhttps://www.concrete5.org/community/forums/themes/lack-of-loyalty-wi...

Free and supported is good, as long as the developer can afford to continue support.

When a developer has 'gone away', I am not convinced free and unsupported is a good solution.

Free -> more will use it. Unsupported -> greater volume of issues as the core evolves, and all those 'free' users run into them. Hence free & unsupported could actually increase the number of sites having issues with marketplace addons/themes.




Copied fromhttps://www.concrete5.org/community/forums/themes/lack-of-loyalty-wi...

While there are numerous improvements that could be made to help customers and sellers in the marketplace, the fundamental approach of the marketplace is about right.

With respect to this thread, implement some indicator of when the developer was last active, average response time, days of no-response support requests, aggregated across all of a developer's addons.

Display the result in a banner across the top of every addon/theme. Either as data, or turned into a 'developer support rating' that ranges from Excellent....OK, but sometimes a bit slow....Unsupported.

If an individual addon has too many pending support requests, automatically make it unapproved/black.

I've readed in linked articles mentions like another license models could scare the users, since they use on concrete5 because it is open source.
Another fear was that if you introduce another license model or make the licenses too expensive, people tend to pay a developer and developes themes/addons themselfs.

I do not agree with both points. Finally, Concrete5 remains open source and anyone who wants to can continue to use the core system for free. Elementary is available and many core blocks too.

And also the fear that people develop themselves I can not share. I often develop custom themes for agencies by myself. Meanwhile, I have a maintenance contract with many customers and get a monthly fee for support, care and development (adaptation to updates). In a nutshell, if there is some update security, it is not done with a one time fee. And I think customers know that too. Meanwhile, the trend of almost all online products and services is becoming a subscription model. And I personally sympathize with it. Be it Photoshop, which I use monthly, phpstorm, Netflix
, maxdome the list is long and I like to pay every euro/Dollar because I get something for my money.

The concrete5 merit as a marketplace developer is just as I currently find only a nice extra income and if you go and allow customers to buy x pages with a purchase, there will be even fewer developers for concrete5 to develop because the sales will go even further down.

I think with a new license model you could counteract here.

1) I think every page must have a valid license.
2) through a marketplace api, the core system must check whether the license for page x is allowed to use. If not, the execution of the extension should be prevented.
3) conceivable would be an exclusive license as envato for x.000, - Euro

Is this thread meant for discussion about the marketplace in general, or the licensing model in particular?

A lot of ideas are bundled here: https://github.com/a3020/concrete5-ideas... It has a section about the licensing model too.

2 things.

First I agree that it would be better if licensing was on a yearly basis. Meaning after a year, unless the license is renewed, updates don't come in freely anymore. Of course, they can keep using the add-on.

The second thing is the support fee. We can set a price for support after the first month but it seems to be the best-kept secret ever. Couldn't we have that option on the package's marketplace page: Buy with extra support or not. Like that they can add support directly to their cart when they buy.

I know a first-time buyer doesn't necessarily know if they need support or not right away but this would have 2 benefits:
1- they would be aware that there is a paid support option that they can buy later on if needed
2- it would give experienced users a positive signal that we have their back.

Of course with the number of devs on the marketplace that do not answer support requests, that might be an open door to mayhem.

Licenses for add-ons and themes need to remain on a per domain basis regardless of multi site functionality. This is pretty much industry standard I believe? Its most fair to the developer to say the least. There needs to be a multi site license option that's price depends on the amount of domains you intend to use it with. 3 domains, 5 domains, 10 domains, unlimited domains, etc.

Agree with @mnakalay about stopping free forever updates. Free forever support appears to have been kind of addressed but I do not believe it lead to many "extended support sales" if any at all and it certainly did not stop customers from seeking free support sometimes years after the fact. Customers should always have access to the product they purchased as a download, but the versions they have access to should be limited to the version that was available when their support/updates expires.

The bottom line is we need a reason for paid updates. Right now customers have no reason to pay for an update. Why would they when its available forever for free?

Agree again with @mnakalay. Extended support needs to be available on the marketplace page so it can be added to the cart along with the purchase of the add-on/theme at the same time. This appears to be pretty industry standard these days on other successful marketplaces. Most of the sales for extended support/updates will come at the time of purchase, not after the fact. I mean this must be the case right? The way we have it now does not work at all.

I agree with @mnakalay

Could we have the possibility to add a custom text on top of the package's support page? That would be helpful.

Some other features i would love to have if the marketplace will be relaunched...

In-App-Purchases: I would love a feature like this. So users could buy extra functionality if required and get the add-on/theme with basic functionality for a cheaper price or even for free. Btw.: This could be used to offer free trials too.

Other payout methods then PayPal. Even PayPal is a cool thing i do pay a lot of fees there. One fee to be able to receive the money and another one for the currency exchange and last but not least i get the worst exchange rate.

Stats: I would like to have the possibility to see page views, conversion rates, referrals, search terms etc. for my add-ons/themes on concrete5.org.

Bumping this back ton the top. Multisite is now in the core on GitHub.https://github.com/concrete5/concrete5/pull/7751...
With multisite soon to go live, we need some action on management of multisite licensing.

Had a nice chat with Andy on just this last week.
Lots of good thoughts on marketplace strategies/improvements - but the key to multisite:

Seems that the current install license should be apply-able to a single "Sitelette" in multi-site.
Seems that we need a new "unlimited" license if you want to run that code on ALL the sitelette's in a multi-site install.
Seems like other places (evanto) have done well with a "unlimited" license where you can simply pay a one time large fee and then own your copy of the code. Might be appealing for someone running multi-site, might be appealing for a dev shop just running a lot of sites and being willing to spend a couple of grand on a theme they now own, might be appealing for a dev here to get a big check on occasion instead of lots of little ones.

Along with revisiting the support expectations (not infinite) and introducing a simpler way to sell a feature improvement upgrade - this would probably satisfy all the needs.

Great thing with the "Unlimited License". But without a license check method this will be definitely exploited. I think that because a lot of users buy one license and use it for X projects yet because the install the add-ons by FTP and maybe don't know about the marketplace policy or don't want to know. Whatever.

What is required in addition to the unlimited license type is a license check in the core for marketplace items. In the attachment is a flow chart with some ideas of an possible license check.

I'd be the first to agree that we could do a better job of having a simpler on-boarding and simpler/more convenient purchase & installation flow. We've got a lot of the basic infrastructure in place with the in-site shopping you can do from your dashboard already. If the concern is "hey this can be kinda complex for someone to understand and use, we could make some UX improvements and see some great success" I'm in total agreement.

I'd also totally agree that any system we make, some percentage of people will abuse. A small percentage will abuse it on purpose. A larger percentage will abuse it by accident. If open source has taught me anything, it's "there's someone out there for every idea."

Where I get concerned is designing the solution with a focus towards that small percentage of abusers. I believe we should focus on making a convenient shopping experience for the majority of people who are just trying to build a website (or websites) and not screw anyone over as they go. Changing the package install process to die if we can't match your package handle to a record at concrete5.org seems like a feature designed entirely to be punitive, and I can imagine any number of scenarios where it will get in the way for someone we're trying to support. What if my home-brew package shares a package name with something in the marketplace? What if my install can't connect to the marketplace? etc.

Given that none of this code is compiled, the platform is open source, and even in your hypothetical you're describing someone savvy enough to be FTPing packages around manually vs. our automated marketplace install - I'm curious to why you don't think that nefarious actor won't just comment out the code required to avoid this marketplace check you've outlined?

Again, totally acknowledge there's lots of improvements we could make to simplify the experience for a customer trying to do the right thing. I'm just not really bought into A) any stats that show a large percentage of people are doing what you suggest, and B) the belief that any development efforts we put into systems to keep it from happening will be a good ROI for any of us.

Proof: NetFlix vs. Torrents - most people will pay for convenience:
https://pbs.twimg.com/media/D4sq0z9WkAEjo2t.jpg...

Unfortunately, I do not see this that as euphoric as you.

Pirated copies have often made the company bankrupt in the past.

If I Take a look myself: For more than three years now, I've been putting a lot of heart and soul in the development of concrete5 add-ons. And of course I would like to be able to live on it someday. To earn at least such an income so that I can cover my basic costs with it. This is difficult, because concrete5 has a small community in compare to WordPress for exmaple. But it gets even harder when there is absolutely no copy protection and the license model can be easily bypassed.

And I'm a relatively "new developer". There are old dogs like JohnThefish who have been active for many years. I also bet he would not mind a better extra income from concrete5.

You put so much love in, so much time, you always adapt your work to the latest core versions and give support. All this costs time. Time that is missing for other projects and unfortunately you can not live alone on air and love. Most of us live in civilized countries. Countries where you have a high cost of living.

Nice and good that concrete5 is open-source. I think that's great too. But that does not mean that the whole marketplace must share the open source mentality for the add-ons.

I think the Netflix comparison is good in one aspect: Netflix has a monthly license model. That would be a great thing too. The trend is everywhere to monthly / yearly subscriptions. I think that's justifiable if people want support and updates. phpStorm has solved it well with a fallback license if you do not renew the yearly subscription.

Only a stricter licensing model can increase revenue, which creates incentives for software developers and for you it has a positive side effect. After all, I think there is a 30% commission that goes into the further development of the core. That's why I do not understand why this topic is always so small talked?

Of course you can comment out lines of code. This is cracking and this is illegal. But you can crack every software. What we can do is to make the copy protection more complex. For example After uploading the files in the marketplace, the files can be compiled or encrypted or or or. There are many possibilities in theory. But the will has to be there. As long as opinions like mine are not taken seriously, something will never change. And that leads in the long run to the fact that less and less developers are in the mood to develop concrete5, which means that the extensions get smaller and smaller, which ultimately leads to the fact that concrete5 is becoming more and more unattractive to users.

What I do like is time-limited support and access to free upgrades. After XX time, no more upgrades, no more support, and no more ability to review (to prevent review blackmail). If sites want the latest, they refresh their license.

Aggree with payed updates/support. What do you think Would be better in addition to the multi site feature? A exclusive License? And what do you think about License check?

Fabian,

You've got the CEO of the company chatting with you on a forum on a sunny Saturday morning. I'm not sure what else we can do to prove that any "opinion is taken seriously" at concrete5. Of course, I also completely agree with you that all our marketplace developers put in a lot of hard work, and that they should all be rewarded more handsomely for their efforts.

Where you lose me is "Only a stricter licensing model can increase revenue."

I think that increasing our total market share is much more likely to increase revenue for everyone.

I also agree with JohntheFish that there are some edges to our shopping/support experience that if cleaned up might dramatically increase revenue and reduce workload for the marketplace developers today.

Those are two problem/solution sets I can choose to spend our time and resources on which could both increase revenue for everyone. _Alternatively_ we can choose to spend our time and resources on making deliberate license abuse harder to do. I'm sure we can come up with more solutions there, and I'm not telling you it never happens. I just question the amount it really happens and the ROI of focusing on it vs. these other things.

We have explored this issue in depth back in 2012-13 when a very active marketplace developer was frustrated about loss. We found their experience to be more anecdotal than systemic. There was one customer who seemed to have moved a set of licenses around on an _awful_ lot of project pages while opening support requests. We sent them a PM, offered a special deal to do the right thing, and eventually ended up disabling their purchases. This was one customer of many thousands of sales for that developer. When we added up those hypothetical sales, and we added in refunds (which were also a big point of contention at the time) we still ended up with a loss rate in the very low single digits.

I want to make digital communication easy and good.
I am also a businessman.
If I thought we were leaving huge money on the table by not having a stronger DRM/License enforcement model, and that were the main problem in our way, I'd go after that. I don't have any data telling me it is.

Today the data I do have points me towards these problems as having the best ROI as we try to achieve our goals:

1) On-boarding is punky. SimpleSites/trials convert poorly. The infrastructure is there but the polish & support is not.

2) SaaS is (I agree) the future/present. How we offer that in a meaningful way with an ecosystem of 3rd party developers is an interesting challenge. Right now I'm looking towards Jira Cloud vs. Jira Server as a success story there. I think its hard for us because concrete5 sites can get pretty complex pretty fast, and avoiding the "it's actually that other dev's fault" challenge with support on a SaaS model will be difficult. Still, I agree there's huge ROI if we can get this right though.

3) The marketplace search and checkout could be a lot better. Paypal sucks. The whole experience just needs some attention it hasn't had enough of in years.

4) Support is draining and our customers are generally treated very very well by marketplace developers. I'd love to make it easier for this to be more lucrative for devs, particularly if it might also make it easier for site owners. Some ability to issue free updates over time is important to us for basic security reasons, but there should be a better ability for a developer to make some upgrade money off of a major version improvement as well.

5) Our marketplace doesn't completely represent the ecosystem of what is happening around concrete5. It's interesting because generally 'marketplace' in the states means a open air pavilion of independent vendors doing their own transactions (think bizarre). However our online experience is much more like a single 'store' where all purchases go through us and customers have the expectation of unified service & support. Ie: we say we're a mall, but we act like a Nordstroms IN the mall.

This is becoming more and more problematic because while I'm eager to sell add-ons and themes here, I'm also eager to give Community Store the credit/attention it's due. I completely get why Ryan wouldn't want to be on the hook to provide support through the marketplace today.

I think this undercuts the larger project in many ways. Community Store is a well tested quality ecommerce solution that frankly looks far superior to what we sold in our own ecommerce addon for legacy concrete5. Still people ask me if we're ever going to have a ecommerce addon for v8, because concrete5.org does a poor job of connecting them to that very viable, and free, solution.

More ecommerce sites out there would mean more customers buying other add-ons and themes as well.
We just stuck a fully functioning digital asset management system for free in Github ourselves. You'd never know it from the marketplace.

6) Multi-site is coming out. Call it v9 or v8.6 - it's not coming out until we get a solution we like in place for marketplace licenses. What I described earlier (single site/sitelett vs. unlimited) seems like a good solution for the problem to us.

We're imagining a hypothetical business that sells industry vertical websites. Maybe they want to buy individual themes for individual sitelettes they manage out of a single multi-site concrete5 install. No reason to force them to buy an expensive license if they're really going to use the theme on one sitelett. Additionally maybe they want to have some blocks that all the sites in their network use. Think some link list builder, or a image gallery of some type. They might recognize that spending $3,000 once instead of $30 * however many sitelettes and other installs they have out there is a good idea. They might also decide they use/love some theme so much it makes sense to just buy it so they can fork the code and run with it. Both models make sense, so we want to support them both thoughtfully.

That's the stuff that's in my head today, that's the stuff that the team at PortlandLabs is worried about.

Making copy protection more complex is not something I've seen as part of a successful open source strategy. Typically it's all about offering support on top of stuff that is by in large gettable / solveable elsewhere. Perhaps I'm missing something, I'm certainly open to learning something new or seeing the world in a different way.

I also appreciate that very much that you take the time for reading.

Of course it makes most sense to spend time and resources in a way that makes them much profitable as possible. I agree with you absolutely in this point. Personally, I would focus on introducing a subscription model. Just as everyone here really wishes when I scroll through the thread. Time limited updates and time limited support.

I'll go back to the numbers from your example: $ 30 per page / $ 3000 for the exclusive license. That's 100 times. A really high sum, where even agencies think twice, whether you should spend the amount for the respective extension or not. And if there is not at least a basic copy protection available, most users will most likely misuse the single license as an exclusive license. This is my personal opinion. I can not prove this assumption, but I can look back at my current experience. I've seen many times that customers who bought my extensions did not properly license them. This has then become e.g. turned off when I gave support to them and check the sites.

As for the intentional license abuse: It is always a cat and mouse game, between the bad and the good guys. When there comes out a new copy protection, it will be definitly cracked. These are things we can never change. No matter what we use for techniques. The code is anyway available to the end user on the computer / server. No matter if compiled, ciphered or raw. But I think a really basic license check is easy to implement. I have written a module in the past which actually does exactly that. It's more proof-of-concept than ready to be integrated into the core, but I've developed this within one day. So this is not an ract science or uneconomical to implement. A minimal check does not stop the Bad-Guys, but those who accidentally licensed wrongly.

A few general words: If no one pays for movies, movies will not be produced in the future. If no music is purchased or legally streamed, the artist will no longer be able to produce music in the future, and if no software is legally purchased, the developer will no longer be able to develop software in the future. Thats the way it is.

With all due respect, but concrete5 just isn't the big player (yet) to be able to "live on marketplace sales". I've come to accept that, although I had the thought that it could be a potential good sales platform. The CMS just has to grow much more to be able to do that. I just hope that the 30% you're talking about doesn't go into the core itself, but into promoting the CMS instead and being able to attract more users of the CMS and eventually get more money towards concrete5 AND the developers selling stuff. All for a "monthly/yearly fee" too, although it's hard to divide the money to developers if it's an [xx] amount per website.

I guess the user count more or less is stagnating and we need some good promotion (and some absolutely fantastic website + videos/graphics) to get the user count getting up again. I'm no salesman myself, so wouldn't know how to start this to be honest. But the CMS is too good for the current position it's in.

Also know some buyers who just buy 1 license of [x] Add-Ons I have, and keep it at 1 per Add-On. The years in between is like 2-3 years and knowing which Add-Ons these are and if they depend on eachother, I know it's not for just 1 site/project. Nothing I can do really and probably ain't the only one, but if we just have a bigger pool of potential clients it wouldn't hurt as much. The percentage may be too high compared to the users we have, and the "smaller" developers probably feel the hurting more compared to the bigger ones (IMO).

No ranting or anything, just my view on all of this. I'm a marketplace seller and buyer as well and I know people need to earn their bread just as I have to. So I have the faith in people doing the right thing, otherwise if it stays the same the amount of Add-Ons submitted will lower each month as well.

True words. You talk from my soul. I think one big step for Marketing would be to get the hosting Providers to provide recent concrete5 installations. But this just one drop of water on a hot plate. This cms is awesome and everybody i show it love it. But people dont know. Big player is WP.

Completely agree with Franz on how strict we need to enforce licenses. Its the accidental/didn't realise group that we need to keep it convenient for while helping them not make mistakes with the scope of their licenses.

Those who abuse deliberately can always find a way round it once they have access to a zipped package.

I agree, trying to stop the bad ones from being bad is a lost battle.

Limiting free updates to one year max with also an offer for unlimited updates would be lovely.

In my experience, agencies symlink add-ons and/or use private repositories (Github, Gitlab, Packagist, Satis, etc). Those add-ons are not linked to the marketplace. I am convinced this is a large number of copies. I totally get that they follow this approach though. My take on it is to not see C5 add-on development as a major source of income.

In my experience not and I worked since about 10 years strong together with agencies.

Agencies, like all companies, are also economically oriented, and if it is cheaper to buy functionality, it is better to buy functionallity instead of custom developing it. Which is also logical. However, most agency directors are not developers with an understanding of how much money a software is worth. Most are creative people. Everyone likes to spend $ 30 without thinking about it. But $ 3000 will less agencies spend as long it's possible to bypass. I do not trust just the goodwill of people. I know enough agency managers and know how they thing and act.

Maybe the mentality in the Netherlands is different. But that's exactly why we're talking. We share our opinions.

My experience with agency purchases is they are generally quite good about licenses. An agency will have a few addons it uses often and buy licenses individually for each client on a c5 account set up for that client. Its only when a support request comes in that I realise that behind the purchase is a regular customer.

The difficulty with multisite is that I can see some agencies using it to significantly change their deployment pattern. For brochure sites where the agency provides a full service with hosting and management of updates included in an ongoing relationship, they will now be able to manage a single core shared across many client brochures. It will be easy to loose track of which addons are used where unless c5 does that for them. So the c5 licensing system needs to help them keep track of that and not make mistakes.

Once multisite licensing is resolved, what we are really looking at is the general licensing system, duration of licenses and matching up licenses to support requests.

90% of my support requests are through the pre-sales enquiry channel because a site is not connected to the marketplace or an install was done manually rather than through marketplace integration, or are made 'license XXXX not currently allocated'. Sometimes it is only when I ask that I can tie together a support request with a purchase and a specific site.

my 5c:

Paypal sucks! Paypal sucks big time especially for international developers. $14 add-on - you get $10 in PayPal, -% for conversion, -% for transfer = you end up with like $5.

concrete5 definitely needs other means of payment.