Agreed, the Software Portal IS a convenient resource… however is it what we want new members of the community to see first? Currently it often shows up in google search when you search “somesoftware opensuse”.
A year ago when I first installed openSUSE that gave me the impression that this was where to go to find what was available for Tumbleweed, and I immediately ran into the one-click install issues (obviously I eventually found out not to use that), and I was disappointed at how many softwares didn’t have official releases. However thankfully AppImages and Flatpak exists as well as Jonatas Goncalvas’ MaxxedSUSE repo, and once I had everything I needed I was convinced me to stick with Tumbleweed.
However, it wasn’t till a couple months ago that I really understood that OBS is and incredibly powerful community feature. The ability to work together as a community to create the build recipes for software with a tool that thankfully abstracts away many of the complexities of building RPM packages is amazing.
OBS is abstracted away by the Software Portal, and I really do think OBS should be the focus. In my opinion we should be teaching users how to fish from the getgo. Especially for Tumbleweed, which for me was the distro I gravitated to only after trying other “entry level distros”. By then I had some experience breaking and fixing things and was ready to take on some more risk.
If new users want the official software in Tumbleweed, we should direct them to the right place in OBS, and show how and why zypper can pull that by default. New users may not want to immediately download OSC and start branching repos, but they should be shown that this functionality exists, and is a key part of the openSUSE community. They should know how to add a user repo to zypper, and the risks of doing so (and how to manage repo priority in zypper).
I also think putting OBS front and center would help attract more potential contributors into being package maintainers, which is something I believe you can never have enough of… and I know there are lots of good packages out there on OBS that just have never gone through the process to make them official. That is actually my goal eventually, to get a small package into Tumbleweed and maintain it.
I completely disagree with that. Before SLE integration one of the things you could boast about with openSUSE was precisely how easy it was to install packages with 1-click.
With Leap 15 series we could boast about “enterprise-grade” robustness but not 1-click.
Perhaps the question that needs to be asked is why we would want a software portal.
If the software portal is meant to help people install their software, then in my opinion we should not only improve it, but we should add functionality to be able to search i.e. flatpak. I like the idea of Discover in Plasma, which allows you to search for rpm or flatpak packages in the added repositories. A web service or application that could search all the community repos like the software portal, and could also search Packman and other common repositories (e.g. VLC, which is free software) and flatpack would be playing on another level. But of course I understand that different approaches to searching for packages from each other can make it very difficult to standardize a search engine. But just as in Plasma you can add components from its “store”, being able to do something similar in Discover and other tools would make things much easier for many newcomers…
I understand the impulse to encourage people to participate in the buildservice. Not just to learn about it, but to participate, develop, etc. But in my opinion, this should be done with better integration with the wiki and perhaps with the forum, the welcome page starting Plasma/Gnome…
It’s possible to integrate the package search service with OBS? Ok, go ahead!!
@karlggest Whatever the design specifics may be, vertically integrating OBS through the entire openSUSE software cycle, from package maintenance to end-user, will bring users closer to developers and reduce development overhead.
Remember “knows/can learn where project is developed”, and “has available resources to file report” in the flowchart? Reducing these barriers to contribution is what further vertically integrating OBS will achieve for openSUSE packages
For that matter, vertical integration also becomes a implicit learning resource and reduces the short-term resource cost of learning to fix package issues (requisite amount of familiarity using OBS). It does this distributing the learning effort over time in a process that shifts traditionally what is “consumption behaviours” closer towards “contributing behaviours”.
I will finally say that people learn and become motivated much better by “doing” instead of “reading about doing”. We want as little “reading about doing” before someone can actually “do” as possible.
Yes, I agree. If we can achieve greater integration with OBS that would be great, but that’s easier said than done. In the end we should not lose sight of the fact that the idea is that openSUSE
is a worldwide effort that promotes the use of Linux everywhere. openSUSE creates one of the world’s best Linux distributions
This is certainly a reasonable discussion to be having, whether software.o.o is worth keeping around, and trying to find the folks to put in the work to fix it, but specific services really aren’t the point of this special forum section.
Not directly.
It does come back to the lack of organization, which is relevant, and raises the following questions for me:
A) Who is making the decisions for software.o.o?
B) Where would you have this potential discussion?
C) How would somebody contribute to the software.o.o codebase?
Mentioning the mailing list having been inactive since 2023 isn’t meant to indicate that nobody is looking after software.o.o, as there are github commits as recently as 2 months ago, but the issue tracker on github has 101 open issues, with the oldest being filed in 2016. I’m not making any value judgement whatsoever on the folks that have been working on software.o.o (there are 328 closed issues in the github, with the most recent having been closed on 22-Oct-2024), but if I were walking into the codebase cold, and wanting to try to help, I wouldn’t say the communications surrounding how to do that, or the indications of who I would talk to are even remotely close to clear.
So that part of the discussion is relevant to this special section of the Forum, as it is indicative of the sort of issues we do face, in many aspects of the project, when it comes to attracting and/or finding contributors.
@sfalken I’m having trouble trying to systemically identify roles a contributor may have to the openSUSE organisation (such as package maintainer), and projects developed at openSUSE (particularly more niche ones like osc).
I’ve got a pretty detailed write-up in the works outlining specific systemic design problems for organisation and potential solutions, and as part of it I’m drawing up some infographics.
Having a detailed list of contributor roles and projects would help guide further discussion and avoid bias towards the most known projects, but I feel like I haven’t been around long enough to learn about a bunch of them.
I think @sfalken’s larger point is “what justification does software.o.o have to be called an openSUSE project, and not just an independent project?”.
Off the top of my head:
There is one main reason openSUSE should pick up/support a project:
It helps openSUSE action its mission statement
There are one main reason a project may want support from openSUSE:
They want to make use of openSUSE’s resources
Broken up into two basic subcategories
Human resources
Infrastructure resources
If a project is picked up by openSUSE, and the contributor-base and infrastructure is underutilised, the project has no reason to be a part of openSUSE. If development becomes so slow that it no longer effectively helps openSUSE action is mission statement, then openSUSE has no reason to support the project. In both cases, openSUSE loses.
openSUSE should encourage projects to use its own infrastructure (and keep its infrastructure fit-to-purpose), and effectively communicate to its contributor-base which projects are out there and how to help them. I believe Shawn is trying to make the point that this is currently not the case, a position that I agree with.
As far as the justification being self-evident goes, I’m going to quote something back to you. I hope you can understand my position in trying to identify motivations for project associations.
That being said, it seems that I misinterpreted your intentions… What I don’t fully understand then, is what the overall point in asking those three questions is.
You refer to “organization” as the originating factor, but I feel as if organisation is a bit of an amorphous blob of a word. Can you elaborate on what you consider to be organisation and how you see that answering such questions will help improve it in the big picture?
Software.o.o is used for searching the openSUSE OpenBuildService, to find packages that may not be included in the default repositories (and technically for non-openSUSE packages as well, since OpenBuildService can do that) so it’s perfectly reasonable to say it’s self-evident that it’s part of the “openSUSE Project” as it runs on openSUSE infrastructure, uses an openSUSE domain, provides functionality for openSUSE products, and the source is developed and maintained within the openSUSE namespace on GitHub, I would need to look at the commit history, but I’m mostly certain that the bulk of the development is done by openSUSE members. So I’d say it’s pretty safe to say it’s a project within the “openSUSE Project”
I’m using “organization” in the most basic way. Not in reference to any sort of entity. Like you would organize items in a drawer. If somebody were interested in contributing to software.o.o how is that particular project “organized” so a new contributor could figure out how to do so.