Лайфхак:

Зачем объяснять не буду, сами знаете.

Итак, сначала скачиваем себе https://windscribe.com/download
Этот VPN работает и для IOS и Android и на всех компьютерах включая Linux
В процессе установки он предложит зарегистрироваться. При регистрации указываем email и потом подтверждаем свою почту в пришедшем письме. Так мы получаем 10Гб в месяц.

Далее можно получать бонусы в виде дополнительного трафика если кто-то зарегистрировался по вашей реферальной ссылке.
Ссылку ищем тут 👇

Копируем ссылку и далее открываем в вашем браузере вкладку в режиме инкогнито. Я буду показывать на Яндекс браузере, но этот режим есть у всех, поэтому не так важно в чем именно, главное чтобы инкогнито.

Далее копируем туда нашу реферальную ссылку и регистрируемся. В поля логин и пароль можно писать любую белиберду. Но, нам нужно подтвердить емэйл.
Для этого мы идем на сайт https://temp-mail.org, где нам автоматически генерируется временный емэйл.
Временный емэйл работает сутки если не чистить историю браузера.

Копируем сгенерированный емэйл, завершаем регистрацию. Подтверждаем на temp-mail.org почту и проделываем весь процесс заново. Открываем новую вкладку инкогнито, чтобы не ждать сутки и не чистить историю браузера и далее по тексту. Больше 18 гб не дает, но этого вполне хватает.

Скриншот некогда скандально известного сайта «Нивежа»

Не думал, что такой вопрос может у кого-то возникнуть, очевидная вещь, казалось бы, но видимо не для всех.
Итак. Для начала. Что такое паспорт записи?
Что в него должно входить и главное зачем?
Паспорт записи — это набор сведений, который помогает нам идентифицировать эту запись, сделанную в ходе фольклорно-этнографической экспедиции. Аудио, видео, рукописные тетради и даже фото. Кто записал, где и когда. Паспорт может быть минимальным, может быть максимально подробным и включать в себя кучу всяких дополнительных сведений.
Вообще, сами понятия никто не определял и жесткого регламента нет. То есть нет никаких резолюций круглых столов, или конференций, где были бы приняты такие термины и конкретные атрибуты, необходимые для публикации. Но, в научном обороте есть более-менее устоявшаяся традиция описи экспедиционных материалов, и о ней я поведаю.
Конечно же есть нюансы, о которых идут споры в кулуарах, и это тоже интересно.
Итак, минимальный паспорт, по моему скромному мнению, должен содержать:

1. Адрес населенного пункта (область, район, название населенного пункта)
2. Дата
3. Автор записи (руководитель экспедиции)
4. Название фрагмента записи (песня, тема в интервью, обряд, праздник, возможно, ответ на вопрос, сказка и т. д.)
5. ФИО информанта

Это минимально необходимый набор.
Более полный может включать в себя следующие пункты:

1. Год рождения информанта
2. Место рождения информанта
3. Организация, проводившая экспедицию
4. Организация, которая осуществляет хранение этой записи
5. Реестровый номер записи

Каждый владелец архива для себя определяет ещё какие-то данные для удобства работы.
Например:

1. Национальность
2. Тип исполнительства (песня, рассказ, игра на музыкальном инструменте, танец)
3. Жанр по версии информанта и/или по версии собирателя
4. Приуроченность к чему-либо

И так далее.
В принципе, последние два пункта уже больше относится к анализу данных, а не к паспорту, и об этом стоит написать отдельно, а нам пока вполне хватит тех проблем, которые встречаются даже в таком минимальном наборе.

Населенный пункт

