I don’t really get what that would accomplish? It would not really make pulling from github/gitlab easier I think?
It would make so that people with those accounts would not need to create individual Blender accounts to contribute on developer.blender.org. It is just a convenience thing.
2 Likes
I would like to add bundled add-on development to the discussion. Has it been considered at all when looking for a new platform? Should it remain as one repository with everything lumped in together, potentially with one main “issue” for each add-on to keep track of things, or should each add-on have a separate repo for its development?
5 Likes
Just wanted to drop a note here that I’ve been following the discussions going on here and am deeply thankful for the amount of insightful views that people are providing on all manner of aspects. Sorry for having been quiet about that so far.
A big part of what I’m doing is collecting and collating different concerns and considerations that people have about what is good/bad/ugly about the options that we have available.
I want to take a moment to address a recurring theme in the discussion above, however, which touches on the subject of licences and openness.
It’s no secret that Blender has a proud history and culture revolving being Open Source. This is true for Blender and its related tools and projects as much as is possible. This is of course not accidental.
For this reason, preference goes out to seeking solutions that are fully open source if those can be made to fit the needs of the development community. This is not an ‘at all costs’ approach, however, but should be seen as a strong internal compass.
For that reason, for example, running on a full Github setup is an unlikely way forward. But neither is it impossible if other routes turn out to be fruitless. The process right now is geared towards evaluating what’s out there in an honest manner. The comments, reports, suggestions and concerns above are helping in this a lot.
Cheers,
19 Likes
yo, i have an idea, idk if its possible but what if you use discourse as the frontend and throw in some bot accounts to interface with a git backend?
Since no one has commented on this yet, I’m going to guess that it hasn’t been discussed very much yet and y’all want to hear my thoughts on it 
Blender’s bundled add-on development is a bit of a mess currently IMO, add-ons generally don’t have a central landing page where you can see what’s happening with them, issues and diffs are all lumped in together, if the development isn’t being conducted on some external repository somewhere, and developers with commit access can change bundled add-on code without the author’s knowledge or consent (this isn’t to say that contributions aren’t welcome, but it can cause problems like ⚓ T95962 Sapling Addon now broken because of "SPDX-License-Identifier" header).
Since it seems that Blender will be adopting the fork/pull request paradigm, my current thinking is that I would like to see each bundled add-on get it’s own repo to manage development (bugs, tasks, landing page, PRs, etc.), have scripts/buildbot incorporate the master branch from each of these into the daily builds/releases, and a central listing of bundled add-ons so that the repos are easily findable. Or perhaps bundled add-on development should move entirely to external repos on GitHub, GitLab, Codeberg, etc., but then there is the challenge of synchronizing them with the rest of Blender.
Now I know this doesn’t directly help with picking the new development platform, but I think this is a good time to discuss it and to keep add-on development in mind when looking at the different platforms in case one platform is better suited for something like this than another.
Also, how bundled add-on development proceeds will be influenced by the new policies that have been made recently, and that are hopefully being discussed and clarified here Add-ons Policy Clarification/Discussion so feel free to chime in there if anyone has any thoughts on that as well.
4 Likes
Some critical issues have not yet been raised, which can all be encapsulated in the form of the GNU Ethical Repository Criteria. There are also some evaluations by these criteria, although the list of evaluated sites and software is far from complete.
Blender is a flagship free software program and should be a shining example of freedom. Relying on proprietary software, no matter how much the proprietors claim to be friendly to “open source” or want to give a discount for their proprietary software, is a complete betrayal of this goal of leading by example. No matter whether the entire platform has critical freedom issues (and privacy issues for that matter), eg. Github, or whether the software is only partially free, eg. GitLab, anything less than 100% freedom is a joke. Both of these sites currently score an F (unusable) in the GNU ERC, the worst possible grade.
Should the Blender project self-host or use an existing platform? Ideally the former, as this allows the Blender project to control its own infrastructure, software, and computers. The latter is okay, but not ideal, as it would mean the Blender project would lose a lot of the aforementioned control.
In any case, contributing without an account, anonymously over Tor, and without running JS, especially not proprietary JS, are an absolute bare minimum, which as I mentioned previously, is all encapsulated in the GNU ERC.
I vow to delete this account once this public discussion is concluded, and I resent having to make it in the first place in order to participate in this discussion. If I refused to make a temporary account, who knows whether anybody would have raised the issues I have, and as a result the final decision may have been disasterous.
Forges which allow communication by email are a solution, which leads me to lean towards self-hosting SourceHut as a preferred option, although it has a few issues which need fixing first, namely that it recommends non-libre OSs in its CI features and that it has not had an official “stable” release yet, although it’s already rock-solid.
2 Likes
wasn’t Sourcehut the one that got its grade lowered by the FSF because it didn’t call linux “GNU/Linux”?
To clarify, Linux is a partly proprietary kernel and GNU+Linux is an OS. Linux-libre is a 100% free version of Linux.
Referring to the GNU+Linux operating system as “Linux” is incorrect, and as such SourceHut received a lower score in its evaluation for making this mistake.
In my opinion, being open should be a criterion, not a requirement.
I understand that there are people who think like that. I clearly disagree with it though. Yes, the openness of Blender is important, but artificially trying to make it solely rely on open software appears counterproductive to me. First, it already heavily relies on and uses proprietary software. It runs on proprietary operating systems and uses proprietary drivers.
The decision here is regarding where the development should be coordinated. From my point of view, if they were to pick a purely open solution, there would be a huge risk involved. It is likely that a lot of work would be needed just to get something that works for them. At the same time, the risk is larger they would need to switch to another platform again.
Their primary goal should be to develop Blender. If they can do it purely with open source software, perfect. If it would take a huge effort or risk to do so, it makes way more sense in my opinion to use proprietary software.
1 Like
artificially trying to make it solely rely on open [sic] software
On the contrary, Blender is free software and should be developed in freedom; any attempt to make its development rely on proprietary software would be artificial.
First, it already heavily relies on and uses proprietary software. It runs on proprietary operating systems and uses proprietary drivers.
One can run it in freedom on 100% free operating systems like Parabola; using proprietary software is optional, as it should be. I wouldn’t particularly disagree if you were to propose removing support for proprietary systems and drivers, however, because that would free up time to spend improving support for free systems and drivers.
From my point of view, if they were to pick a purely open solution, there would be a huge risk involved.
On the contrary; using a proprietary or otherwise non-freedom-respecting platform or software would be a huge risk because control and freedom is lost. In other words, the Blender project would be at the mercy of the proprietor instead of independent, free, and in control as it (largely) is at the moment.
It is likely that a lot of work would be needed just to get something that works for them.
They already did it once with the current self-hosted infrastructure setup; I trust they can migrate to a different setup.
If it would take a huge effort or risk to do so, it makes way more sense in my opinion to use proprietary software.
Using proprietary software is a risk. Why put oneself at the mercy of a proprietor?
@Ton, in the interest of securing freedom for the future of the development of Blender, I think you should weigh in.
Blender would not rely on it. If issues occurred over time due to the proprietary nature of the platform, they could just switch to something else.
From my point of view, the number one priority should be the sustainability, meaning the chance of being able to use the platform as intended in the long run. If the risk is smaller on a proprietary platform (no matter how proprietary it is), that should be the go to solution. If there is an open source solution fulfilling the requirements, even better, but that doesn’t seem to be the case.
They are currently using an open source solution which was abandoned. So there is clearly a risk when relying on open source too.
1 Like
Blender would not rely on it. If issues occurred over time due to the proprietary nature of the platform, they could just switch to something else.
Ever heard of vendor lock-in?
If there is an open source [sic] solution fulfilling the requirements, even better, but that doesn’t seem to be the case.
On the contrary, SourceHut is the fastest, (anecdotally) most stable, most usable (working efficiently via email) and most freedom-respecting and ethical option at the moment, aside from Savane (which I wouldn’t propose using because it’s technically inferior to SourceHut), scoring a B on the GNU ERC.
(The issues it has which I previously mentioned in other posts can be fixed relatively easily.)
They are currently using an open source [sic] solution which was abandoned. So there is clearly a risk when relying on open source [sic] too.
There is always a risk, it’s software written by humans who make mistakes after all! Imagine if the current solution were proprietary, the Blender project would have no choice but to switch away from it, but since it is free, they had the option available to fork and maintain it, which is an advantage over if it were proprietary.
Yes, not sure why it would apply here though.
Again, I believe if there is an open source solution which can be adapted to fulfill the requirements, which appears to be sustainable, that would likely be a good option.
Even if they have the choice, I don’t see it being a good usage the available resources to maintain this sort of project in the long run.
Yes, not sure why it would apply here though.
It applies because the Blender project couldn’t “just switch” if it migrated its infrastructure over to a proprietary platform. It is not always possible to export data, eg. bug reports, conversations, messages, CI scripts, etc. from such services which are designed to lock you into their infrastructure. Some even start charging money after a while, it’s a classic bait-and-switch scheme.
If the developers of such hosting sites are already so morally bankrupt that they develop proprietary software, why would you trust them to always provide a “sustainable” service, be friendly to “open source” with discounts and publicity, and not to pull stunts on you like jacking up the price? It’s blind faith or nothing, and it’s a risk the Blender project need not take.
To quote @Ton, https://nitter.kavin.rocks/tonroosendaal/status/1003610646611709957?s=20&t=mdWhDgIyrZhl47fRZOIKuQ
FYI: Blender has its code on git (dot) blender (dot) org and developer services on developer (dot) blender (dot) org - we already host our own services since 2002.
(I had to edit the quote because apparently “new users can’t post more than two links”.)
Even if they have the choice, I don’t see it being a good usage the available resources to maintain this sort of project in the long run.
I agree, but this is irrelevant. The point is that this even being an option is an advantage they would not have had if it were proprietary.
I highly doubt that this project would ever accept completely anonymous code contributions, for legal reasons. It is important to ensure that any added code is actually free software, so we need real people to sign off as such. If that is an “absolute bare minimum” requirement for you, then this project might not be a good fit for you. LOL
1 Like
What’s wrong with people using a pseudonym if they want to? Tons of other free software projects’ commit histories are full of pseudonyms and they’re fine in terms of legal troubles.
That should be easy to find yourself with a simple Google search, so no need to fill this thread with off-topic discussion of something that is irrelevant to this project. If you really think it unfair that we don’t currently accept anonymous contributions then you could always start a new topic, however fruitless that would be.
In other words: “There is no issue, but why not waste time trying to look for some?”
Free software projects have accepted contributions under pseudonyms for decades. People using a pseudonym are “real people”. There is no issue.