Точно това съм го разбрал прекрасно - такива като Бонго още не са го разбрали .

По мое скромно мнение тъй-нареченият съпорт, на който разчита средностатистическият потребител след като се изръси една камара пари е една голяма измама. От мой личен опит, примерно с Microsemi Libero, който по принуда ползвам на работа, имах проблеми с библиотеките на една матрица. Обаждам се на регионалния представител, който за нещастие познавам лично. Той ми казва - опиши проблема и ми го прати на имейл. Отделям 15 минути за описване на проблема и му го изпращам. След 3 (три) дена ми се връща имейл с препратки към разни даташитове, които естествено съм изчел преди да се обърна за т.н. съпорт. Отделям още 15-20 минути да опиша как съм прочел въпросните листовки, как съм включил библиотеките в проекта, как съм внимавал да не включвам несъвместими библиотеки и т.н. След още 2 дена ми се предложи да му изпратя проекта, въпреки че знае че проекти не бива да напускат компютъра ми и сървъра, на който работя. След като му отказах ми се отговори че либеро бил hits and misses и предположи че проблема е в последната версия на продукта и ми предложи да инсталирам предна версия и да пробвам с нея, след което го зарязах. Проблема с библиотеката го реших като ръчно коригирах компонентите в съществуващата проблемна, така че да не ми реве компилатора. За продуктите на Микрософт няма да повдигам въпрос изобщо. Опън сорс не е просто безплатен продукт без подръжка, има опън сорс продукти без аналог, като Python примерно, други опън сорс проекти се използват за база на комерсиални продукти - примерно MPLab X на Микрочеп e базиран на Netbeans, компилатори на ST и NXP и Renesas са базирани на Eclipse, има Матлаб алтернатива - Scilab, който се ползва от Рено и Еърбъс, специално при Scilab има сертифицирани специалисти, които предлагат подръжка, така е и с други продукти, като Линукс примерно. Неслучайно опън сорса се предпочита от научните среди, голяма част от опън сорс проектите са добре документирани, други имат голяма общност с достъпни форуми, където се предлага безплатна помощ. И защо ми е тогава съпорт, след като първата работа на къстъмър сървис е да ме прати да чета техн. документация? Както споменах - изказвам лично мнение, лично аз подкрепям отвореният код и често съм правил дарения, не е до парите,

ЛибреПЦБ се опитва да спазва интерфейса на eagle - въртене на десен бутон и т.н.


Това че нещо е трудно не значи че за мен като потребител е полезно да им стоя на историята. Всеки софтуерен проект стига до тази фаза - по вашия край май му викат "да се изчисти technology debt-а". Грешно е да се мисли че del на папката със сорсовете е почване от нулата - след това сакрално действие остават натрупаните знания, концепции, спецификации, issue-та и акъл в главите на спецовете.
Преди 20 години изискванията, поставени от клиентите (дето като имена на фирми ги няма на 80% поне) са били едни, в момента са излезли много нови изисквания и са отпаднали стари такива. Технологиите са се сменили (примерно много ядра на CPU-то, ускорение в GPU-то). Няма как код база, написана да отговаря на старите такива да почне да отговаря на новите само с дребен refactoring - поне не и на езиците, на които се пишеше по онова време.
За мен новината че се хващат да пренаписват беше много радостна - с ясното съзнание че ще им трябва много време да го докарат до еквивалентна функционалност. Което си е сериозна инвестиция, понеже ще трябва да поддържат и старото. И не е ясно накрая колко е трябвало да трият, преди да почнат да карат нагоре.
Наскоро имаше тема, май за ментора, дали може правилата да се експортират и импортирам между проектите. При алтиума в общи линии може, стига да се спазват донякъде концепции при писане. Ако при ментора наистина не може е голям автогол - все едно да си пиша наново компилатора за всеки следващ проект, или поне препроцесора?
Идеята за GPU DRC е щото си мисля че това е много близко до рендъринга - дали нещото ще се вижда или не, дали има пресичане, но като цяло математиката от множество паралелно изчисляващи процеси (правила), които добре биха паснали на няколко хиляди ядра.

Ами.. аз имам наблюдение над 3 различни продуктови линии които поддържаме. Едната е на принципа пипай възможно по-малко, части от кода може би са от преди 20 години, оправданието е пълно пренаписване е невъзможно защото трябва да се пуска нова версия мин на 3-4 месеца, а няма как да създадеш същият кор екип защото няма да има опит. ... промени с еправят бавно, някои неща стават ужасно трудно и неефективно. Въвеждат се промени но доста бавно.
Имаме и продукт който за последните 12 години е писан 4 пъти, първият път нямахме никаква идея с какво точно сме се хванали, вторият път вече знаехме че жълт сняг не се яде, третият път всички грешки на прохождането бяха решени, четвъртата версия се релийзва в момента. Първите 3 ги релийзнахме за период от 5-6 години може би, в момента при четвъртата въпреки че има много съществена промяна в концепцията на работа успяхме да използваме и голяма част от кода писан за 3-та. Горе долу 3 пъти сме почвали от около 0 като код, последният път от около средата. Това по никакъв начин не е забавило или попречило на развитието на продукта, напротив.
Аз лично съм на мнение че пренаписването от 0 е много полезно, след 2-3 итерации вече няма да се налага да тръгваш от 0.

Аз пък к'во съм имал на компа, идея нямам кога съм го заредил:
https://en.wikipedia.org/wiki/GEDA
Пуснах го - работи. За повече нямам време сега.

Гичо - както се спомена -опцията -експорт-импорт на ДРЦ баш я няма но има друг начин за рещаване на таз задача.
Когато експрт/импорт руловете при Алтиума това е един вид темплеит.Е при ПАДС про и Експедишъна тоя темплеит е на друго място.