Первым делом разберёмся с населённым пунктом. Зачем указывать населённый пункт? Может достаточно указать просто область? Мы же все говорим — «белгородская традиция», «песня Брянщины», «казачья песня».
Но. Казаки обитают от Украины до Дальнего Востока, различия в традициях очень сильные, нужно хотя бы указывать с территории какого войска песня: донская, кубанская, уральская и т. д.. Достаточно? Возможно, но всё же территория бывших войск так же неоднородна по своему происхождению, и как следствие, по типу исполнительства. Есть кубанские казаки-линейцы, есть черноморцы, и песни у них очень сильно различаются. То же самое можно сказать про Нижегородскую и Саратовскую области: они заселялись людьми из других регионов России, процесс этот был весьма растянут во времени. Так же нужно учитывать, что области как таковые меняли свои границы. Например, части Тульской и Орловской губернии когда-то входили в Московскую. Липецкая и Белгородская области были основаны всего лишь в 1954 году, и поэтому говорить о Липецкой и Белгородской традиции весьма странно в свете того, что мы изучаем песни, которые появились за 100-200 лет до появления этих названий как минимум. На эту тему есть замечательная лекция у Екатерины Анатольевны Дороховой. Очень рекомендую посмотреть для самообразования. Суть заключается в том, что административные границы не соответствуют культурным границам.

Ну что же, давайте коснемся проблем, связанных уже с точным адресом.
На удивление они есть.
Одна из типичных проблем, это запись информанта вне места его проживания. Например, в московской студии или на фестивале. В источнике может быть указано место записи Москва, а исполнитель оказывается из Афанасьевки Белгородской области.
В некоторых архивах для этого вводят графу место бытования. На мой взгляд, важнее указать именно адрес бытования данной песни. Уточнять обстоятельства записи дело второстепенное, хотя для кого-то это может иметь большее значение конечно, но точно не для массового слушателя.
Населенный пункт на момент записи принадлежал другому району или области, назывался по-другому.
В этом случае стоит отнестись к записи как к документу, который был создан в определенное время. И его адрес должен быть указан таким, каким он был на момент записи. Для облегчения понимания можно в публикации дополнительно указать современный адрес.

Дата записи

Зачем нужно указывать год записи?
Потому, что традиция не статична, она меняется с течением времени. Конечно, к большому сожалению, в основном мы говорим о процессе угасания и деградации. Но, к счастью, хоть редко, но бывает и наоборот. Где-то она возрождается, или просто меняется в каком-то новом направлении. Поэтому зная традицию одного конкретного места, мы можем по одному паспорту записи понять, интересна нам эта запись или нет. Можем оценить сами послушав записи разных лет, угасает, меняется или возрождается традиция в данном месте. Можем выстроить ретроспективу звучания одного конкретного ансамбля или исполнителя. Специалисты, например по одному году могут понять, кто именно записал песню, и кто поёт на записи. Надо отметить, что редко когда можно найти в архивах точную дату записи. Обычно на кассетах или бобинах указывается только год, иногда вообще приходится писать приблизительно, например (1973-1976). Архивы, это тот еще квест.  

Автор записи

