I can try to help… but not sure how much time I have given that I am running three initiatives already. But happy to be present and help - let me know!
Is this initiative about raising funds for the Foundation, or about the fundation helping raising funds for community-led projects?
I think this is a false-dichotomy. A lot of the funds that enter the Foundation go back into the wider community as things like events, internships, travel sponsorships, and infrastructure, as well as what I think of as “things no one else wants to do.” The latter is work the Foundation takes on because no one else is particularly excited to get it done, and it needs to happen. Additionally, all of GNOME is community led. There is no single project leader, and the Board itself is elected from among members of the community by members of the community.
That being said, I am interested in building up our grants program to specifically address projects in GNOME that just need funding to get through the next step.
Oh this is me poorly explaining myself again
I know some developers in the community who would be interested to raise funds so they can work full-time on their project. Those people are not one person but a team, and they would need a legal entity to get the money from the fundraising campaign and distribute it between the members of the team.
The best solution today for this is quite cumbersome, since people need to create a legal entity. I’m wondering if the Foundation couldn’t play a role here? And if the Foundation can play a role as a legal entity to receive the money of the fundraising campaign and distribute it among the folks involved in the development, could it play a role in advertising the campaign too?
Finally I understand what the Foundation is all about. Thanks, @mollydb.
The Foundation as a fiscal sponsor is an interesting question I’m not currently qualified to answer.
If you know people who feel like they are at a point in a given GNOME project where funding is what is needed to take the next step forward, I would appreciate speaking with them about the project(s).
We’re also trying to collect “fundable projects,” which are projects that are in that place: where they need funding to move forward, and have concrete plans and steps ready to go once funding is secured. There is a wiki page where projects can be added: https://gitlab.gnome.org/Teams/Engagement/Fundraising/-/wikis/Fundable-Projects. When we see grants that match projects, we’ll be able to apply for those grants.
I recently worked for a few years with an NGO on tech grants and fundraising, I’m happy to help in any way I can.
Can you provide some examples for this ?
Sorry, it’s not clear. Does this apply to new / recent projects only or also to existing projects which are not getting enough attention, maybe, because the project developer (s) / maintainer (s) feel that their time and efforts could be more rewarding ( financially or otherwise ) elsewhere, which is perfectly understandable.
E.g. For example,
brasero ( CD / DVD writing application for GNOME ) has not been getting any attention for the past few years. Honestly, I feel it is an engineering miracle , that it still keeps working with little to no maintenance in the last few years. Kudos to ABI / API keepers. It crashes right out in latest
Arch Linux though. I do understand that physical media is not being used so widely these days, still no maintenance for years is not good. I am sure that there could other apps with similar stories.
I do understand that GNOME is volunteer effort for most part, and I am a very strong believer in volunteer contributions. But, maintaining projects is a different story, and doing it over a long period is a tiring and mostly thankless job ( courtesy: @ebassi ) . That could be one of the reasons for the maintenance story of
So, I have a couple of questions here:
I am honestly interested in knowing the foundation’s take on apps like
Does the foundation reward ( financial or otherwise ) project maintainers who have done good job of maintaining their projects, for a reasonable amount of time ?
Examples of work I identify as “no one else wants to do”? I think some key examples are things like the annual report, tax preparation, and taking notes at meetings.
- I don’t understand what you mean by “take on.” I think it is unlikely a current Foundation staff member would begin to develop or maintain it.
- This is a difficult question and depends on what you mean by “reward.” The idea behind the grants program is not that the Foundation will pay people, but we will apply for grants for projects that are in positions to apply for grants.
There will be a meeting on September 22nd at 16:00 UTC to discuss the fall fundraiser. Hope to see you there!
Sorry, what I meant was “what is foundation’s stance on GNOME apps / libraries”, which are not getting enough attention for various reasons:
- Maintainer is unable to find enough time for the project.
- Maintainer not available for the project.
- Too many open Gitlab project issues with 1 ( or 2 if lucky ) developer / maintainer working on a relatively large code-base.
I just had a quick look at Foundation board meeting minutes, and I don’t seem to find anything in this regard. Might have missed it though.
As a foundation we’re now getting regular donations:
$823,412 - FY 2018
$632,914 - FY 2019
Source: GNOME FOUNDATION ( 2018–2019 ANNUAL REPORT )
which is one of the major sources of income for the GNOME foundation. In such a scenario, we should have a strong policy on how much we pay attention to user’s feedback ( say, after every GNOME release ). Do we have a survey / feedback page available to users to give feedback ( say,
Brasero was highlighted as an example, since it is a highly user visible app, which is not getting much attention lately. And it doesn’t reflect good on GNOME, when it is not maintained for a long time. There are issues and comments in Gitlab for brasero for anyone to take a look at the state of the project.
As a foundation primarily driven by donations, GNOME has some commitment to users and hence user-visible apps ( Audio / Video / Imaging / Editing / File manager / Software / Browser ). Gnome 3.36 and 3.38 have received good reviews, but still there are old pending issues, which keep coming in the comments release after release ( For eg. Nautilus desktop icons ).
I have been keeping a watch on Linux Mint for quite sometime, and it is pretty impressive how they work closely with their user base. Same with Elementary / Zorin / PopOs / Manjaro, though not to the extent of Mint. Sure, they’re distros, and GNOME is not ( yet ), but still it wouldn’t hurt to listen to user’s feedback about GNOME.
I would recommend a new position in GNOME BoD whose primary responsibility would be to act as a bridge between the GNOME user community and GNOME development community, and ensure that any valid and important suggestions from the user community gets addressed as part of every GNOME release.
I would describe this conversation as “above my paygrade” and redirect you to the Board.
Info on the Board of Directors is on: https://www.gnome.org/foundation/, though it doesn’t look like there is a single email address to contact them. I’m not sure the best way to bring new proposals to them though. Wish I could be more helpful!
Agenda and notes: https://etherpad.gnome.org/p/fwg-22-9
Next meeting will be 06/10/2020 at 16:00 UTC.
I was thinking something like, goodies from GNOME shop for a start, as a token of appreciation for maintainers who have completed 3, 5, 7, 10 years.
Maintainers who have completed 3 years, can have “Senior Maintainer” badge in gitlab / discourse
Maintainers who have completed 7 years, can have "Experienced Maintainer" badge in gitlab / discourse.
It doesn’t cost much, but would mean a lot if I were a maintainer.
@sri and some others are working on a badging system, and might have something to add.
We’ve been evaluating badging systems just to gauge their effectiveness in an organization - but we won’t integrate one until we understand how it works and how it could conceivably making volunteering on GNOME projects a better experience.