This is a placeholder topic to address an important subject that came up first in the Forge Federation chatroom. For now copying comments from Social Coding chat.
@room, a fascinating discussion is ongoing on Forge Federation general after it was found that for the migration of the Blender.org project to Gitea NDA’s were signed. This creates a somewhat unclear situation what this will mean for Gitea and anyone depending on it (like @dachary whose forgefriends.org is a fork of Gitea). NDA’s and Contracts with customers are common in FOSS and they are a means for hard-working maintainers to get some income from their work. But there should be best-practices to follow… I will copy my comment from forge federation chat here, as this is a touchpoint to Social Coding…
Copied from Forge Federation General:
Wow, this is a fascinating discussion. And I wonder if there’s any best-practices to derive from it for inclusion on Social Coding website. I understand all angles being discussed here, and such dynamics and various forms of power play, proper governance as well as abuse… this must be a common theme in FOSS.
I wonder if any of you are willing to post about this in Challenges or Best-practices categories on Discuss Social Coding. There’s already a challenge created by @realaravinth on Monetizing FOSS (a broad subject that may lead to many related best-practices), and one on False Entitlement (where there might be a relationship to high profile team members and conflicts of interest).
@dachary lists some serious aspects of how all this leads to uncertainty and doubt, potentially puts a wholly different light on the nature of his collaboration with upstream.
What I also wonder, hearing from @algernon and @wiki is if there wouldn’t be a Best-practice where a good middle ground is found. Liking having clear upfront rules on the kinds of NDA’s and Contracts you accept. This might state that, while you won’t divulge internal customer details, you are fully open in public communication on anything that translates to code, like feature / functionality / design, etc. Plus transparency in that you are working for the customer in the first place, and maybe that the project tracks a list of customers that were served in the past and with what features. Also the governance rules might state that if you are not honest in disclosing who you work for, and that comes out, you are not electable as owner/maintainer in a next voting round.
I would be delighted if anyone would take the time to write something to the forum. Social Coding Movement isn’t yet ‘officially’ launched, but it will only be a success if it is crowdsourced. If things are OT here, you can discuss on Social Coding chatroom.
Note: The particular case that is topic of discussion i.e. Gitea + Blender is irrelevant and should not be named as an example in any further elaboration of Challenges and Best-practices.
Some guidelines could be helpful, yes, as long as it is understood that they’re just that, guidelines, and may not be applicable in every situation. I mean, deviating from the guidelines should not necessarily be considered a red flag, or Wrong.
While I agree with the sentiment, I heavily disagree with the “implementation”.
In my opinion, it is far more productive - and far less hostile - to have guidelines on project governance, rather than on how individuals conduct business. Providing guidelines how to handle conflicts of interest are far more useful than trying to make sure there are none. There will be conflicts of interest, and that is fine, as long as they’re resolved in a reasonable manner.
For the remainder of my post, I will assume that we’re talking about owners, maintainers and other project officials, rather than any random contributor.
As a maintainer, there will always be conflicts of interest of some kind, whether we’re talking paid work or personal goals, desires, ideas. The guidelines should help resolve those conflicts. Transparency can play a crucial role in there, but it isn’t enough in and of itself, nor is it always mandatory.
For example, if I were to contribute a feature to a project, of which I am also a maintainer of, and I follow the usual procedures, get the contribution appropriately reviewed, vetted, refactored, changed, whatever - like with any other contribution; does it matter if that was contract work, or if I were scratching my own itch?
Nope. Procedures were followed, project goals and principles were not compromised. The company paying for the work may wish to disclose they paid for the work, of course, in which case disclosing that information is the way to go. But if they don’t care, or if they wish to remain anonymous, I do not see a reason to encourage full transparency anyway. It doesn’t affect the end result.
If the company sponsoring the work decides that they don’t care if the contribution gets merged, and they go only as far as dumping the code developed in-house, project maintenance guidelines can take care of that, too. It still goes through the same scrutiny as any other contribution, and the project may decide not to merge it, or merge it in a different form, or partially, or whatever. Same thing may happen if the contribution was a personal itch scratched, and the contributor just wanted to get things done and not care further and move on.
The guidelines should be about resolving conflicts, tips and best practices about project maintenance, rather than getting down to the level of guiding how one does business.
In general, a guideline such as contracts having a clause that contract work will still have to go through the same procedures if being upstreamed as any other contribution, is a reasonable one. That does not require disclosing that the contribution is contract work, or who it is paid by. What it requires is that maintainers live up to the trust placed in them, that they follow the same procedures, adhere to the same standards, whether they’re dealing with contributions from their clients or employer, or from anyone else. It’s more about project governance, project-wide procedures, than about individual way of work.
Helpful tips for individuals about how to achieve that are useful. Like, don’t sign contracts that say that code developed in-house must be merged upstream as-is. Make sure that the company you contract with understands that this is a FLOSS project, with governance rules and guidelines in place, and they will have to abide by those, too. Make sure they understand that just because they happen to contract maintainers, they do not get a shortcut. It will make their job easier, because the contracted people can better guide them to achieve a result that is suitable both for the project, and for the company. That’s the added value, not the fast-tracking of code dumps.
It’s also reasonable to ask maintainers that if they accept longer-term contract work, they try to work with the rest of the project (including significant downstreams) to discuss roadmaps and the like. Sometimes that’s possible, sometimes it is not. The best course of action is to discuss roadmaps anyway, as a project. Whether particular items are suggested by contract work is largely irrelevant, as long as they’re put on the roadmap with the agreement of the wider project.
There will always be cases where a contribution is developed behind closed doors. Whether that door is a big company door, or a garage door of a random contributor, matters little. What matters is the procedure followed once the contribution is made: is it vetted, reviewed, refactored, subjected to the same scrutiny as anything else? Is it rejected if it is not desirable for the project? If yes, then it doesn’t matter how the contribution came to be.
It doesn’t even matter even in the case where usual procedures are not being followed, or when project goals or principles are compromised: that’s a situation that shall be handled the same way regardless of whether the cause of it is contract work or something else.
Of course, there’s a risk of an entity just paying all the maintainers to gain control over the project. Again, that’s something to handle at a project level, rather than on an individual level. If there are clear procedures to handle that situation, to resolve that conflict, then the procedures are good. Policies regarding individuals do little in this case.
In summary, the guiding principle should be that the project be developed in the open, to the extent possible. To prioritize project-wide goals and values. To follow the same procedures, apply the same level of care to every contribution, every work, regardless of how those came to be. This does not require full transparency. It does need some level of it, and the more the merrier, but as long as the trust placed in maintainers is maintained, it’s fine.
Mind you, these are my personal opinions, based on my personal experiences with the projects I worked with or maintained. In most projects I worked with, the basic stance was that we trust maintainers to keep the project goals in mind, and strive towards resolving conflicts, rather than plow one opinion or the other through. If that trust was breached, maintainers had their privileges removed.
On the other hand, this is a delicate topic, with wildly varying experiences and expectations.
@algernon This is very well put and after taking the time to read it thoroughly I find it is both insightful and useful. It would make for a great standalone blog post.
I specially like how you describe, with examples, various situations that could be seen as problematic although they are just widely spread and normal. Here is another one: when a person engaged in a project has an idea and thinks about it during weeks without talking to anyone about it. The idea incubate in their head, in a 100% secretive way… and it’s perfectly fine That’s just the way human being engage in a creative process.
It is sometimes not trivial to see when a conflict of interest manifests itself. It took centuries for laws to be applied to politicians forcing them to give up long established habits of abusing the power given when elected to further their own agenda. A line had to be drawn in the sand to define what a conflict of interest is.
In the context of Free Software projects it indeed has to do, first and foremost, with project governance. If there is no project governance there cannot be any conflict of interest. But when a project governance is adopted, the people and organizations that are empowered can have a conflict of interest. A very simple example is when a self proclaimed community led Free Software project has a democratic governance and an elected leader. If the leader secretly concludes a business transaction in the name of the Free Software project and derives an income that they keep for themselves, there is a conflict of interest. The leader used the power granted to them by the project governance to further their own personal interest, misrepresenting the project as being under their exclusive control. The contract and financial transactions are with the leader and evade the democratic governance the leader is expected to uphold.
As you very well know, I’m a huge fan of transparency and all the benefits it can bring to a project. I advocate for governance where transparency is expected from members (such as the one in place for the Hostea project). But only when they engage in activities in their capacity as members of the projects. They have to choose between doing whatever they want under their own name. Or acting as members of the project with all the benefits it brings them and being transparent.
This however leaves a gray area where projects members indirectly or implicitly represent the project or are perceived as members of the project. It is often difficult to see that clearly and pushback from other project members may be necessary to realize a line is crossed. To give a concrete example, part of my income in 2022 is indirectly derived from my activities in the https://forgefriends.org project. I published a declaration of financial interest because it may be useful for other project members to understand how I behave in the context of the project. This is the kind of clarity that I would very much like to have whenever I find myself participating in a Free Software project on a daily basis.
Politicians and centuries struggles to contain corruption again gave us useful framework to think about this gray area. In particular members of the parliament in Europe (and presumably in other countries):
…are required to declare their financial interests or assets that could create a situation of conflict in the performance of their duties.
That’s just the way human being engage in a creative process.