Тут можно поговорить уже о юридической стороне дела, хотя на мой взгляд гораздо более важна этическая.
Если кратко про закон, то авторство экспедиционной записи принадлежит руководителю экспедиции и его наследникам и информанту или его наследникам. Человек нажавший кнопку на магнитофоне не считается. Это просто технический персонал. Все, кто присутствуют тоже. Возможны нюансы если кто-то другой ведет опрос, но юристы склонны трактовать права не в их пользу. Организации, которые отправляли в экспедицию в подавляющем большинстве прав на саму запись не имеют. Это связано с тем, что экспедиции в рамках работы организаций были и есть лишь средство для получения конечного итога — публикаций (книг, статей, сборников). Это то, что работник должен произвести как конечный продукт. Иначе в трудовом договоре должен быть план и объем по количеству записанных часов и т. д. Такого нигде не было и нет. Организации в лучшем случае могли потребовать назад магнитную пленку, сейчас хард-диски. Само содержимое на балансе никогда ни у кого не стояло, и эта ситуация неизменна по сей день.
С юридической стороной всё понятно и если честно, то мне не особо интересно. Я не знаю ни одного судебного разбирательства по поводу публикации чужих записей, поэтому это все относится больше к теории. Гораздо важнее этическая сторона вопроса, и тут, оказывается, есть мнения. Да что там мнения! Война!
Степень упоротости некоторых граждан поражает. Например, один весьма известный в фольклорных кругах индивид сделал заявление, что мол зачем указывать авторов записи, мол они и так уже сделали свои публикации, получили за них свои научные степени, деньги и славу. И знаете, вопреки вашим ожиданиям, я соглашусь. Евгения Эдуардовна Линёва действительно получила известность в том числе благодаря тому, что первая в России записала традиционное народное пение на восковые валики. Научные публикации стоят каких-то денег, ну и конечно, способствуют получению научной степени. Тут спора нет. Дело в другом. В том, что, забывая тех, кто для нас сделал что-то полезное и хорошее, пусть даже за какие-то награды, мы теряем уважение к себе и поступаем плохо относительно наших же детей. Мы сами стираем свою историю. Давайте назовем таблицу Меделеева просто периодической таблицей химических элементов и вообще не будем указывать имена всех российских первооткрывателей, этнографов, биологов и прочих, прочих, прочих. Все же слышали новость про данные опросов в Японии, где 60% респондентов считают, что СССР сбросили атомную бомбу на Хиросиму и Нагасаки. Ну там-то понятно, вражеская пропаганда, а здесь? Сами себя будем превращать в манкуртов? Резюмирую. Указывать автора записи надо не для автора, а для нас самих. Это наша история. Иначе наши дети будут уверены, что Т. Р. Миронова и К. Л. Морозова записал не А. С. Кабанов, а National Geographic.

Название фрагмента записи

Вот тут интересно. По поводу, как и что писать, не утихают споры. Возьмем, например, песни. Логично указывать первую строчку. Вроде правильно. Но что делать, когда у нескольких песен один и тот же зачин и совершенно разный текст дальше? Ну например «На восходе было солнца красного». Таких песен сотни.
Идем дальше. У некоторых песен есть общепринятые названия. Например: «Калинушка», «Веселая беседушка» и так далее. Беда в том, что в некоторых вариантах бывает слияние двух текстов из разных песен: и это уже не совсем в чистом виде «Калинушка». Еще вопрос «как именно писать?». В диалектной расшифровке или в переводе на современный? Проблема не решена. Все поступают по своему разумению. Ответа нет. Извините.

ФИО информанта

С юридической точки зрения собиратель и информант абсолютно равноправны относительно одной конкретной записи. Поэтому, если стараться соблюдать юридическую сторону дела, то здесь вывод один — «указывать однозначно!». В научном обороте важно указывать не только ФИО информантов, но также год его рождения и место рождения. Это связано с тем, что информант может не являться представителем традиции данной конкретной местности. Самый частый случай, это женщины, которые переехали в связи с замужеством. Важно указывать информанта в том случае, если вы надеетесь, что с помощью вашей публикации кто-то найдет запись голоса своего предка.
Тем не менее, я ставлю приоритет указания собирателя выше. Можете меня осуждать.
Дело тут вот в чем. Во-первых, информант не всегда известен, особенно в записях любителей или на первых записях, что на восковых валиках.
Во-вторых, информантов существенно больше собирателей. Есть безусловно знаменитые выдающиеся исполнители. Есть и те, кто известности заслуживают. Их, конечно, стоит упоминать. Но факт в том, что их песни пели и другие люди. Когда мы упоминаем конкретного информанта, надо понимать, что мы не упоминаем все тех остальных, кто пел до него и будет петь после. Ну и тех, кто поет одновременно с ним, но не попал на запись. Еще раз повторюсь, не обязательно придерживаться моего мнения. Я работаю в архиве и это профессиональное. Моя жена думает по-другому, и мы живем в мире и согласии. Да и вообще, найти автора записи проще чем информанта, это просто реалии нашей жизни.

Всё остальное

