Crowdfund people to package apps for Cloudron
-
@jdaviescoates well that seems very sensible!
-
@eddowding What might work in the meantime is if those have already packaged an app, as well as those who are packaging one right now, and even those who may package an app could share some mode of payment that the rest of us could use. That might be a BTC or DGB address, a paypal.me address, a Stripe address, etc. There might be more out there (like those Buy Me A Coffee services). That info could then go into their User Profile.
So far, the people who have packaged an app did so out their own generosity. I think making it into a, "we've paid, now do it", would make things more stressful and change the open attitude that exists here. But I definitely get that some might be motivated if they knew there was definitely money or crypto involved. Some might even prefer that a donation be made to a charity, rather than receiving payment. So, maybe putting it in their hands (in their Profile) would be a good start. As I type I'm actually throwing in my DGB and BTC address in my Profile, more as a display than a request of course, since I haven't actually packaged an app!
EDIT: Perhaps putting that info in the Signature would be easier and quicker for ppl to see. Saves a trip to the Profile tab.
-
I love the idea of having "Here is how to tip me" in the signature line of the devs, but I don't know if it solves all the problems.
Here is my attempted stab at a solve...
I would like there to be an addition to the forum. Essentially, a kickstarter like model.
Whenever an app is requested by an end user, cloudron team posts a comment on how users can "fund" this project
The monies would be dispersed only after an app is published to cloudrons app store as Stable
The monies are split proportionally to the various devs involved in the apps completion
To address time involved (8 hours on 4 lines of difficult code) versus amount of code (400 lines of easy to implement code), I don't have an answer there. But something needs to be there to address that. -
@privsec All in all, I think it is incredible that the Cloudron team has built something that can actually be 'easily' augmented by their own users, without demanding or requiring payment. It would be good if we could solve this without getting them to do it. If they do it, then it's the Cloudron devs who are spending X amount of time redirecting money to others, and not even getting paid for it (even though they've laid the groundwork). Not to mention, they'd then be stuck giving support to that app. I guess if they did arrange something, they could collect x% to make it worthwhile for them. But this then starts getting tricky, and as I'm typing out loud, I think again: We should solve it, not them.
I
A life lived in fear is a life half-lived
-
Ok, I can see that. A community provided solution would be beneficial.
How would you suggest we address the following
Paying a dev some money and then they bolt prior to completion?
Multiple devs work on the same app together (this is a kinda simple one, but it has merit)
Prevent a Pay-to-perform model that might intimidate some
-
@privsec So far, the community sort of knows who is packaging what, so when they are done, and it's live, then they share their payment mode. Of course, if it's in their Profile or Signature then anyone can pitch in any amount at any time.
I do understand that the question is more along the lines of whether the offer of payment will attract someone's attention and effort to package something, or even a group/company to do it, thereby making it more likely that some of the cool and useful apps we've been asking for actually get done. In that case, having a system where the money is ready to paid out is what will draw those people and efforts.
Perhaps a bounty system could work.
I've just followed the link that @eddowding shared, https://forum.cloudron.io/topic/2798/sponsored-app-creation, and I see that this topic has been covered already quite well. There was even a new Forum category added! So I think I'll stop babbling away and read up on those other threads.
-
@scooke said in Crowdfund people to package apps for Cloudron:
they'd [the cloudron devs] then be stuck giving support to that app
I think this is the key point here. Instead of creating short term incentives to "get an app in the store", there is a need to find people that are really invested in apps and there to maintain and troubleshoot app installations.
I'm currently watching an appstore concept implode on another project, where exactly this did not work out. And now after a new release that needs changes in all apps, apps are dropping out because its just not worth the effort for the maintainers.
-
@fbartels I think you are exactly right on this.
We can add 100's of apps to Cloudron, but even the most stable of apps produces a level of questions on usage, bizarre edge case deployments or configurations and of course updates.
Cloudron might need to scale up support resource for a large influx of apps, and then subscription charges might need to, err, scale up in response.
Might be a case of "be careful what you wish for"
Alongside this discussion, we should possibly discuss how we can improve documentation and tutorials or workshops on self-packaging. You did an excellent video a while back.
And maybe in order for new apps to be in Cloudron app store, they should be recommended to have a "sponsor", not a financial sponsor, but someone who will be active in answering questions or helping out Cloudron staff. Sponsor should not be a requirement, but if there is one, it might help cloudron staff to say 'ok, let's add this one'.
OK, yes, I am rambling now. Sorry.
-
N nebulon moved this topic from App Wishlist on
-
To share a bit from our side, what @fbartels said is pretty much spot on and also one of the main reasons we only slowly add new app packages over time. While the initial app packaging effort is some work, the long tail including ongoing app support and updates, is usually more work. Two give two current examples where I am looking into even making only the next updates possible without breaking installations, are firefly-iii (they changed the LDAP implementation and it doesn't work anymore without upstream fixes which are still unclear, I am no PHP expert) and the latest major version of peertube, where we now have to come up with automatic database migration scripts.
We do accept offers for creating app packages already and some of our apps landed in the library due to that, however we also factor the mentioned ongoing costs into the picture here, so none of this is within the
"buy me a coffee" * 20 such userscategory.This is just some reality which we also had to learn the hard way. Server side apps are not like mobile apps which may not need to be updated when security issues arise. Also potentially many users are affected if an app is down or an update breaks, compared to if one phone/client is broken and from our perspective at least, the product would not work as a whole if our users would have no-one to go to, to get it actually fixed.
However what does speed up the process of getting apps into the published library is, if the initial packaging work has been done and we can evaluate the long-tail effects by having a working instance. We just can't give any kind of guarantee upfront. I also have attempted various packages which I had to drop half way through, since I hit issues which may just not work well with our current design.
-
@nebulon are there criteria for apps which are / are not hard to maintain? I imagine there's an 80/20 thing going on where 20% of apps take 80% of the time?
Is it straightforward to assess the likely challenge of bringing an app into the cloudron offer? eg a weighted scorecard where "has email" adds 50 points, KLOC has a multiplier, etc?
If it were possible to triage apps in the packaging queue this way maybe it might help?
-
@eddowding there may be such criterias, but they also might change over time based on the upstream app development. For example if we take invoice ninja, they rewrote the whole application, so any assessment would have to be made again, while in the end we simply have to make the update available for users whatever comes out of it.
Also based on the around 100 apps we have now, it is still not clear to me what kind of solid metrics there might be. It also depends on how much experience there is for a given tech stack. What I can say at least from a packaging perspective, go and nodejs apps are usually easy to package, while ruby/rails and django apps play in their own league complexity wise
On the other hand Nextcloud is easy to package and deploy but we found out by now, that it requires ongoing support effort just because of how the app works with regards to plugins. When we started with the Nextcloud package, it was a lot more stable and a bit of a safe-bet back then.
On top of all this, it also depends on how it is used by our users. The more users for an app, the more issues and bugs will be hit eventually. That is fine and expected, but for us it is hard to judge the popularity up-front.
If all this might sound a bit vague, I am sorry, this is more of a pragmatic view rather then theory.
