Я думаю, если биллинг будет предоставлять очень-очень базовый функционал по биллингованию и обойдется без всяких инвентори и helpdesk-ов, то может быть это можно сделать и собрать денег. Самое сложное - собрать денег, т.к. люди должны увидеть серьезность проекта и этих людей должно быть реально много. А из-за того, что их много, вы с ними этот функционал не согласуете никогда, поэтому вам (автору биллинга) придется ваше виденье реализовать - поэтому нельзя делать широкий функционал. Вы слышали, что ежегодно в мире 80 миллиардов долларов тратится в софтверной индустрии на реализацию требований, которые никогда не используются? Вы же не хотите потратить своего времени годик впустую?
Советую Вам (инициатору) написать ТЗ. Если это будет хороший документ, Вы может быть найдете людей, которые смогут это реально поддержать.
Я бы для упрощения реализации написал бы конфигурацию к FreeRadius2, которая бы собирала данные в базу, написал бы процедуры обработки к этим данным и веб-интерфейс и этим ограничился бы для начала. Люди меняли бы процедуры обработки (а это делают все), но продолжали "иметь сертифицированный биллинг" (хотя мы то с вами понимаем...) - это закрыло бы проблему.
В свое время был такой проект FreeNIBS - популярный был, он представлял собой доработку к FreeRadius, где код биллингования был вставлен в MySQL модуль (C модуль, который сохранял данные в базу, ну вот тарификация была вставлена туда же). Проект как-то свернулся потом, как и многие другие - автор утратил интерес. Поэтому нужен фонд. Ибо кто будет сертифицировать?
Но в C я бы тарификацию делать не стал - сделайте отложенную тарификацию на процедурах - пусть будет лаг, уверяю вас небольшой минус за реально полученные услуги это не проблема; большая (ударение на о) проблема это код на C или свой радиус. Нужно меньше нового кода.
Но никто не поддержит это со старта. Любой проект начинается или с полезного хоть как-то работающего приложения (обычный вариант OpenSource), или хотя бы с понятной документации, что это будет (обычный вариант с инвестициями).
Для NetFlow, я бы рекомендовал испльзовать flow-tools в качестве коллетора. В базу можно собирать как написано здесь.
Чтоб вам не пришло в голову расширять возможности в сторону helpdesk скажу, что проработав 10 лет в операторах связи по части автоматизации, я вижу что только в одном из десяти внедрений используется встроенная в биллинг система заявок. Это из-за сложности требований телекомов к таким системам. Вот с какими требованиями сталкивался я. Я предлагаю не делать это в биллинге, а делать это примерно так.
В общем резюмируя, рецепт такой:
1. Меньше кода, используйте имеющиеся коллекторы и радиусы.
2. Пишите документацию или сразу делайте проект, потом собирайте деньги на разработку или сертификацию.