Указание организаций — облегчает поиск схожих записей.
Реестровый номер, это ИНН записи. Используется в научных публикациях, в других случаях не обязательно.
Национальность — зависит от контекста.
Тип исполнительства (поем/играем на инструменте/декламируем) — облегчает поиск в реестре, не более.
Жанр — единой универсальной системы жанров нет. На романсовую мелодию может петься обрядовый текст, и это — не шутка. В какой жанр запихать такое никто еще не придумал. Жанр по версии информанта важен, но редко когда такая информация есть.
Приуроченность есть далеко не у всех песен, тут еще надо бы хорошенько выяснить, кто эту приуроченность обозначает, сам информант или это умозаключение собирателя. Собиратель тоже человек и не всегда бывает объективен. Может быть важным параметром, но только в контексте конкретной задачи публикации.

Минусы

Публикация точных адресов и имен исполнителей в свое время породила в некоторых местах массовый наплыв любительских экспедиций. Это иногда вызывало проблемы. Были ситуации, когда бабушкам приходилось принимать по три — четыре ансамбля за сезон, иногда это было подряд, бывали и накладки. Деревенские жители чаще всего гостеприимны и хлебосольны, но ресурсы их не бесконечны. В общем, это отдельная большая тема об этике в экспедиции.
Сейчас возможно есть проблема с публикацией адреса и ФИО исполнителя поскольку это является личной информацией и на это нужно брать письменное согласие.

Итог

Приоритет в данных может меняться в зависимости от целей. Фольклористика, это не единоличная сфера влияния ученых. Мы все формируем информационное поле, давайте делать это правильно. Часть утверждений являются моим личным мнением, которое разделяют другие люди. Все вышесказанное не обязательно, но рекомендовано к исполнению. Надеюсь, это очевидно. Если есть вопросы или дополнения и мысли, пишите в комментариях.

Архивы

Какую умную мысль написать?
Вот например, меня последнее время посещает такая: мне уже 46, так вышло, что я большую часть жизни посвятил фольклору, но не так как это делает рядовой фольклорист. Обычно, рядовой труженник традиции приходит и поëт, ну или пляшет. Потом создаёт ансамбль или центр или что-то в этом роде, кто-то идёт в науку, в педагогику, в общем набор известен.
Я конечно не избежал пения, чем очень до сих пор увлечён, но основная моя мысль всегда лежала в скучной сфере организации архивов.
Скучная, потому, что моя жена так считает, для неё этот высшая математика. А мне было жутко интересно ещё в далёком 2003 году делать таблички на сайте из названий песни, места записи и исполнителей. Всё это было написано на новомодном тогда php, казалось мне очень сложным и поэтому увлекательным. Не хватало объектов. Архив клуба Белый камень был маловат.
И вот прошло много лет, я уже заведующий архивом Центра русского фольклора и пишу на новом новомодном языке python новый интерфейс к нашей базе.
Но.. мне по прежнему одиноко на этом пути.. IT у фольклористов не популярно. Не с кем обсудить тонкости топонимики, резервного копирования и частотные характеристики бобинных магнитофонов..

Скрипт написан на Python. На вход принимает csv файл:

Курская обл.;Ль район;с. Иванчиково
Курская обл.;Суджанский район;с. Плёхово
Курская обл.;Железногорский район;с. Жидеевка
Курская обл.;Железногорский район;Новый Бузец
Курская обл.;Железногорский район;с. Старый Бузец
Владимирская обл.;Судогодский район;Аксеново
Владимирская обл.;Суодский район;Карпово
Владимирская обл.;Судогодский район;Слащево
Архангельская обл.;Котласский район;г. Сольвычегодск

На выходе будет csv файл уже с координатами. Если не удается найти координаты, то будет записано пустое значение.

Курская обл.;Ль район;с. Иванчиково;
Курская обл.;Суджанский район;с. Плёхово;51.1007804,35.3290548
Курская обл.;Железногорский район;с. Жидеевка;52.1923663,35.4500001
Курская обл.;Железногорский район;Новый Бузец;52.164154,35.484161
Курская обл.;Железногорский район;с. Старый Бузец;52.199837,35.5330842
Владимирская обл.;Судогодский район;Аксеново;56.0756071,40.761767
Владимирская обл.;Суодский район;Карпово;
Владимирская обл.;Судогодский район;Слащево;56.0697562,40.8062814
Архангельская обл.;Котласский район;г. Сольвычегодск;61.3315511,46.9311295

