On 3/3/22 3:20 PM, Matt Sicker wrote:
I'd like to see a better solution proposed for maintaining vendor
neutrality while funding the individuals working on the project. If
every workable solution is denied, then the only people who can afford
to work on Apache projects would be rich people, retired people, and
those who are being paid by another employer to do the exact same
thing. In fact, this is probably relevant to the demographics here as
discovered in D&I surveys.
Umm, no.
1. We can all afford to volunteer our discretionary time as we see
fit. Not just rich or retired people have discretionary time.
2. Employers can support OSS communities by allowing their employees to
contribute as part of their jobs, but not in a "job shop" or directed way.
3. Employers can support OSS by allowing their people to scratch itches
directly.
I have personally done 1 and enabled 2 and 3 for 20+ years now. I think
1 and 3 are really what built the ASF. People working on things that
they are actually interested in and scratching their own itches leads to
great software that developers love to work on and use. We don't need
to turn into some kind of job shop, glorified joint venture or
pseudo-employer to tap into the vast and renewable resource in the user
-> contributor -> committer pipeline. Getting more *user* employers to
support 2 and 3 is definitely needed, but I think it is smarter and
better for the long term health of the ASF to focus on that (and
removing barriers to entry in vendor-dominated projects) rather than
becoming a de facto commercial software company.
Phil
On Thu, Mar 3, 2022 at 4:15 PM Craig Russell <apache....@gmail.com> wrote:
I very much like the direction here.
One other top post that falls into item 2 (rules of engagement):
Apache does operate in the open with discussions, bug fixes, etc. all out for
anyone to see. Except for security issues.
I'd like to discuss how we treat committers with security privileges with
regard to third parties who may be contracting for the committers' resources.
Is it acceptable for committers to inform a third party of security issues
before the CVE is public because of their relationship with the third party?
Regards,
Craig
On Mar 2, 2022, at 6:12 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
Hi!
top-posting here, since I'd like to summarize a few points to see where we
can
take this discussion. Before I do that I wanted to thank Bertrand and Jim
for
excellent, short emails/summaries and also special thanks to Chris for an
extremely informative recap of his efforts.
Personally, I'd like to focus on 3 things. Please let me know if I'm missing
anything or you disagree:
1. building a robust list of what we at ASF perceive as potential value
that can be offered to *our* members, committers and contributors
by the 3d parties like Tidelift (again, I'm simply using them as an
example here -- anybody else would do just fine).
2. building a list of "rules of engagement" that we feel must be met
for these types of relationships to be compatible with the way we
govern our communities.
3. document all the learning, pitfalls, etc. that we've collectively
amassed by trying to solve this type of a problem on a one-by-one
basis.
To expand on those points: I really do think that 3d parties (if done
right) can take care of a lot of pain points for us. Again -- I'm NOT
saying that a magic entity like that even exists today (maybe Tidelift
is really not the right solution for us -- dunno yet) -- what I'm saying
is that I really would like to understand how that type of a service
should look like. Or take Jarek's example of ridesharing: most
of people focus on ridesharing companies just matching riders to
drivers, but that's just the tip of the iceberg -- ridesharing companies
solve huge amounts of arbitration issues (such as insurance, license,
etc.). Common folk don't get to see those -- but that's a huge value they
offer to drivers (and arguably riders) on top of just finding "customers".
Same with 3d parties for us I have in mind (see Chris's list of gotchas).
For now, I propose a few Cofluence pages under ComDev where this
type of information gets collected. I'll do it later tonight -- so feel free
to just add to this thread for now.
Once we've collected that type of info -- we can then sort of "evaluate
vendors" against that list and see what they are missing, etc. We can
even issue a wide "call to apply" for various companies if we feel like it.
Makes sense?
Thanks,
Roman.
On Tue, Mar 1, 2022 at 9:43 AM Bertrand Delacretaz <bdelacre...@apache.org>
wrote:
Hi,
Le lun. 28 févr. 2022 à 21:15, Jarek Potiuk <ja...@potiuk.com> a écrit :
...Proposal:
I think we all agree that ASF meets the criteria of Tidelift already.
Why don't Tidelift (in the places where open-source projects included are
listed) explain that ASF projects meet the criteria, and any one is free
to deal directly with the committers of all ASF projects directly...
I'd say we all agree that *in theory* ASF projects meet Tidelift's
criteria, quoting from earlier in this thread, with my own numbering
added:
Le lun. 28 févr. 2022 à 19:30, Joshua Simmons
<joshua.simm...@tidelift.com> a écrit :
...*What Tidelift expects from maintainers*Maintainers provide two
things to
our customers: (1) information (licensing details, context on CVEs) and
(2) continuity (comfort that the package is maintained and is highly
likely to
continue to be maintained). We also expect maintainers (3) to abide by a
Code
of Conduct....
I think for (3) we're good, the ASF will intervene if projects are not ok.
But for (1) and (2) I think the ASF *wants* our projects to be good
citizens, and we work towards that and support them, but entities such
as Tidelift or others could add value by measuring and reporting what
actually happens.
Does Apache FOO actually provide good information on security issues and
CVEs?
Timely response? What's their average/min/max response time, how many
"in-flight" CVEs?
Does Apache FOO release often enough? Maybe based on project maturity
categories, new, established, mostly dormant etc.
We could of course measure these things ourselves, and we do have some
data.
But I think having external entities provide factual data on how well
our projects are doing can be useful, and for customers of Tidelift
and the like that certainly has value.
Whatever mechanism our contributors use to finance themselves, having
information on which projects are most worthy of trust can help end
users select and finance the right projects and people.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
Craig L Russell
c...@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
