Well a lot of what you write sounds sensible … especially with an assumed
Community-Tax (or whatever you call it in the end).
Eventually it would be an option to have a global “donation service” form the
ASF together with the option to - let’s say add a “Donate to Flex” button on
the projects website in which donations are done to the ASF with a marker of it
being directed to the Flex Project. I wouldn’t want to have to manage a
dedicated bank account and handle all the beurocratic stuff.
I guess there are enough new-banking solutions where we could split up a
classic bank account into virtual sub-accounts and each PMC has limited access
to pay using that (Just an assumption that something like this exists … if not
we should create a new TLP for that ;-) )
One thing I never want to see or discuss is: Should X be paid to do Y because I
know this will cause a lot of problems. Especially if Z could also do the same
job and might be also willing to be paid for doing it. Who decides if X or Z is
chosen? It could also lead into a direction that people could stop doing things
for free. Sort of like “If I wait for a problem to become more and more a pain,
I could get paid to fix it”.
There is a HUGE difference between setting up a Jenkins on the Intranet and
running a Jenkins on the Internet. From the end-user’s perspective, this isn’t
noticeable, but when administrating these system, it is huge. I had been
working on a solution for assisting companies to detect and fix security
vulnerabilities for 4-5 years and have learnt quite a lot on this. Just some
things that would pop my mind:
- You must integrate the authentication into the ASF LDAP (Setting up a
separate one is out of the question)
- You must install the good patches as soon as possible and skip the bad ones
(Usually you have a test-environment to test updates)
- The credentials for accessing the ASF LDAP must be available on the system
(Don’t think Infra would like that)
- To publish artifacts to the ASF Maven repo, credentials of someone must be
provided (alternatively Infra could create technical users, but this will not
happen and I think that’s good that they won’t do that)
- To commit and push to the GIT repos the same applies as for the Maven repos
- Unfortunately, there is no “setup.exe” to install Security. It’s why a good
system Admin is worth its weight in gold (At least this was one thing I learnt
from my Professor). Every “shortcut” opens dozens of possible security holes,
you have to think about all of them.
- I bet if we were to switch to the “self hosted mode”, I would start voting -1
setups and decisions to block unsecure shortcuts, we would have a whole new
dimension on discussions here … not looking forward to that.
- If we run our own JIRA/Wiki/Website … we need backups and people skilled
enough to restore them after a catastrophic failure.
I guess most things that people are complaining to Infra about are probably
sort of the same type of problems we were having in the past. The thing is that
we wanted them to provide a build that fits the build we created. What I did,
was to simplify the build and create a common ground with Infra towards what’s
possible and what’s not and to adjust the build accordingly. If all projects
would use this type of dialog I guess, we wouldn’t have this type of problems.
What I would be willing to support is something down this path:
- Have the option to do (micro-) donations directed at the ASF that go into an
ASF managed account that we can distribute funds from
- A ASF Community-Tax has to apply that will make sure that the other ASF
projects don’t dry out financially
- We continue to use the ASF systems (Jenkins etc.)
- We use our funds to pay for one or multiple Jenkins agents that only the Flex
project can use
- Funds should never be used to pay for development/documentation/testing work
done on the project
Right now, I don’t know how we could make sure we are able to commit to GIT or
upload to maven without having the credentials on the VM we control …
Chris
Am 13.02.17, 07:05 schrieb "Alex Harui" <aha...@adobe.com>:
On 2/12/17, 4:25 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi,
>
>> Don't worry about finances, that's an ASF corporate question - to start
>> with, look at the directed funding proposal from the past President's
>> report in a board report.
>
>Alex’s suggestion as I understand it doesn’t seem to fit with the above
>experiment. Alex (please correct me if I’m mistaken here) but you’re
>looking for lots of small donations from many (possibly unknown) people
>rather than a single largish donor up front right?
Yes. I explicitly asked on board@ if I should continue to pursue this
idea even though it doesn't close to the 50K threshold mentioned in the
minutes and they said to go ahead. My takeaway is that the Prez report
was an opinion and not a policy. We need to solidify a proposal. They
might still say no, but right now I am an additional person investigating
directed funding options so they don't have to spend time on it. Maybe we
will come up with a good new idea. Or not.
Thoughts on other responses:
Fundamentally, regardless of Apache "direction", it occurs to me that it
is just plain wrong for Flex to be a net consumer of resources at Apache.
Really, all projects should be striving to be providers, by bringing in
enough donations to not only pay for ourselves, but also have some extra
for the other projects that need help. So I don't know how many of you
contribute money to the ASF and are willing to go public about it, but
before I go asking for a new VM from Apache I'd want to know we are
putting enough money in to effectively pay for it. And that's the problem
for me: if I write a check to the ASF, I can't currently earmark it for a
VM for Flex.
To me, the "Donate to the ASF" goal is different enough from the "Donate
to Flex" goal that it seems worth trying the latter. The "Donate to the
ASF" goal is about altruism for open source software in general. I'm
willing to give a certain percentage of my salary to good causes. But I'm
willing to give more to help my community, because I hope to get payback
in other ways.
So sure, there may not appear to be a need to do something like this now
since things are working. But just like you re-do the roof on your house
before it starts to leak, I want to find out what it would take to track
if we are paying for ourselves. Would it require an actual separate bank
account? Don't know. Would we get a "cost center" like in my $dayjob?
Don't know. We'll find out if we get that far.
I guess I didn't understand what Justin meant by "Professional Services".
The ASF doesn't want to pay for folks to write code, and I think that
include documentation as well. But could the collection of lots of little
donations require that we pay for professional accountants? It could.
The ASF already pays for professional financial management.
If some people want to collect money to pay folks to write documentation,
I think that needs to be done in a separate effort.
CI on builds.a.o is working nicely. But what changes would be required to
move it to apacheflexbuilds? Isn't there something special about
builds.a.o and its capability to publish Maven artifacts?
Other folks on past directed donation threads on other ASF lists have
expressed concerns about rich projects and poor projects. IMO, the ASF
could implement a graduated tax. Right now they are just saying 15%, but
they could raise it in general or tax higher incomes more. In the US,
income is taxed on a graduated basis topping out at 35% or so. I think it
is much higher outside the US isn't it? 15% may be too low. It just has
be the right number to fund what needs to be funded without discouraging
donations. I'd bet the higher income projects are also big consumers of
resources so there'd be enough money from the taxes to pay for the "poor"
projects.
We would have to have language that says that your donation is not
guaranteed to be used for what you want it to be. I think many
fundraising manage to get this wording right enough to be successful.
We'd probably have to have language that if money doesn't get used or the
project goes to that attic someday that all funds will go to the ASF
general fund.
We would use the same decision making process to decide what to spend
money on as we do for deciding what code donations to take and other
project-level decisions.
I'm hoping that we don't have to do the same things that Infra currently
does. I believe my Azure account pays for a lot of what Infra does.
Azure folks keep the servers up and running. "All" we have to do is
install and maintain apps like Jenkins which several of us have already
figured out how to do, and maybe some day JIRA, maybe a web server, who
knows. I already learned how to set up JIRA when migrating the Flex bugs
from Adobe. These things feel more like application usage than "Infra"
stuff.
We will have to have security on everything whether it is server-side or
client-side. We will be writing a ton of client-side Javascript, so we
are probably way more exposed there.
A goal of the experiment is to see if we were to move all builds outside
of the ASF, who would save time and money and who wouldn't and would there
be any advantages or not? If you follow build@ I see lots of issues there
that would be solved by decentralizing builds to a VM per project.
I'm not in a huge hurry to finalize a proposal. I'm interested in
collecting more opinions, especially thoughts on whether folks have been
contributing money to the ASF today and whether they would contribute more
if there was a "Flex" bucket. We have a tangible expense in the Azure VM
that we could pay for via these donations instead of asking the ASF to add
to their expenses to provide a VM for us. The VM bill is small:
<$50/month for a 1 core 1GB Windows VM. But still, if I can at least
unearth the logistics around directed donations at this level, I will have
provided the greater ASF with some useful data, and if it turns out to be
practical, then we will have contributed more money to the ASF than I
think we do now.
Thoughts?
-Alex