Вся эта штука работает с API Nominatim, поэтому конечно же нужен интернет, ну и есть вероятность каких-то лимитов.
Собственно код:

from geopy.geocoders import Nominatim
import csv
with open('test.csv', newline='', encoding='utf-8-sig') as File:
    reader = csv.reader(File, delimiter=';')
    data = list()
    for row in reader:
        loc = row
        try:
            geolocator = Nominatim(user_agent="my_request")
            location = geolocator.geocode(loc)
            point = str(location.latitude) + ',' + str(location.longitude)
        except:
            point = ''
        row.append(point)
        data.append(row)
myFile = open('out.csv', 'w')
with myFile:
    writer = csv.writer(myFile, delimiter=';')
    writer.writerows(data)

print("Writing complete")

Задача

Необходим инструмент для систематизации и работы с записями полученными в ходе экспедиций. Что для этого можно использовать? Простые таблицы Exel, может какие-то готовые программы можно приспособить под эти нужды или стоит написать свою программу? Что это будет за программа? Её устройство?
Есть кажущаяся простота решения проблемы — найти программиста, заплатить за работу и он все сделает. Но на практике всё оказывается сложнее. Программисты не понимают специфики работы с фольклорным материалом, фольклористы не знают технологий и все это выливается в перерасход средств и не удовлетворительный результат.

Требования

Для начала важно понять какие требования мы предъявляем к программе которой мы будем пользоваться.

1. Оперативный доступ к материалу и его описанию.
2. Совместный доступ
3. Делегирование различных прав доступа пользователям
4. Доступ не требующий установки дополнительного программного обеспечения
5. Независимость от разработчика
6. Простота в установке и переносе на другой компьютер
7. Независимость от типа операционной системы компьютера

Немного по пунктам.
Оперативный доступ — в идеале это доступ с любого компьютера в организации, возможно даже из дома и с мобильного телефона.
Совместный доступ — возможность работы одновременно всем сотрудникам. Не нужно идти к одному ответственному сотруднику и загружать его рутинными задачами по поиску нужной записи.
Делегирование прав — возможность ограничивать доступ на редактирование записей, на какие-то разделы.
Доступ не требующий установки программ — идеальное решение, это доступ через браузер. Раз уж у нас есть необходимость совместной работы которое обуславливает структуру сервер — клиент, вполне логично, что клиентом будет выступать браузер (Chrome, Firefox, Edge ).

Если изучить сборник Мультимедийные и цифровые технологии в собирании, сохранении и изучении фольклора по результатам одноименной конференции, то можно отметить, что большинство решений используемых для построения таких систем сделаны при помощи WEB технологий

Готовые решения

Из наиболее популярных CMS (системы управления содержимым сайта) можно выделить такие как: Wordpress, Drupal, Joomla, MediaWiki

Первые три — Wordpress, Drupal, Joomla являются блоговыми или новостными движками ориентированными на решение таких задач как новостной блог, сайт организации, интернет магазин и так далее. Страницы которые создаются в интерфейсе администратора ориентированы на размещение статей, вывод страниц на сайте по умолчанию в виде новостной ленты с заголовком и тизером, порядок вывода по дате добавления.
Для возможности формирования своей структуры, логики и типов статей необходимо искать и устанавливать расширения. Плюсом этих систем является низкий порог вхождения для редактора. Минусом — необходимость устанавливать и настраивать расширения.

MediaWiki — совершенно отличная от этих трех система. Это свободно распространяемый движок на котором работает известный сайт Wikipedia. Он очень хорошо подходит для публикации материалов энциклопедического характера, позволяет выстраивать сложные семантические связи и организовывать данные в различного уровня сложности структуру. Плюсом системы можно отметить то, что идеально подходит для построения на ней системы учета фольклорно-этнографических материалов. Минусом — сложность освоения для редактора. Все материалы оформляются при помощи специальной разметки markdown, структура и ссылки так же требует оформления через специальный синтаксис. Для более удобной работы так же требуется поиск и установка расширений.

