App store and code repository?

It’s been a while we’re playing with Luup, and at this stage having to download plugins from links of forums isn’t serious IMHO. Not having any shared development space limits collaboration.

Are there any plans to introduce a proper app store with updates management; and some sort of plugin code repository, based on Subversion or something like that. The latter would help to collaborate and speed things up. There are plenty of collaboration platforms on the market, the point is to agree on a specific one, or to let MCV to offer a code management space

Yes, there are plans for this! In fact, it’s one of the first things i’m tasked to do as a new member of the micasaverde team.

We’re still discussing the details, so there’s nothing to announce yet. Probably at first it will be something really simple, more like a ‘gallery of plugins’; but it will evolve to a full-fledged appstore.

Suggestions welcomed… :wink:

For the “gallery” -basic functions: add, delete, hide, update. I can’t reiterate ‘update’ enough - there should be an easy way to patch the offered plugin when necessary.

It would also help if we standarized on a source control system. It doesn’t have to be supplied by MCV, but having a central “recommendation” (preferably free) would likely increase the code sharing during the Development phases.

Similarly, all internal Plugins, the ones shipped with Vera, should be pushed into that space. I can’t tell you the number of times I’ve had to “install” one of the Vera ones, just to get it’s source to see how something is done, only to “uninstall” it afterwards.

You may even find that we fix them for you guys as well :wink:

btw, Welcome to the Forum, looks like @MCV has an even more geo-dispersed team now :wink:

There are plenty of offerings there - gitorious, github etc. (As you can see I’m a big fan of git SCM)

@javier, are you the new Lua guru we’ve heard about? :slight_smile: Welcome!

There are plenty of offerings there - gitorious, github etc. (As you can see I'm a big fan of git SCM)

Understood, but by standardizing it, making a solid recommendation, we’re not going to be scattered all over the map. Not that anyone will ever be held to it, but I’d rather not have to deal with a hodge-podge of CVS, SVN, Mercurial (etc) as each developer choses “free will”…

That helps, as folks won’t have to use different SCM tools and/or interfaces to get to the stuff.

Otherwise we might as well continue to use ZIP files and an assortment of File-storage services :slight_smile:

I see 4 possible scenarios:

  1. MCV leads the way and establishes the common source control system or officially recommends one.
  2. We lead the way and decide on one source control system for user-generated content (plugins, fixes, enhancements etc.) and promote it ourselves. We may ask MCV to help promote it as well, if they decide not to go with scenario #1
  3. We do nothing, keep exchanging xml and zip files through the forum.
  4. Everyone uses what he thinks is better, we end up with scattered and divided tools, systems, sources and SCMs.

Let’s prevent #3 and #4 :slight_smile:

So, when you said this:

It would also help if we standarized on a source control system. It doesn't have to be supplied by MCV, but having a central "recommendation" (preferably free) would likely increase the code sharing during the Development phases.

I assumed we’ll be going with scenario #2 and tried to “suggest” git as a SCM and one of gitorious or github project hosting solutions… Feel free to offer your suggestions - I’m open. :slight_smile:

I’m hoping we can encourage (1).

I really want the “source versions” of the stuff that’s already shipped from MCV “as source” (D_.xml, I_.xml, S_*.xml) to be in the repos. Obviously not their proprietary stuff, but the stuff that’s already in source form, and should often be referenced/linked from the Wiki “as samples”.

In a perfect world, we could tweak it occasionally and have that team participate without splintering the base. Mostly since this stuff is on the “fringe” of the codebase and often has bugs, or could benefit from {|better} code-doc (etc).

To me, this is the natural extension of the Wiki editing we already have.

I can survive the way I do now for ages, but suspect others would benefit from the above. If we don’t get a direction from MCV and team, in say 1 month, then I’m happy to go with whatever.

I work with a bunch of them anyhow so it’s not going to bother me (as long as it’s a free option)

Yes, as the largest producer of said enhancements/plugins, I’m pretty sure you can survive the current way as long as you want… ;D

I guess we can wait 1 month…

I used to work with almost every SCM out there, so it wouldn’t matter to me much. While I still like git the best at the moment, we may not need its powers of distributed development…

@javier, we’re looking for you to chime in here, as the official MCV Luup contact.

We’d like standardize somewhat on the “preferred” model for source control, with the following types of goals (others will likely chime in with more):

[ul][li]create a shared experience for Luup Development[/li]
[li]allow all sorts of Skill levels to contribute (from “beginner” to “rocket scientist”) with a low learning curve to participate[/li]
[li]to automate the [preferred] mechanism from Development, through Test and ultimately to Patch (via the Marketplace/App store etc)[/li]
[li]have well defined packaging contructs for the Marketplace distrib (ZIP, EAR, JAR, RAR, TAR, etc)
[/li][li]be free[/li][/ul]

Overall it’s about sharing more during the development, or to foster new development, but also to document/automate and expedite the process for getting [validated] plugin versions into the Marketplace for users to consume.

chiming in…

I’m still gathering all the pieces needed for this; but this is roughly how i see it:

[ul][li]we want to promote development. the home enthusiast is the best ally we can have.[/li]
[li]we want it to be as easy and open as possible. open for developers and easy for users. a stated goal is to be so easy to use that you’d want to use it to install on your own device instead of copying it yourself.[/li]
[li]we love free. we won’t charge for free plugins.[/li]
[li]… but we also want to foster commercial plugins, like a full AppStore. for these we’re planning to charge a percentage of the sale price.[/li]
[li]at the same time, we’d love if a commercial developer wants to make the code readable, even if users have to pay a little to have it installed. Of course, this is optional, a commercial developer might want to keep the code secret.[/li]
[li]Making it open for developers mean (among other things) “allow by default”. That is: once you upload the plugin, it’s immediately available, no authorization required. We still reserve the right to disable it, of course. (for example, if we find a copy/paste from a commercial plugin)[/li][/ul]

There are (many) other things still to be decided. For example, I’d like it to be useful as a learning resource, even for those that are still deciding if buying the device. Also, some kind of rating to allow users to ‘reward’ those plugins they find useful/reliable. A centralized place to write success stories… lots of ideas

What surprised me on this thread is the focus on SCM tools. I hadn’t foreseen such a need, because I think writing plugins is mostly a one-person task. In that scenario, just a simple way to keep the most recent version readily visible, with previous ones available would be enough, don’t you think? In the relatively rare case of a truly cooperative development, you could use any other service while development (google code, github, etc) and just upload to the appstore the release versions.

Another possibility to support developer collaboration is a tool like Trac ([url=][/url]); but it seems to be oriented to the ‘one big project’ setups. Do any of you know a similar tool better suited to the ‘many small projects’ situation?

As already said, I want to start small. As small as just a few wiki pages, just to have all contributed plugins available from a single location. Next step would be formalizing and automating the process to add to the servers.

I’d like to see some basic code “snippets” we can browse through, right now I have to search through the Luup forum to find what I need since Im not a coder…anything to help code searching/sharing would be wonderful!

@javier: I think that a recommendation on SCM would be useful as using a standard set of tools would make it easier to someone to get up an running looking at code. Also, seeing the history of a plug-ins codebase can be helpful (particularly if there are good check-in comments) at figuring what each piece of code does. I think that as the community grows, the platform matures and time goes by we will start to see larger plug-ins built. It would be nice to have the infrastructure in place ahead of time to support that.

@javier, initially I think you want to focus on “seeding” the Development base. There are folks out there that aren’t traditional SW Eng types that would likely jump in on developing plugins, and potentially “fixing” some of the open issues (in the source-file delivered files .lua, .xml) if they had a quick, easy way to do that.

You’d also find folks helping each other out more if there’s commonality of the tools used (with Web based viewing techniques for Diff etc).

Here’s an classic case:

The Phone [Web] interface has been missing key functionality from the Full UI since day one. It’s not the focus on the MCV team to address that, but there are folks here that would fix it, enhance it (etc) if they had a reasonable mechanism to collaborate on those fixes… with some potential to get them back into the mainstream product.

People will develop this stuff for free.

…mostly because they have a functional need for it, and can’t afford to wait for it to get developer time, but also due to passion and inquisitiveness.

Ultimately I think the common platform will foster a better sense of Developer community, with folks helping “tweak” each other’s plugin’s etc to add things.

Want to add Events and Scene handling to my Weather plugin, go for it in the full knowledge that the changes can be merged (easily) into the base.

Want to formalize the IPSerial Plugin, and make it a bit more flexible, no problem! (and no duplicate versions floating around.

Want to build the “luupx” Lua Package for everything not in the “luup” package that are needed daily to write more advanced Plugins, all good.

Of course, there will eventually be some sort of “closed source” Plugins, and they’ll have their own world(s) to develop in, but at this stage I think we can promote (and grow) the Free Plugin base by having some commonality in environment… at least a strong recommendation.

It might be as simple as putting up a Forum Poll containing a few recommendations and we vote on it. Over time, my expectation would be that the “winner” would get greater automation-integration with the MIOS Marketplace, so people could go from concept to deployment with minimal fuss.

I’d second what guessed said. He did a much better job explaining what I was trying to express.

Another nicety of a standardized SCM is that the MIOS Marketplace could be made to be aware of it and be somewhat integrated with it. This would make it easier for new users interested in getting involved in working on plug-ins to discover the code and the open source developer community that we are hopefully forming.

I agree that if we don’t see some action on this from MCV and Javier (who I really appreciate for all of his help recently) by the end of February, that we just do something ourselves. Starting off simply shouldn’t take much effort or time and once it gets rolling more and more contributions should stream in. I would appreciate Javier monitoring it and improving code where needed.

@javier, let us know what you’d like to do here. I think folks would like to “move” by the end of Feb, so it would be better to make the decision before then (with you guys on board) or we’ll plot our own course :wink:

Well, on our plans, first and foremost is to foster sharing. That must include not only software developers that love SCM, but also the hobbyist that managed to get something cool and say “Gee, this is cool, why not share it?” without having to ask himself "Now, where should i put it? how to let others know about it? should i make some package? installation instructions?.. "

To reach there, I’m tinkering with the Mios Marketplace, ideally making it bidirectional. Once you have something on your Vera, you should be able to publish it right from there, without bothering with packaging and install procedure. After all, you already have done it!

Now, if a plugin is popular, it will grow and evolve, likely forked too. For this a SCM is a lot of help, especially a distributed one (like Git). But it also needs some web pages (like a wiki), a ticket system… etc.

My first thougt (already mentioned it) was using Trac ([url=][/url]) but it seems inadecuate for a multi-project environment. Almost the only alternative is Redmine ([url=][/url]), but still no consensus on it.

A different possibility is Fossil ([url=][/url]), it applies the ‘Distributed SCM’ concept not only to the code management; but also to the wiki, documentation and bug tracking… seems pretty amazing. Unfortunately, it replaces your SCM, so you have to install it to use it… a no-no these days. Unless it were preinstalled in the Vera box, and you interact with it locally, and the Vera box synchronizes with everybody else that also have your plugin… a weird and powerful concept, but somewhat further into the future.

current plan:

  • first, just some wiki pages and a forum channel. Things move from there to the MIOS marketplace manually on request from the contributors. If you need real SCM, please use GitHub, GoogleCode, BitBucket, or something like that. On each ‘releasable’ version, just put a note in the forum and/or email us to update the marketplace.

  • in a month or two, a web application (RedMine or similar), with integrated SCM (likely SVN and Git). At this step, we plan to make the Marketplace auto-update from the SCM, probably from a ‘release’ branch, or by a predefined tag

If we decide to go with the ‘publish from your Vera’ idea, it would be integrated with Redmine, or whatever we’re using.

About the “make it or we’re moving” thing… well, I don’t think it’s a totally bad thing. at least for a while. we don’t have a publicly writable SCM, so If you want one, you have to use some other service. Once we have our own, you’re free to choose if you want to migrate to ours, or stay there. It’s even possible (but i can’t promise it yet) that we could make the marketplace ‘follow’ some branch on external SCMs. I don’t see this a ‘desertion’.

I’ll put some extra steam on the Redmine evaluation. If anybody here has any comments on this, please share.


Sounds promising so far, thanks for sharing. I guess we can start with something smaller, go in stages (wiki → external scm → integration with marketplace) and address the specific details as we go…