discgolfer1138 wrote:This is fantastic!! I, for one, am absolutely delighted to hear you guys actively promoting collaboration and embracing GitHub
Glad you're excited.
discgolfer1138 wrote:- As an active developer of several OpenSource plugins, does it make more sense for me to request that my repos be moved under your 'umbrella' or to continue to maintain them under my own GitHub account?
I don't know that it makes a lot of difference at the moment though it might make finding things to contribute to easier if they were all under a single umbrella. I'll leave it up to you to decide either way just let me know if you want to move yours over.
discgolfer1138 wrote:- There are a whole lot of different places that our community can look to find plugins (forums, 'official' plugin list page, User Contribution Library, 3rd party websites and/or google searchs). Have you guys ever considered creating a definitive 'registry' of sorts that the developers can publish to? As a node.js developer, I can't help but cite the overwhelming success of
npm. Furthermore, simple cli utilities and apis can easily be created to streamline the publishing and discovery process. Imagine for users to simply be able to query this registry from within the Indigo API and discover/install new plugins and even be notified when new versions are available
The plan is to have a "plugin store" at some point that will be the central place for users to find plugins, free or otherwise. We have quite a bit of plumbing work before we get there but we think it's a critical piece to get the community to the next level - allowing developers to monetize their work (and to protect their IP). I know that's sorta counter to the open collaboration that you're looking for but it's our intention for free plugins to be there as well (haven't figured out how that will work but we'll cross that bridge when we get there).
The current File Library is really a stop-gap when it comes to plugins - they will ultimately transition to the plugin store. It will probably remain as a place to get non-plugin stuff (scripts, images, etc) but that's another thing we'll have to think through when we get there.
discgolfer1138 wrote:- Since GitHub provides an excellent
Issue Tracker), would it make more sense to encourage the community to somehow leverage that to surface bugs and feature requests? While it seems that many plugin developers are quite diligent about watching the forums for issues/questions regarding their plugins, I, for one, prefer to have things centralized.
Each developer is more than welcome to use whatever tools they like. GitHub, IMO, is a bit intimidating for the typical user - just getting the plugin from there can be a little scary (which we hope to fix with the plugin store). I think using the Issue Tracker for development tasks (bugs/feature requests, etc) is probably a good idea. Using it as a support vehicle for standard users might be a bit of a stretch. GitHub is a great place for collaboration and could be much more, but I think their current focus is on developers (as it probably should be) and it's best to use it for that purpose.
But that's just us - it's not a general enough tool to replace the forums and we don't want yet another place for users to go for general Indigo answers (forums and wiki is enough). It might very well be a workable solution for plugins - just keep in mind that your plugins are likely to be used by people much less technical than you are.
discgolfer1138 wrote:- Might I suggest that you specify a template for the README.md files for plugin repos. Clear information regarding a plugin's purpose, requirements, configuration, actions, triggers, states etc. I humbly submit one of mine for your consideration:
https://github.com/discgolfer1138/indig ... /README.md
Following my thought on the last one, I think the README.md should probably be targeted mainly at developers (with a section at the top telling non-developer users how to get the plugin). That's the logic I used in creating the readme's on the
three plugins that are already up there.
discgolfer1138 wrote:- Is there an established standard for unit testing? I know
TravisCI supports python and I would imagine it wouldn't be particularly difficult to set up some basic linting and unit tests. At the very least to reduce issues/frustrations on the part of the users due to trivial errors on the part of developers. I definitely have this on my todo list and would be happy to share my findings, just thought I'd see if it's something others already have some traction on.
LOL - not that I know of. Anything you come up with is likely to be much beyond what anyone is doing with plugin development at the moment. It'll be interesting to see how many plugin developers embrace some kind of unit testing. Remember, many of our plugin developers are not professional software developers so they might not be as rigorous as you are when testing.
discgolfer1138 wrote:ps - I
tried to start a discussion regarding collaborative plugin development in GitHub over a year ago.. but .. crickets. Hope folks are ready for it now
Yep, I think the best approach to growing the ecosystem is to do it incrementally - first we needed to build the API with good docs and examples. Next we needed to attract developers/users to start building plugins to validate that we built the API with enough functionality to get some solid plugins out of it that would provide value to users. Now that we've gotten to this point, we can start thinking about how to further grow the ecosystem - which I think comes in two parts: encourage collaboration and allow monetization of plugins.
The GitHub account is just the starting increment to fulfill the first part - I don't want to try to put too much structure around it at first but rather let demand and the community determine how it grows. It also solves another problem, which is abandoned plugins. Hopefully if a developer finds that they no longer have the time, opportunity, or motivation to maintain their plugin it can find a home and if there's enough demand perhaps other developers can pick up the maintenance.
The last of course is the plugin store and is something that we are really thinking hard about at the moment. Enabling developers to get paid for their work will, in turn, help ensure that plugins will continue to be supported and developed, at least as long as they remain relevant. I know monetization comes in a lot of forms but we think it's really important to allow developers to protect their IP - which means avoiding providing source to the plugins if they choose. We have the process down to do that, we just need to make those tools available to users. So lots of thought needs to go into the plugin store to get it ready to go.
It's been fun watching the ecosystem grow over the past couple of years. When you think about it, it's actually pretty incredible that a relatively vertical application like Indigo can go from no plugins to 70+ (we just crossed that threshold a couple of weeks ago) in just 2 years.