That’s a good suggestion and maybe one video just to highlight how to use the other ones in the list.
Ah, all those in the dropdown menu were just early examples of what you can do with components, they are just using the Elements API. They are a little long in the tooth now and need to be updated and re-done… something we are planning on doing, but there is only so many hours in the day
Over the coming months we’ll be updating these and doing new dev videos to help people build more exciting Custom Components and Packs!
I don’t know what the best solution is, but it’s probably not this. So you know where I’m coming from, I was involved with two of the earliest “publishers” of personal computer software in the 70’s, and managed several (including “stores”) since. I’ve watched pretty much every version that’s been tried, some from within.
The basic “cost” of providing a product these days is transaction fees plus a very small bandwidth cost. I currently provide thousands of products a year directly at a burdened cost of about 7% of the price I post to users. The de minimus charge for an electronic transaction and download is probably about US$3.
Basically, stores and publishers are acting as middlemen. They’re usually run as profit centers (otherwise why go to the extreme of building them and assuming all the fixed costs?). I’ve seen the “middleman tithe” put at anywhere between 25% and 65% in my long software/publishing history. What history seems to tell us is that even 30% isn’t sustainable for true software businesses (as opposed to hobbies).
RMS likely knows that from their own experience with the Apple Store. So, I, too, am wondering why you’re really trying to do it yourself. The answer I come up with is that “it’s marketing.” By having Elements and all the Elements resources in the same place, Elements “looks bigger and more complete.”
Dan’s response here is basically Apple’s response to everyone. I don’t necessarily disagree with the contention, but we know that this is Apple-friendly and consumer-friendly, but has proven over and over to not be developer-friendly.
So, Dan, what are you going to do when I develop a porn component (to use just one possible example)? Say it can’t be in your store? How are you going to police Developer 1 basically “stealing” Developer 2’s component? I think you’re opening yourself up to be the bad guy to developers, just as Apple did.
So I see two elements—pardon the pun—at work here: policing and fleecing. 25% is too much, and I have no idea how you’re going to actually manage the “store” when the inevitable issues start happening.
Note that there are alternatives that accomplish much of what you say you want to do. It’s called curation. Sell Elements, Elements Extended, and point to all the others.
The distribution model we’re rolling out is all about creating a smooth, secure, and consistent experience for everyone. By standardising payments through Stripe and having Realmac manage the marketplace, users can trust they’re getting reliable, high-quality content, while developers are freed up to focus on creating great add-ons without the headaches of handling distribution, security, or updates.
Updates will also be seamless, so users always have the latest features with zero fuss—and to top it off, all purchases will be safely backed up in Elements cloud, meaning they’ll be available on any Mac whenever needed.
We completely understand that the platform commission might raise some concerns. However, it’s an essential part of supporting and improving the platform—covering everything from development tools to documentation and support, all of which make building with Elements easier and more efficient. These investments ultimately benefit both users and developers, ensuring a thriving ecosystem for all.
The list of benefits for developers, but more importantly users, just wouldn’t be possible without us building the Marketplace directly into Elements.
You can learn more about the benefits of the Marketplace here.
I have already come out in favor of the RM Marketplace. However, I wonder if instead of a percentage, a flat fee might be better? Then the user and the developer knows the RM tax being applied without doing the math.
Plus, that seems more fair to me. Someone who spent months creating a CMS solution who sells an add-on for $100, costing him $25, versus someone who invested an hour creating a widget that sells for $4 costing them $1 is not balanced in my opinion.
The labor and overhead for hosting to add-on is the same. In theory, the review process doesn’t happen every transaction, just updates, so such a large fee seems obsessive to me. Maybe even consider a review fee as a line item cost. That way only quality add-ons get listed for sale rather than quick utilities or junk-ware.
Just my 2¢.
Thank’s so much for all the feedback — it’s truly appreciated!
I knew there would be varying perspectives on the Marketplace commission fee, and I want to reiterate again how important your feedback is to us. The current rate is designed to help support platform development, maintenance, and marketing, ensuring a sustainable ecosystem for both developers and users.
The current system is designed so there is no financial risk for the developer, and there is as little friction as possible to go to market. The Marketplace will allow anyone (including users) to go from building a component to shipping it live on the store within a matter of hours. There’s no need for a new developer to setup their own store, licensing system, update server, marketing website, this will be a phenomenally easy system to get up and running with. Not to mention the benefits to the end user!
While we don’t have plans to change the payment structure at this time, we completely understand that every developer’s situation is unique. If you’d like to discuss your specific needs in more detail, please feel free to email me directly at dan@realmacsoftware.com.
Just want an app that offers 90+ percent, leaving the 10% for niche features. With those 10% not being required to build a fully functional modern site with all the general requirements, otherwise to me its just RapidWeaver all over again.
Awesome, that’s pretty much our goal, and I think we’re well on our way there!
What are the 90% must have features for you?
Dropdown Menus then I am good!!
Most any other larger component can be built with the basic components included, at least for my use, which is relatively basic!!
Is that an in-page dropdown menu or one in the navigation bar? Can you post a link or screenshot of the type of thing you need?
In page dropdown
See here: Dev Diary Ep49 - Let's talk Components - #4 by sbchasin
Example of what is currently on my site is in that post. That is what I am looking for.
I’m not opposed to the proposed marketplace and I don’t think 25% is unreasonable. There will be tangible sales benefits from being on the RM site rather than trying to be ‘discovered’ through a Google search. Making it a seamless install, trial, purchase and update is worth the commission. I’d much rather save an hour of time and trouble than saving 5 or 10 bucks commission.
I’m unable to see how a flat fee would work when the pricing could be so disparate - a percentage makes perfect sense.
My assessment is Elements will have far more base functionality than Classic and the need for 3rd party add ons will be less. Because of this, I’d expect these add ons to be more complex and likely cost more. There may be fewer developers but they will be focused on more sophisticated products and will likely do very well.
It seems there will also be a healthy community of free components being shared - which is great.
At the end of the day, I expect similar functionality in Elements will be significantly cheaper than Classic with Stacks, and I’m all for that.
— EDIT —
So you asked a question and I spent time responding, I even gave positive reinforcement of the way you’re gonna handle 3rd party developers to ensure the quality for users. But was not given a response in return to anything, you just instead closed the thread.
I really wanted to believe things had changed with RealMac so badly.
I’ll point out my observation here. When the percentage take is around 30% (which is the norm these days), two things happen over time:
- The developer atrophies and goes away over time because it’s not financially viable to put full energy into the product.
- The developer leaves the store to sell directly, because that’s the only way they can get enough long term revenue to continue real development. This is also where the SaaS trend intersects.
I’ll give you an example from a competitive product, Blocs. About half the items that were in the initial “store” are no longer supported.
I understand why RMS is doing what they’re doing. It’s a logical simplification of a bigger problem. But I’m going on record as saying it won’t prove to be the real solution long term.
The issue intersects with the other part of this discussion, which is what should Elements actually include. I’d also bet that short term we’re going to see a bunch of two-day projects in the Elements store. We’ll find a dozen ways to do cards, a dozen ways to do an animation, etc. I’ll probably pick up a couple of these things because they save me two days and their price is likely to be not even remotely close to what I charge an hour.
I’m still concerned that Elements won’t ship with everything that’s really needed, so the whole issue of what developers add is important, and it’s important to see that they’re supported well.
That’s a bit of a kitchen sink. Many of those things are easily done via Custom component (e.g. Comments), because you’re using external services. Ditto social media embeds.
The Big Ducks in your list are blog/CMS, ecommerce, GDPR, and maybe forms and password/login. Even those are somewhat available as HTML embeds, though much more elaborate ones that really could use a dedicated developer.
The other most important thing that’s missing is an Introduction to Elements book. Because beyond building through the basics we already can see in Elements, it should extend into “what if you need a blog, forms, comments, password, etc.” and show examples of how to do that, probably using some Custom elements and some DevPacks that become available.
If Dan would give me a full week of his time in the UK, I could probably create that book today (disclosure: I’ve written and sold over 2m books in 29 languages and at beginning to deep tech pro levels, including some seminal programming ones, such as the PC Programmer’s Sourcebook from Microsoft Press). Yes, having specific online help is useful, but it doesn’t build the picture the way many need in order to learn.
I could certainly deal with that approach if detailed and extensive. Just being part of the online manual / in-app help would be fine to me.
I think we it’s worth taking a step back from this for now. We still have a way to go before the Elements store is available in any form. As soon as we have something to show, we’ll demo it in a dev diary to get feedback from you guys.
If you’re a developer and would like to discuss your specific needs in more detail, please feel free to email me directly at dan@realmacsoftware.com.