review new teams for Gratipay 158 #234
Comments
|
Are these teams a good fit for Gratipay? How can these teams improve their application? What questions do you have for these teams? |
|
Bcc: [21]
|
|
@kyledrake bounced our mail; reticketed that as gratipay/gratipay.com#3530. |
|
Stuff that looks off to me - https://gratipay.com/commie-subs/ https://gratipay.com/aerith-radio/ https://gratipay.com/jens-segers/ - Account for an individual developer, revenue model and how to get involved are not mentioned. https://gratipay.com/sqlalchemy/ -
What about Gratipay revenue?
|
|
How is a team with a single member different from an individual? Most of the teams seem to be centered around a single project. So (for programming-related projects at least) the "teams" sound like they actually are a proxy for the core group of developers, which for small projects (everything starts small) often is only an individual. It seems to me that individual accounts like https://gratipay.com/jens-segers/ are meant to be a proxy for all the projects run by the individual. For example, I'm a CPAN author and when submitting teams I wondered if I should create a "team" for the work I publish as BOOK on CPAN in case someone wanted to support my open source work in general, as opposed to individual projects. (Some of the distributions I publish are not my creation: I took up maintenance of them after the original authors stopped working on them. This is called "adoption" in CPAN jargon.) On CPAN, some distributions are the work of a (sometimes large) team, and some authors are very prolific (with a hundred or more distributions published). If I wanted to use Gratipay to support Perl projects, I'd like to be able to support both team projects and people whose work I appreciate. Disclosure: I submitted applications for https://gratipay.com/act/ and https://gratipay.com/cpan-io/. |
|
I also have similar concerns about my project, JOSD. It is an individual effort, so far, and even though I welcome contributions, it confuses people who see my name on the book and github repo and a "team" on the donation page. |
|
Do we really care about how project revenue in general is shared? Or do we only care about how revenue through Gratipay is shared? Perhaps that section title should be reworded. |
|
@webmaven, but the way the revenue is shared on Gratipay is not really under control of the team owner, so they can't enforce much once they've invited new members. |
It isn't?: gratipay/gratipay.com#3433 (comment) |
|
Oh, OK. My reference was the features/teams page, which might be outdated. |
|
Re: jens-segers. The user created that team during a private support exchange. He asked to withdraw his balance, and I gave him the option of migrating to a team account if he wanted to keep using Gratipay, or waiting until we release 1.0 balances otherwise. He stubbed out the team, but said he doesn't really care which option we go with, so I've rejected his application and put him on the list for 1.0 payouts. |
|
What do we think about "Debian Long Term Support by Freexian"? That seems too long of a name to me. Could that be "Freexian" instead? I expect Freexian can't claim to represent all of Debian, such that the team could be "Debian" or even "Debian LTS." Though looking at the Debian wiki, it appears that Freexian's LTS support is fairly official: https://wiki.debian.org/LTS Maybe "Debian LTS" after all? |
|
One thing that is not clear to me (sorry fort being slightly off topic): what happens tout the money pooled on my user account when (if) the teams I submitted are accepted? My participation to Gratipay 1.0 was mostly "remote", as I never put any money in the system, only redistributing some of what was tipped to me (probably not enough, considering how much I accumulated). I'm wondering if that kind of "participation" is still possible under Gratipay 2.0. |
@book A team with a single member is open to other individuals joining, whereas an individual is just an individual. Creating multiple small teams is fine, the hope and expectation is that some small percentage of those small teams will eventually grow into much larger teams that support many, many people working on them. We want to bake that possibility in from the very beginning.
We consider that your "Gratipay 1.0 balance," and we'll release it to you in the first payment cycle where you are an owner or member of a team.
I believe so, if I understand you. On Gratipay 2.0 you can set up payments to other teams, and we'll debit/credit you the net during each payment cycle ... though, come to think of it, I'm not exactly sure what the behavior of the system is if you don't have a credit card attached. |
That describes one distribution method, which we're trying to bring back, though that's cascaded into bigger questions (#214). Regardless of the distribution mechanisms directly supported on Gratipay, it's always possible to distribute funds apart from Gratipay: simply withdraw the full amount of your income to your own bank account, and pay out contributors however you like from there. |
Since people can't pool money anymore, that means if they don't have a credit card and the give more than they receive, then they'll give less. The best way is probably to distribute the debit proportionally across all recipients. So if someone want to give $10 and only receives $9 on a given week, then the missing $10 will be removed from each donation. If they planned to give $5, $3 and $2, then each recipient would receive $0.5, $0.3 and $0.2 less respectively. I expect it's going to be more complicated than that if there are many people like (e.g. the person was actually receiving $10 but one of their donors came short, and so they only got $9), because there's some network effect there. I guess you'll need some extra rules to make it settle quickly on a unique solution. (Obviously, the order in which donations are processed shouldn't change the global result.) |
|
@whit537, one question I didn't get an answer to is the following:
I've been giving the idea some more thought, and I think it would work fine for CPAN authors, who are typically people with several small projects (their own CPAN modules) rather than one larger project (although there are many large CPAN projects too, which usually outgrow their author, and would deserve a team of their own). So people who appreciate their work could tip them for their work on all their Perl modules in general, without the need to pinpoint one project in particular. In my case, if I created a CPAN-BOOK team, I already know one person I would invite to the team, as he's been a contributor to several of my modules, with patches, help with debugging on Windows, etc. and I want to recognize that contribution to my work. Of course, once I have created such a team and it's approved, I would suggest other CPAN authors to do the same. So I'm asking first, in case that sounds like a bad idea to Gratipay. |
|
@espadrine Can we work on the "Revenue Model" section of https://gratipay.com/shields/?
That says what revenue is used for, but the question here is "How does your team make money?" Where does the money come from in the first place? Who are your users? How do you get them to pay you? |
|
Re: #234 (comment) SQLAlchemy is an interesting case. It is an open source project, whose development has been driven greatly by for-profit consulting (by many parties) to add enhancements. It isn't really structured to share donations among voluntary contributors from it's community (which is largely steered towards bug reporting and answering Qs on the mailing list and IRC channel), and I think the answer here indicates that Authors are generally assumed to be contributing patches that solve a problem for themselves (or for their clients). I could be wrong, but that seems to mean that all donations via PayPal are currently going directly to @zzzeek. |
|
@book Similar questions looking at https://gratipay.com/act/:
and https://gratipay.com/cpan-io/:
This tells us what your costs are, but the question is, how do you make money? Who are your customers and how do you get them to pay you? Do you make an appeal on the website itself directly to users? Do you sell sponsorships?
The CPAN-BOOK case is a fine use for Gratipay, yes. You're basically a small consulting company working on multiple Perl-related projects. Does that sound right? The fact that you've already got someone in mind whom you would consider part of your consultancy makes it all the clearer that this is a legitimate use of Gratipay. It's not uncommon for "closed" consultancies to incubate multiple products and spin them off into separate entities when they reach a critical mass. Sounds like you're proposing to do the same here, which is great! :-) |
|
I sent the following to commie-subs a few days ago, in response to a support request from last week:
|
https://gratipay.com/the-charis-project/ Hah! Love it, @technomancy. :-) |
@captn3m0 Patreon might be a better fit if your goal is to build a personal brand instead of an open company. Even then, JSOD's revenue model is confusing to me:
If that's the case, why bother with Gratipay (or Patreon or ...) at all? |
|
Okay, first pass through I was able to make a decision on 12 of the 21 teams this week, leaving nine with unresolved issues:
|
|
To: Aerithradio
|
|
@schettino72 Looking at https://gratipay.com/doit/ ... can you unpack your thinking behind the revenue sharing section? You say, "Revenue is not shared with contributors." Is that because you don't have any revenue right now, or because you don't intend ever to share with contributors? |
|
@kyledrake Similar question for you re: https://gratipay.com/neocities/. Have you and Vera talked at all about a threshold past which you would be able to share revenue with other contributors? If so, can we add a sentence to that effect to the revenue sharing section? Maybe even move the second paragraph of the revenue model section down to revenue sharing? |
|
A thought - We could add small help notes above each input in the team application that indicate what we're expecting. |
|
@zzzeek Echoing @webmaven's comments above at #234 (comment), it seems that SQLAlchemy has a pretty well-established funding model outside of Gratipay, and the question for us here is how to model or adapt that for SQLAlchemy's presence on Gratipay. Both the revenue model and revenue sharing sections describe activity out-of-band from Gratipay's perspective. What about revenue generation and sharing on Gratipay? |
|
@rohitpaulk Not a bad idea, though we do have question prompts in addition to the titles. |
|
@rhertzog Looking at https://gratipay.com/debian-long-term-support-by-freexian/ over here ... your application looks good, and we're excited to have you on board. Can we do something about the name, though? It's so long. :) Reposting from above at #234 (comment):
What was your thought process behind the long name? |
|
Okay, I believe the owners of all eight unreviewed teams are all pinged here. I'm going to proceed with today's payday, and we'll see whom we can squeeze in and whom we'll have to bump to next week. |
|
@whit537 So Freexian is the only company currently offering such a scheme to Debian LTS but there's no exclusive relationship with Debian LTS here... so I want to avoid any ambiguity and we should really keep the Freexian reference. Also Freexian is more than just Debian LTS... so my best suggestion would be to shorten it to "Debian LTS by Freexian". |
|
@rhertzog Done! Welcome aboard! :) |
|
Picking up on #248 ... |
I expect the "similar questions" are:
The code is twelve years old now, and while it's still used today to run conferences, many users find it lacks many features. So there are some side projects (run by others than me) to modernize the code base and make it easier to add new features. My plan with the gratipay team is to invite the main sysadmin (who actually keeps it running for our users), and the main code contributors to the current code or the next version.
Because one of the usefulness of a conference website is to sell the tickets, the YAPC Europe Foundation non-profit organization was set up to support the online payment system. When a conference ticket is sold a 100 €, the bank gets about 2 €, and the organizers get the full 100 €. Which means that the YAPC Europe Foundation sponsors the online payment for Perl conferences in Europe. Although some of the people involved are the same, the Act team and the YAPC Europe Foundation are distinct entities. (The French Perl community has its own non-profit organization, but adding them to my already long explanation is not going to make anything clearer...)
The answers will be similar to the above. We don't make money with the site. We don't have customers, we have users. We have full-time jobs and do this on the side, for the benefit (if any) of the Perl community. No sponsors, or rather, we're our own sponsors, paying with our time (for the code) and our money (for the hosting). If the gratipay team is created, we'll probably link to it from the site.
Except for the fact that I'm not actually a company, and working on these module on my spare time, for free. :-)
Well, I don't think any of my modules (even if some of them are used by many people) will ever grow into something bigger than themselves. Most Perl modules on CPAN are libraries, building blocks, and not full products. OK. So, no matter what happens with the two teams already submitted, I will also submit a CPAN-BOOK team, and once it's accepted, I'll make a blog post to suggest that other CPAN authors to the same. This would enable the Perl/CPAN community to use Gratipay 2.0 as it used Gratipay 1.0, by "virtually buying [our] fellow colleagues a beer for EXCELLENT OUTSTANDING WORK ALREADY COMPLETED" (said @ribasushi). |
|
@whit537 Shall we do it elsewhere? This issue is both crowded and slightly closed.
Shields revenue comes from donations. It doesn't have a legal entity, though. If it did, it probably would be a nonprofit, and I probably would need to read a lot more about French law on the subject. However, given the current situation, if I need to set up a nonprofit, it will be easier for me to use a system that allows personal donations, at the expense of the possibility of sharing the workload and the donations.
Those who download content from img.shields.io, use the shields library or its API.
They donate if they want to keep the service running. |
@espadrine Sure: #264. |
|
What was the decision on https://gratipay.com/northern-plains-athletics/? I never received an email one way or another. If rejected, are the reasons given, so that a team can modify and resubmit? |
|
Decision was yes! Sorry we didn't notify, that's gratipay/gratipay.com#3564. |
|
@mattbk The plan going forward is to have a separate ticket for each team. Any reasons pro/con will end up on that ticket. See gratipay/gratipay.com#3568. |
|
@whit537 re: "it seems that SQLAlchemy has a pretty well-established funding model outside of Gratipay", I'm not really sure what that is based on. SQLAlchemy's "funding model" is based on:
and...that's it! There are almost entirely no lines of code in SQLAlchemy that were paid for by anyone, I can point you to the two things that were paid: the original version of the versioning example was paid for, and a transaction replay extension which has never been released was paid for. Everything else you see in SQLAlchemy, code, docs, examples, bugfixes, tests was written for free. Now to be fair, my current employer is a large open source company, so as of the past year, I finally can spend a small portion of my time working on SQLAlchemy and Alembic issues as part of my job. But I still have to run and fund the project entirely myself. I'm very excited for the moment by a new Bountysource platform that offers recurring payments, as open source projects like SQLAlchemy IMO deserve to be allowed to receive monthly funding from supportive users without passing through arcane ideological hoops. |
|
Thanks for following up, @zzzeek. For now I've copied your comments to gratipay/project-review#11. I will follow up there when I get a chance ... |
Applications filed between 156 and 157 (N=21):
The text was updated successfully, but these errors were encountered: