Project & Governance

I’ve seen a lot of good conversation here, but not too much about the second question of how a foundation would fit into governance structures and requirements for a foundation’s operation, so I wanted to offer some of my own knowledge and experience with foundations.

Short version: Foundations have bunches of legal requirements, especially if they want to be tax exempt (and/or if they want to be considered charitable). Lawyers are necessary. I can see many different roles, such as handling budgeting, contracting/license use agreements, and even just paying to maintain domains and spaces. A foundation (if established under certain criteria) would also provide a place for those who want to offer support via treasure, rather than talent or time (if, perhaps they lack those things).

Long version:
Broken into sections:

  1. Brief on Types of Foundations
  2. Brief on Foundation Governance & Management
  3. Potential Use Cases for a Foundation within the Project

Note: My knowledge is USA based, so its usefulness may vary. I am also going to comment generally on ‘a foundation’ not specifically on the Geeko Foundation, since I don’t know very much about Geeko’s structure other than that I do strongly support the work they outline.
My background: I’ve been on boards and am currently involved in the creation of a charitable foundation.

1. Types of Foundations
There are multiple types of foundations. Foundations can be a not-for-profit organization (such as a not-for-profit company) or a charitable organization. The difference is whether or not the foundation is subject to taxes (particularly income taxes) and how much those taxes are.
Foundations can be organized in multiple ways as well; typically they are either organized as a corporation or as a trust. In some ways (and countries/states), corporations are better, since they have perpetual life in most places and allow for limited liability of board members (legal things that matter). But trusts have advantages too.

Foundations of all types can pay staff, make grants, and support operations of a charitable program or set of programs.

1a. Charitable Foundations
Charitable foundations (aka Charities) offer an advantage in that they are tax-exempt and can provide a tax-exempt option for supporters who want to donate. However, they typically have stricter operating requirements than non-charitable not-for-profit foundations. These operating requirements include how they can collect funds, what they can spend funds on, and often how much of their funds must be spent annually.
Charitable foundations also come in two basic sub-flavors: Grant-making, and Operating. A grant-making foundation supports its causes by giving grants to other parties; i.e. writing a check with conditions about what it is supporting, often to another charitable organization. An operating foundation exists to support its charitable cause; i.e. a museum that uses admission fees, donations, and endowment to pay its electric, water, lights, staff, etc. Operating foundations can make grants to other entities, but they do not typically have the sort of ‘minimum required amount of money given to other charities’ that grant-making foundations have; instead, they have a minimum amount they must spend on the operation of their charity.

In the US, charitable foundations also have two more sub-flavors (for anyone still following this binary tree there are at least 4 types of them). They can be private or public. A private charitable foundation requires only that the founder(s) legally establish the foundation and appropriately give away the money (via grants or operating). To qualify as a public charitable foundation in the US requires a declaration of intent, five years (or more) of specific operating ways, and a certain amount of fundraising from non founder parties (and maybe more conditions).

Charitable foundations are also subject to lots of rules regarding who they give money and support to, if they want to maintain their tax exempt status. (For example, there is a rule about not supporting terrorism.) These rules may cause a foundation to need to exercise more control over the Project in some way(s). It would be good to get some legal advice on activities that could/could not be supported before this road is followed.

2. Foundation Governance & Management
Foundations are typically managed by a Board. In the US, if the foundation is a corporation, it will be managed by a Board of Directors; if it is organized as a trust, it will be managed by a Board of Trustees. There are subtle differences in the legal responsibilities of these two types of individuals (Directors & Trustees). In other countries, this can be different. The Board is required to have regular meetings (sometimes just once a year) to conduct the business of the foundation.

Foundations are typically required to have bylaws and/or other guiding documents upon their founding. These guiding documents will include things like a mission, how the foundation operates, how board members are selected, and more. In addition, many foundations choose to craft a strategic plan, an asset allocation plan and other guiding documents.

Among the duties of the Board are managing the foundation’s assets. This can be delegated to professional asset managers, or, if Board members have the correct expertise, can be conducted by the Board or a subcommittee. Legal responsibility is a factor here too.

The Board may also hire and oversee project directors and others, either directly or through project directors. The Board bears the legal responsibility for the operations of the foundation while the conduction of the operations may be carried out by hired or volunteer staff.

3. Foundations & The Project: Potential Use Cases & Things to Consider
A foundation could serve in many different roles, one or all of the following and probably a bunch more I’m not thinking of. To start, I’m going to make two lists, one for non-profit (but taxable) foundations, and one for charitable foundations.

Non-profit, but taxable, foundations could:

  • Serve as an operating organization that manages the budget, licenses, trademarking, and domains, maintaining space for the Project to conduct development. If the foundation’s only role is to maintain space, this would need to be clearly delineated that they host a web space, but don’t influence inclusion or development of the OS or other projects.
  • Serve as an operating organization that also strategies about the Project and perhaps even hires/contracts for support to complete certain projects when funds are available.

Charitable foundations could:

  • Support the Project through provision of grants to host space, complete initiatives, etc; without hosting or maintaining the Project.
  • Support the Project with direction, managing funding for trademarking, domains, space, and so on, including contracting for support.

One thing to keep in mind is that, due to the requirements on charitable foundations, it may be the case that a charitable foundation needs to exert more control over the Project (e.g. to insure it isn’t including malicious software, or accidentally violating any rules) in order to support the Project fully. On the flip side, being a charitable foundation, it would have some significant tax advantages and be eligible to receive other grants and charitable donations, which could be a huge plus.

Some things that should be done before decisions are made on this matter, in no particular order:

  • Determination of what types of control we can accept and not accept on behalf of a foundation. E.g. could we accept it if a foundation had to have the final say over everything in the official repos? Does our answer change if unoffical repos can be hosted, or if they have to be offsite (i.e. a different webpage).
  • Additional research, with legal assistance, into the types of activities that different foundation options would be able to engage in.
  • Research on foundation structures and types of rules in various countries for determination of host country.
  • Consideration of the bylaws, board, and how founders would be recruited (starting a foundation requires time and money).
  • Consideration of how assets will be collected and managed, and how an income stream will be generated for the continued work of the organization.

So, that was a novel, thanks for taking the time to read it! Just some ideas to keep in mind for the foundation discussion.

2 Likes

I suppose some of you are in vacations… Ok.

