-
- 24,544 Posts
The biggest problem I have with Package Manager is the occasional raft of error messages it puts in the log.
One thing that I think might help a lot with the current Package Manager is to add a "Cleanup" button to the PM panel that would remove packages from the DB that no longer exist in core/packages, and maybe if there's no version of the package there, also remove any objects with their namespace and/or category.
More tutorials and examples of creating packages. I've been struggling with MyComponent off and on now for weeks, just to package a template. If more people can easily understand how to make packages, there will be more packages. I'd like to concentrate on getting a couple dozen fairly basic templates done.
-
- 483 Posts
In the interest of Add-on developers and MODX users, it is really important that real documentation be easy to provide with a released Add-on. This should be supported within the MODX Package Manager.
For many little Extras, a Readme is certainly good enough and the Package Manager grabs it right away. For more complex Add-ons, simply injecting a whole bunch of files into the file system is not necessarily a good idea. Several users of MODX (mostly new) are scared to touch the file system.
As a User
There are Add-ons that I have installed to use (especially in my first week or so) that I had to simply discard because I didn't understand how to use them. I know newer users are facing the same issues. Comparing to Joomla or WordPress, it's "not as plug and play". Now, MODX is far better (IMHO) than both of those and I would never want to go back to either, but that is what I hear most common from people that I teach about MODX over Skype, and I have to say that it is a legitimate barrier. A more integrated way to document Add-ons would definitely help a lot.
As a Developer
While others may not feel this way, I find myself reluctant to release Add-ons due to this. My Add-ons are already of an abstract nature and as a result, I do not have enough demonstrations or tutorials. The extra work to release screencasts and documentation (and maintain those links) can be quite cumbersome. (Mote: My personal lack of ability to come up with a viable alternative or solution has made my owns Add-ons lackluster at best, and this is something I have been trying to solve for some time.)
[ed. note: fuzzicallogic last edited this post 11 years, 2 months ago.]
-
- 24,544 Posts
Quote from: sottwell at Feb 22, 2013, 12:50 PMMore tutorials and examples of creating packages. I've been struggling with MyComponent off and on now for weeks, just to package a template. If more people can easily understand how to make packages, there will be more packages. I'd like to concentrate on getting a couple dozen fairly basic templates done.
In theory, that should be dead simple, but I'm thinking of adding some simpler example config files for packaging just a template, snippet, or plugin. I'll email you some tips.
I would appreciate it. I'm sure once I get one or two under my belt, it'll all fall into place, but getting started on something new is always troublesome.
-
- 255 Posts
IMO I am very interested in this topic and sorry I missed the hangout (had I known I would have moved mountains;). In regards to the premium addons issue and ensuring ongoing support, it's a broader issue than technically how to structure and manage it as it potentially gets into legal issues between buyer and seller and depends mostly on the licensing agreements and enforceability. This is a risk with any software purchase from a provider. Purchasing software, especially when there is an expectation of ongoing support is a dicey business as software development is a relatively low cost business venture, and therefore can tend to be pretty transient.
That said, I would not try to "boil the ocean" when scoping the direction for ModX in this regard as this is a much broader and ubiquitous business risk issue. Instead the primary focus in the premium addon space would be better served by 1.) protecting and promoting the brand 2.) set standards for such bits as minimum documentation, packaging, and demonstrations to mitigate and potential damage to it. Holding any source code in escrow if there is in fact IP or source code that the buyer does not get is also an option I have exercised in the past, and could be a barrier of entry for some shady characters and enable modx to help protect the buyer as well as the brand. It's a buyer beware world and I think if valuable feedback, ratings, and standards are in place, the buyer will be better equipped to make a good decision what to buy and what not to buy.
The upside is there is obvious opportunity here and intrinsic value to be gained. If there is real revenue potential more talented professional will invest in high quality functionality will will obviously benefit the platform as a whole. Two glaring examples are eCommerce and Forums, both of which are acknowledged high value features that have been historically difficult to deliver due to complexity. Also, there are huge integration opportunities for various media types and other services that will blossom if there is incentive to do so.
We must thread carefully with Prermium Addons. MODx is open source, the Addons need to maintain that path. While it is encouraging to Addon developers, the everyday MODx users (who make up the larger percentage of MODxsphere most be considered in this paradigm). The best model, IMO, will be a scenario where certain features of a Premium Addon is made available to all while the full version is made accessible only to paying users.
Still there will exist the need to provide necessary checks to the standard achieved in Premium Addon development via ensuring tested coding standard, proper documentation and appropriate QA/QC.