Общим минусом у всех готовых решения является необходимость их установки на выделенный сервер.
В случае если эти системы устанавливаются автоматически на сервере платного хостинга, то мы получаем ограничение в виде дороговизны дискового пространства. В нашем случае это очень важный показатель, так как аудио, видео и фото даже при сжатии занимают много места.

Здесь я хотел бы отметить важный момент. Говоря вообще о создании такой системы я подразумеваю, что материалы в систему будут вноситься в сжатом формате. Аудио — mp3 или ogg, у видео будет снижен битрейт и сжат кодеком h264 (mp4), изображения будут конвертированы в JPEG с разрешением оптимальным для полноэкранного просмотра. Опыт работы с архивом показывает, что объем при этом можно уменьшить на 60%-70% без сильно видимых и слышимых потерь в качестве.

В случае же если мы ставим систем на свой личный сервер, то мы упираемся в сложность настройки и администрирования самого сервера.

Схема приведена не для того, чтобы разобраться в устройстве. Здесь я хочу обратить внимание, что для запуска CMS придется настроить минимум три серверные программы (Apache, PHP, MySQL), при этом все это необходимо настраивать в операционной системе Linux. Справедливости ради надо отметить, что все это можно сделать и на Windows, но надежность такой установки авторы всех этих программ не гарантируют. Версии под Windows служат в основном для разработки.
Всё это вкупе с минусами готовых решений подвигает нас к созданию какого-то своего более удобного решения.

Фреймворки

На  Википедии слово фреймворк объясняется как каркас для создания программного продукта. Мне больше нравится в этом смысле аналогия с полуфабрикатом. Фреймворк, это полуфабрикат для программиста. Очень важно, что на полуфабрикате так же указан точный рецепт приготовления блюда.
Фреймворки, это написанный заранее каркас программы где программист в процессе разработки своего приложения пишет код по уже заданным правилам. Свобода в создании продукта остается, поскольку в его ведении остаются типы страниц, внутренняя логика и структура. В фреймворке уже решены все типовые задачи — авторизация, полномочия, построение зависимостей между компонентами и так далее. Все это дает в первую очередь независимость заказчика от программиста и скорость разработки, поскольку базовая часть уже написана заранее.

В ситуации когда код программы написан с нуля одним программистом найти замену или кого-то кто смог бы доработать, обновить или в некоторых случаях даже перенести на новый сервер очень проблематично. Разобраться в чужом коде для нового человека будет крайне непросто. Это называется проектные знания. Для того, чтобы снизить порог вхождения программиста в новый проект и были придуманы фреймворки. Код написан по строго определенным правилам, программист приходит в проект уже зная необходимый базис (базовые знания и стек технологий), время на изучения специфики проекта уменьшается. Как компромисс возможно рассматривать готовые решения как базовую часть кода и дописывать необходимый функционал. Такое решение используется в  Научном центре народной музыки им. К. В. Квитки МГК на базе CMS Joomla.

Следующим плюсом использования web фреймворков в контексте создания системы учета для фольклорно-этнографических материалов является тот факт, что многие из популярных фреймворков уже имеют встроенную программу-сервер разработки.

Сервер разработки, это встроенная команда в фреймворке, которая позволяет запустить проект и проверить его со стороны пользователя без необходимости настройки всего пула программного обеспечения как на реальном сервере. Сервер разработки не рекомендован для публикации его в сети интернет. Но в действительности он способен обеспечить стабильность и надежность его использования для одновременного пользования 10-30 человек. Возможно и больше, но для наших задач, это вполне достаточно, учитывая тот факт, что программу всегда при необходимости можно перенести на боевой сервер. Все дело в том, что вышеописанный набор программ необходимый для запуска приложения на сервере Linux предназначен именно для того, чтобы сайт мог справляться с нагрузкой более 1000 запросов в секунду.
Если уж проект вырастет до такой степени, что ему потребуется справляться с подобным наплывом посетителей, то ничего не мешает запустить все это на реальном сервере по вышеозначенной схеме.