Some days ago in the news from openSUSE (https://news.opensuse.org) Douglas DeMaio published an article about YQPkg, a new package management tool. Ok.

In this article, DeMaio talks about the program, as any could expect, and he links the github page. But in the linked page Stefan Hundhammer talks about his motivation.

YaST will be phased out soon in favor of Agama and Cockpit, and then there will be a huge gap between low-level zypper in and high-level application installers of the desktop environments;

YaST was rewrited in the last years, so it will be phased out? YaST is one of the openSUSE most valued proyects. When I talk with someone to try Leap or Tumbleweed, I must say “don’t worry, YaST soon will be dropped?”. How can someone learn something about openSUSE that will be working in a few years?

I insist. DeMaio is not zdnet or phoronix. Even Stefan Hundhammer knows openSUSE. Where we go?

This isn’t really the place for this discussion, but yes, YaST is going to be deprecated, sooner, rather than later.

1 Like

I’m sure this isn’t the place to debate how, when, or whether it’s appropriate. But it’s just another example of how we can hardly tell anyone why they should use an openSUSE operating system.

I mean, what do you think a poll on this very forum with these two questions would do?

  1. Did you know that YaST is going to be removed?

  2. What is the YaST tool that you would most recommend to future openSUSE users?

And I’m not trying to debate YaST, I’m just saying that it’s just another example of how not even people here know what openSUSE is all about, let alone be able to explain it to someone “from outside”.

Quote from en.opensuse.org:

Project
Project
The openSUSE project is a worldwide effort that promotes the use of Linux everywhere. openSUSE creates one of the world’s best Linux distributions, as well as a variety of tools, such as OBS, OpenQA, Kiwi, YaST, OSEM, working together in an open, transparent and friendly manner as part of the worldwide Free and Open Source Software community.
The project is controlled by its community and relies on the contributions of individuals, working as testers, writers, translators, usability experts, artists and ambassadors or developers. The project embraces a wide variety of technology, people with different levels of expertise, speaking different languages and having different cultural backgrounds.
Have a lot of fun…

No trace of Agama or Cockpit.

This is the kind of thing we need to do better. Maybe not so much the decision, which I’m sure in this case as in others there are very good reasons for. But the communication, the timetable for doing it…

2 Likes

@karlggest who is the we you refer too?

If I use a package X and it’s broken, I branch it, update, patch etc to get the package working, then I test and submit… Likewise I see package Y isn’t (or someone posts in the forum about it) available, I will package if I can and submit/maintain.

I have no interest in marketing or wiki writing (well I have done some for RPi3’s), but if I see something that’s no quite right I can always fix there and then, the reason it’s a wiki?

If this information is important to you, research and update the wiki as needed?

I think Karl’s point in bringing it up isn’t necessary the specific example, but the broader issue of things like this not being communicated in as open a manner as they could be.

It’s difficult to follow everything going on in the project - like Karl, the first time I heard about YQPkg and the phasing out of YaST was in the news article he referenced. That seems like something that there maybe should have been (and perhaps was and I at least wasn’t aware of) some discussion about.

There are a lot of moving parts in this project, and changes that affect the main distros (at least) seem like something there should be more awareness of. Maybe something that’s in a published roadmap?

@karlggest - is that what you were getting at?

1 Like

Yes.

Beyond the chameleon, which is not ours but SUSE’s, we don’t have much of an identity.

It’s not so much about whether there are few or many changes, but about the fact that we don’t even know what’s going on in openSUSE, much less attracting new users.

I insist, if we do things “for developers”, in the end the distribution will only be used by its developers.

People knows what Debian offers. People knows how Mint works. Even Fedora is well known by people. But what people knows about openSUSE? How can myself post in Mastodon or my blog “hei, come try openSUSE”?

2 Likes

OK, so rather than focusing on specific examples, let’s see what we can do to build a framework that addresses the issue in a more general manner - I like to think of starting with an “ideal” that would help.

For example, I think an easily findable roadmap that details what changes are planned/anticipated (which I don’t see at openSUSE:Roadmap - openSUSE Wiki) would be helpful. Ideally there should be a list of components and the dev state for those components. Maybe some kind of report from Bugzilla (or wherever development planning takes place, if not there) would be useful.

Maybe there are ideas we can use from Debian/Mint/Fedora/Ubuntu that would make it clearer.

1 Like

Samples are needed to recognize the shape of the problem. But the idea is

IMHO we need sound, be like a project.

That’s regular work. So I could think the main idea of doing that is that all can use it, and nobody can do it if they don’t know that it works. Even KDE is trying to announce all they are doing, even if regular users can try the newer things.

Knowing that there are new programs or utilities is useful, but these samples aren’t about that. They are about something more important.

Maybe language issue, I am not sure about you mean with this.

I do that. But it’s imposible know every change, every motivation. I can even follow all the talks for each project over several years, and if I miss exactly one I might miss something important. I can follow every mail-list and if one single thread goes to spam I might miss something important.

Be part a project includes think about the project itself when you are doing things. IMHO we need to stop doing things merely because we can, and start thinking about doing things because we want. And stablish a gobernace system to do that.

Even more IMHO, we should focus on being more successful than projects like Debian and its derivatives. The point of having good products and “spreading Linux everywhere” is to get people to use them.

@karlggest To me, Governance == road blocks, red tape etc. Sure there are areas in the Project that this is needed for example Infrastructure, but still wouldn’t call it Governance :wink:

For example, tomorrow Leap 15.5 goes end of life, there has been a notice about that (News, ML etc), so tomorrow Forum Staff will change the leap-155 tag to leap155-eol we will still get users whom have not seen, or new users arriving and having issues, only to find out it’s end of life and no longer supported.

How would any form of (to use your term) Governance model cover this? It can’t, won’t and should not be mandated, best the person(s) responsible can make the notice at the appropriate time (which they do) and move on…

Any governance system would have avoided the twists and turns that occurred with Leap 16.

Even the simpliest governance system would have avoided that. We rely on automated systems that change labels but don’t really tell us anything about ourselves. There’s Leap 16, will there be Leap 17? How long will (partial) support for Leap 16 last? Partial, because every 18 months you have to migrate. Haha, I’ve migrated a server to Tumbleweed because Leap dropped some version of Python support and I’d have to compile it myself.

@karlggest I doubt it, as always, those that do decide, I’ll support what I want to support, in any release, no governance model is going to tell me what to do, plain and simple.

My acceptance to maintain something in a release is based on me hitting a submit request to review from Factory to say Leap 16.0, at that point I agree to maintain for the lifecycle of Leap 16 series (CVE’s and bug fixes only, version updates on a case by case basis).

So, why move, there are a plethora of options available in the containerization area?

Yes, but in order to do that, we need some specifics as to what to do. We can’t just say “be like this”.

The purpose of this discussion is to build some proposals to take to the board. Proposals need specificity about solutions, not just a list of problems.

I mean, these proposals and discussions aren’t for the board. We don’t have the authority to make a decision about anything like this.

These proposals are for the membership, for consideration. The Board currently exists only to foster communication, as best we’re able to.

1 Like

Right. Don’t know what I was thinking earlier. Hadn’t had my tea yet. :slight_smile:

Well, we are talking about how this should work. Even if at the end nothing changes.

Why do it then in first place? If you only wants to maintain something you can open your own repo at github or codeberg. What is the sense of doing in the community?

I’m not developer, but if i was it, the first thing for me would be to make my software as useful as possible. The more people used it, the better, and the more people were interested in it, the better.

So you’d rather spend hours, days, months, years, on a project that you might not even end up using than, say, simply letting a communications team know that it exists. Aha!

Tasks for a hypothetical governance system:

  • Well, at least we need som.eone or something knowing all is happened in the main projects at least too. And knowing what projects are the main projects
  • We need a good place to discuss where we want to go in, say, the next 3 years at least. Even if you have to adapt later or even change your mind because there’s no one who wants to take charge of certain things.
  • IMHO most of the needs we have are about how the Community communicates with each other, including the development groups (and these with each other), and how we see ourselves and the way we tell the outside world how we are.
  • Coordinate projects and communication: someone needs to make sure that if a major project is underway, there is an appropriate communications campaign, or ask those in charge of communications to put one in place. And take care of resources.

Going back to the Leap 16 example, a “let’s do Leap 16 just like Leap 15” instead of “let’s do Slowroll just in case we don’t do Leap 16”. (And I think Slowroll fits in with Tumbleweed, I don’t mean to discuss it, just give an example of something that happened even if few people in the development groups thought of it that way, which I don’t know.)

Well, we need to have some agreement about the real problems. Maybe some of things I say here could be fixed with a trivial changes.

The simplicity of participating in the projects is fine. But without coordination, without communication and ultimately without a common project, they are just a bunch of loose pieces that some of us have been using for many years and others who are the ones who do it and little else.

1 Like

Hi, because I want the packages I use to have had additional eyes on it and ability to deploy across multiple releases, so Factory First. Likewise I don’t publish anything in my $HOME repo so it’s not added by users.

I see plenty of communications within the areas that contributors to openSUSE use about what is happening for the likes of GNOME, Aeon, Factory, Infrastructure etc…

1 Like

Yes, I can see the resul, yes.

Sure, but from the standpoint of the issue you describe, I think it’s fair to say it’s more systemic than just a one-off issue of “we didn’t have any clear communication about the planned deprecation of YaST”.

So probably a good approach here is to include, in a governance proposal (or section proposal) something about release planning, roadmaps, and visibility on the wiki.

Exactly - on this, we’re agreed.

1 Like

Communicate with whom?