I went across statistics from Fedora Package Database and what caught my attention is that the increase of number of packages in the official Fedora repository has almost stalled:

The number of packages in Fedora 22 is 17021 and is not going much since Fedora 20. Does it mean there are no more projects worth packaging? I don’t think so. The number of open source projects goes up like never before, just look at GitHub.

I think this trend is related to the growth of Copr. The number of projects has been rising exponentially there. Mirek Suchý reported a couple of months ago that the number of projects in Copr was almost 3000 and almost 2000 were active. And the numbers have increased significantly since then.

It’s actually a success. It means we have achieved what we outlined in the Fedora.Next plans: we’ve built a ring of software around Fedora which has low barriers to entry for packagers and where software is easy to install for users. Although the number of packages in the official repositories is not growing like in the past the total amount of software available to Fedora users has grown like never before. That’s great.

What we’re still failing at a bit is how to build on this and bring the best of Copr to official Fedora repositories and convert the most promising Copr packagers into Fedora packagers. The official repositories still have their relevance. The quality of packages there is significantly higher than in Copr. We should encourage Copr packagers to work on their packages to meet Fedora standards and become Fedora packagers. We should show them the path. I can imagine that we offer an option in Copr to run the source packages against fedora-review to give the packager a hint what needs to be done to meet the official repository standards and if he/she is interested we can point him/her to documentation for the rest of the process.

The current situation is a great opportunity if we streamline the path to quality. Then Copr can serve as a broad source of “playground” software from which useful and proven projects can get deserved quality of integration and make it to the official repositories. But it’s also a threat because if we don’t provide a path and encourage Copr packagers they may just be satisfied with the easy way to make and maintain packages in Copr and no one will want to package software for the official repositories any more.