(pp
(peg/match
'(capture
'{
:main (* :B)
:B (+
(* :A "x" "y")
:C)
:A (+
true
(* "x" "z"))
:C (+
(* :C "w")
"v")})
"xzxy"))
Peertube covers the enterprise use case, but makes unreasonable demands from hobbyists, single users, tinkerers. Kids, gather around and learn from the Peertube design mistakes that an experienced and well-meaning software designer would refuse to subject his users/operators to. Why is this important? Because the number of hobbyist operators is much greater than the number of enterprise operators, given the intended target audience of people who are interested in decentralisation and federation. Peertube engineers and product managers should sit down with the intention to make a smart market move, and expend the next half month of effort to optimise for the majority of operators who make up the long tail, not the minority, so that hurdles to entry are demolished and the stated goal shown on the homepage of "community-owned" becomes attainable for many more people than is the case right now. The resulting network effect would be tremendous.
1. Packaging. Peertube is not packaged by the major players. <https://repology.org/project/peertube/versions> Real-life experience shows that this is almost always because of a circumstance which frustrates a distro packager. Other NPM-conformant libraries and software are packaged nearly automatically, there is good support in the distros to create specfile/RPM package, control file/Deb package, etc. from an Nodejs library tarball with just one command. Peertube must investigate why it is so exceptional and difficult to package and demolish the hurdles.
2. Configuration. Peertube must as the installation step make effective an usable configuration that has some sensible defaults, or perhaps auto-configure at install time or run time. A user should be able to install the software (from a distro package, or a git checkout/unpacked tarball and build step), run it, and immediately use it. It is okay when some features are not working until configured. It is not okay for a software to refuse to work altogether until each and every operator spends time and brain power to figure out what are essential configuration options and what are not, and make decisions about them. The reason why I say it is not okay is because this is a clear abdication of responsibility from the Peertube software devs and an externalising of mental burdens onto the many Peertube operators.
3. Database. Peertube should work with Sqlite by default. An enterprise user can configure PostgreSQL additionally when the need arises.
4. Web server. Peertube should work with the Node.js Web server (possibly express.js or a work-alike) by default. An enterprise user can configure Nginx additionally when the need arises.
5. Cache. Peertube should work with a simple file system cache or no cache at all by default. An enterprise user can configure Redis additionally when the need arises.