Обзор

В обзоре я постарался показать самые популярные бесплатные фреймворки.
Все они независимы от типа операционной системы, все они легко запускаются при помощи единственной команды и все они могут быть перенесены с одного компьютера на другой путем простого копирования. Обязательным условием для них всех, это наличие на компьютере предварительно установленного интерпретатора того языка на котором они написаны. Установка эта ничем не отличается от установки любой программы вроде Google Chrome или Skype. Так же возможно в процессе разработки надо будет поставить задачу программисту написать скрипт настройки рабочего окружения для первого старта. В действительности это еще две — три команды которые запускаются один раз перед первым запуском. Я подчеркиваю тот факт, что это требуется именно для переноса серверной части программы. Клиенту работающему с ней через браузер ничего настраивать не нужно.

Почему имеет смысл выбирать популярные решения, а не те, которые удобны разработчику? Возможно вашему знакомому или предложившему хорошую цену, но с условием что выбор фреймворка за ним?
Популярность является некоторым гарантом того, что :

• они дольше будут актуальны
• у них чаще выходят обновления
• в них быстрее находятся и устраняются уязвимости
• у них больше расширений написанных сообществом
• для разработки проще найти программиста
• проще при случае разобраться самому, так как больше обучающих материалов с сети

ТОП три web фреймворка на 2021 год

1) Laravel написанны на языке PHP

PHP самый распространенный язык для сайтов в интернете. Все готовые решения приведенные выше написаны именно на нем. В PHP встроенный сервер разработки появился недавно, он достаточно прост, но вполне надежен. Laravel не может похвастаться тем, что его используют какие-либо крупные компании, но количество проектов на нем доказывает, что это очень хорошее решение для небольших и средних проектов. Так же плюсом можно выделить то, что большинство на большинстве хостингов PHP утсановлен по умолчанию даже на самых дешевых тарифах.

2) Rails написанный на языке Ruby

Пик популярности фреймворка пришелся на 2013 — 2015 годы, первый выпуск — 2004 год. Rails используется в таких крупных компаниях как Airbnb, Twitch, GitHub, Spotify, SoundCloud. Движок очень удобен для разработки, прост в освоении. Минус — малое количество хостингов с поддержкой Ruby.

3) Django написанный на Python

Очень популярный фреймворк, в подавляющем большинстве курсов по изучению языка Python используется в программе обучения, несмотря на то, что на Python есть и другие популярные фреймворки. Django используется в Instagram, Mozilla, National Geographic, Pintertest, Youtube. Еще одним из косвенных преимуществ Django является то, что язык Python активно используется в работе с нейронными сетями, что на мой взгляд является будущим в сфере обработки и анализа фольклорно-этнографических материалов.
Минус — малое количество хостингов с поддержкой Python.

Последние пункты (плюсы и минусы) относительны, поскольку при запуске такого рода проектов в сеть стандартный хостинг уже не подойдет и необходимо будет арендовать выделенный сервер, где все настраивается вручную.

Итоги

Помимо приведенных выше, конечно есть еще много популярных других. Например обязательно стоит упомянуть связку Node.js + Express написанную на Java. Достаточно сказать, что именно на Node.js работает платежная система PayPal. Для Python стоит упомянуть такие фреймворки как Flask и FastAPI, для PHP — Symphony и YII2. Многие программисты отдают им предпочтение и часто это обусловлено в том числе и необходимостью иметь больше свободы для написания кода и интеграции с какими-нибудь другими системами. Но поскольку мы рассматривали эти продукты именно с точки зрения создания удобной и дешевой системы для  фольклорно-этнографических материалов, то здесь мне кажется — чем проще, тем лучше. Чем популярней, тем надежней.

P.S

В данный момент мной ведется разработка Банка данных для архива Центра русского фольклора на Django.