Then RMS should not have begun selling components until it was ready for everyone. Otherwise, it just comes across as grubby.
And yes I realize they are just trying to create a sustainable business. But my feeling is that third-party developers are crucial to that effort.
Having something that works internally is very different from opening the doors for third-party submissions. That requires a complete, reliable pipeline for uploads, reviews, distribution, support, and payouts. If it were anywhere near ready, weād already be rolling it out.
Developers are already getting started. Thatās why we shipped Dev Packs in the first place.
This isnāt about āfairnessā. We built the entire platform, and weāre free to ship our own products while we prepare the infrastructure for everyone else. Business isnāt always neat or equal.
We understand that risk, and weāre still choosing to prioritise getting the system right over rushing it. A solid foundation matters more than speed.
Trust the force! (Luke)
I think 
if the store was ready for final release - they wouldāve done itā¦
I hope it all works out for everyone involvedā¦
Want to see all happy and fulfilledā¦
But you are telling them they canāt sell them, so what good is that.
That says it all!
What it says is that we are responsible for the health of the platform long term. We are investing heavily in the app, the infrastructure and the ecosystem, and we are not going to halt our own work until every external piece is ready.
You may not like that priority, which is fair enough, but it is the reality. Our focus is to get a stable store and a strong app in place so that when third party devs do start selling through it, it actually works for them and for us.
Itās going to take longer than anyone wants. Thatās just the truth. But if you look at the past year, we shipped over 80 Elements updates with a huge number of requests implemented. it should be clear weāre pushing harder than any dev team Iāve ever seen. We genuinely care, and weāre doing everything we can to get this right.
Hi, in my many years in the software business - including creating and selling software like the iSync plugins or launch2net in the 90s - I have seen so many backlashes and failed companies because they have given in to outside pressure way too soon or went live too early with certain features.
I am longing for all the custom components and solutions from 3rd party developers, as I want to update my clients side to Elements today and not tomorrow. But I also need a sustainable and long-lasting solution so I do not have to switch my website development app once again. This would be nothing my clients would accept. So I do support RealMac to earn at this point in time by selling their own components to be able to allow this for all devs later on.
Looking into the future I think 3 to 6 months from now we will have a thriving eco-system for Elements with many solutions and with different price tags. And many of these discussions will not matter any longer.
I was actually agreeing with you, not criticizing!
I missed this yesterday, but I think this is worth clarifying because your assumption is wrong, and itās important.
Dev Packs consist of multiple files, so while DispatchSourceFileSystemObject can monitor 1024 files, that absolutely does not equal 1024 Dev Packs.
Dev Packs contain many files; even a basic one can easily include 10 files that need monitoring (info JSON files, templates, hooks, scripts, images, icons, etc.). More complex components can have many more.
If we allowed distribution of Dev Packs, it wouldnāt take long before the DispatchSourceFileSystemObject limit was hit, and then things would start to go very wrong for users.
I also want to take the time to re-iterate the benefits of the store system weāre building.
The Elements Store brings a whole host of benefits, including:
We have to get this right. Otherwise we risk ending up in the same mess the Classic and Stacks ecosystem fell into, and weāre not repeating that.
Weāre not going to be pushed into rushing this. Weāre taking the time to build it properly.
Stick with us, itāll be worth the wait.
I think that will change the game - not only in selling addons, but in feeding back such that those addons benefit from user feedback and mature quicker !
My speculation was coarse and slightly off track re handle count. But itās difficult to imagine why elements would monitor every file with DispatchSourceFileSystemObject at risk of running out of handles when it could use FSEvents and monitor each dev pack bundle (root folder) for changes. Monitoring with FSEvents on a directory is recursive, so on any change under that bundle could just reload the entire dev pack. 
Iād missed the progress 
I think it would be helpful to add the technical aspects raised by @Doobox to the guide so it can be useful to others in the future. Could this be helpful? This is all useful technical information for those who need to invest time in development.
also to better understand how to work on client projects with devPacks
Iām also wondering how custom components are managed. They too can have resources linked to the project. I donāt think this creates any limitations, or am I wrong?
thanks
Itās not really helpful, Iām just sticking my nose in where it doesnāt belong. How they watch files is there business.
In a custom job you can use more than one devPacks, Iām only concerned about this, I just need information to understand how I can offer a service to a single customer with my code.
Your fine. Itās not about the project file, itās about how many dev packs you have installed. Stay under 100, (with current info) and you will be grand.
99 is fine 
If elements freezes on launch, you crossed the line 
