Plugin Source Repositories on GitHub

Posted on
Wed Nov 13, 2013 4:23 pm
jay (support) offline
Site Admin
User avatar
Posts: 16815
Joined: Mar 19, 2008
Location: Austin, Texas

Plugin Source Repositories on GitHub

After much discussion, we've decided to host/sponsor a GitHub account that will be used to host Indigo plugin sources. The primary driving factor is to have a place to allow continued community development of abandoned plugins (with the author's permission of course). However, a plugin need not be abandoned by the author to reside in this account: anyone building a plugin that wants to allow community contributions can ask to have a plugin added to the repository and we'll create the repo for them. If you're a developer and want to add your plugin, just send us an email to developer DASH relations AT perceptiveautomation DOT com and we'll coordinate getting the repo created.

For abandoned plugins, we'll moderate the repo until such time as we can identify a developer to delegate the responsibility to. We will do very minimal moderation though - aside from a quick glance at the diff to make sure there doesn't appear to be anything untoward we'll accept pretty much all pull requests that have a good description of the change.

For plugins from developers who wish to stay involved with the plugin, we'll assign full control over the repo to them. They can add other moderators as they see fit.

Note that we've created a new forum for Open Sourced plugins - we'd like to try and keep that to one thread per plugin if possible.

We hope this will continue to foster plugin growth and contribution.

There are two uses for the repositories: to allow users to get the plugins and for developers to contribute to plugins. The Readme file for each plugin will address each scenario, but it's pretty much the same for all plugins. To get a plugin to use, you just click on the plugin's repository then click the "Download ZIP". This will download a zip file with the Readme file and the plugin. Unzip (if your browser doesn't do it for you) and double-click the indigoPlugin file to have Indigo install it.

To contribute, just create your own branch, make the changes, then issue a pull request with a thorough description of what you're changing/adding. Of course, if you're a repo manager then you'll just commit your changes and push them up to GitHub and they'll automatically be available. When you commit changes or pull requests, make sure that the version number gets appropriately updated in the Info.plist file. Once the commit is complete, create a new release in the GitHub repository with that version number (i.e. v1.2.3) so that people can revert to it later if necessary.

And for those who are really paying attention, the name of the account does hold some significance and will be revealed in the fullness of time (so please don't bother asking)… :P

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Dec 10, 2013 3:42 pm
discgolfer1138 offline
User avatar
Posts: 45
Joined: Jul 28, 2011
Location: Golden, CO

Re: Plugin Source Repositories on GitHub

This is fantastic!! I, for one, am absolutely delighted to hear you guys actively promoting collaboration and embracing GitHub :)

I have a few questions/suggestions to, hopefully, help this effort succeed:

- 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?

- 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 :)

- 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.

- 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

- 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.

Phew, that was a lot of yapping on my part... Hope some of it makes sense. Bottom line, I'm super-excited and can't wait to see things grow!

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 :)

(my face while reading the previous post...)
Image

Indigo 6.1.0 | Mac Mini | OS 10.10.3 (Yosemite)
Fork Me on GitHub!

Posted on
Tue Dec 10, 2013 4:46 pm
jay (support) offline
Site Admin
User avatar
Posts: 16815
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Plugin Source Repositories on GitHub

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.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Dec 10, 2013 5:15 pm
roussell offline
User avatar
Posts: 1108
Joined: Aug 18, 2008
Location: Alabama

Re: Plugin Source Repositories on GitHub

jay (support) wrote:
After much discussion, we've decided to host/sponsor a [url=https://github.com/IndigoDomotics]GitHub
And for those who are really paying attention, the name of the account does hold some significance and will be revealed in the fullness of time (so please don't bother asking)… :P


I'm not asking exactly, but did the name change? I thought when you originally posted it was something like Indigo Developers or something like that. It could have been the beer I was most likely consuming at that moment, so if it's been this the whole time, never mind... 8)

Terry

Posted on
Tue Dec 10, 2013 5:55 pm
jay (support) offline
Site Admin
User avatar
Posts: 16815
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Plugin Source Repositories on GitHub

LOL - no change so it must've been the beer.

Send me one… :twisted:

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Tue Dec 10, 2013 11:16 pm
RogueProeliator offline
User avatar
Posts: 2437
Joined: Nov 13, 2012
Location: Baton Rouge, LA

Re: Plugin Source Repositories on GitHub

And for those who are really paying attention, the name of the account does hold some significance and will be revealed in the fullness of time (so please don't bother asking)…

With part of the root being "domus" it is blatantly obvious... you are embracing localization and the first supported translation is Latin. Case closed. (You mean 9 years of Latin is going to come in handy??? Nah, never mind.)

Posted on
Tue Dec 10, 2013 11:36 pm
RogueProeliator offline
User avatar
Posts: 2437
Joined: Nov 13, 2012
Location: Baton Rouge, LA

Re: Plugin Source Repositories on GitHub

- 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.

I tend to agree with Jay on his assessment... GitHub can be very intimidating to entry-level software developers, much less non-developer users. The forums tend to be have a "friendlier" feel for lack of a better description that encourages users, at least to some degree, who may be a little hesitant to post. That isn't to say that you couldn't leverage issue tracking software - be it GitHub or one of the other versioning systems out there.

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.

I've considered implementing some amount of unit testing into my plugins -- I just spent about 6-7 hours this past weekend regression testing all my plugins against a new version of my plugin framework that I was rolling out to them. Unfortunately, I think that unit testing can only go so far in that after you have verified those, you really still need to do a complete test against the real hardware which often is not conducive to doing so in an automated manner.

What I've done in the interim is setup control pages with buttons that run specific tests / sets of steps and which can be verified by sight on the hardware when necessary (e.g. volume does indeed change to 14 during that step). I also run through a set of GUI tests to verify that, as best that I can, the plugin GUI prevents bad input within the configuration dialogs. That is the most time-consuming step... something that in the Microsoft world I know tools can automate/verify but those don't work outside of .NET and I don't really have the time to investigate iOS options.

Please do let us know if you do any work/further investigation in that area... audience may be somewhat limited judging by what Jay said, but there likely would be several interested parties out there.

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 7 guests