Будем поговорить, чем помогает проектам принцип открытости и для каких проектов эта модель распространения подходит
Как на этом строить бизнес и зарабатывать реальные деньги
Про свободу распространения софта, лицензию GPL, чем они помогают в сохранении последующей открытости проекта и форков, основанных на коде этого родительского проекта, в защите интеллектуальной ёмкоти проекта (заметьте, не собственности!)
Тема интересная...

Пишите в форму свои вопросы ребята!

У нас был прокол на ранних этапах с неграмотным выбором лицензии для некоторых модулей продукта (BSD - альтруисты, чтоб их за ногу трижды!) и неконтролируемой утечкой нашего кода в другой, закрытый продукт.
Практически это привело к сворачиванию инвестирования и самого стартапа.
У нас был rolling release, как и у многих сейчас, благодаря CI/CD системам и практикам.
Поэтому тут ещё вопрос в релиз-цикле и поставке продукта.
И нужно выбирать адекватную модель распространения и лицензию для этого, чтобы все взаимоотношения оставались в правовом поле, а игнорировать эти вопросы сейчас уже как минимум не профессионально, к примеру инвесторы и юристы с их стороны сейчас внимательно изучают лицензионный и патентный портфель любого интересного им стартапа, во многих инкубаторах есть штатные юристы, т.к. стартаперы о своих правах не думают (думают только о взятых обязательствах на инвестиции 😂), а защита проектов и помощь командам нужна, тем более это ещё и защита коммерческих интересов самого инкубатора!

Как писал Виктор Пелевин: "В наше время любой имидж имеет чёткое коммерческое выражение, даже если он подчёркнуто некоммерческий". 😄

Как мне сказал один очень грамотный человек из инвесторов, он бывший океанограф из aussie и занимался долго изучением экосистемы большого барьерного рифа, на мой взгляд он привёл отличную аналогию:

Сейчас, как и всегда, бизнес это длинная цепочка надбавочной стоимости, обработки и переработки...

Тут вы либо киты и акулы, которые питаются сами кем-то и никого не спрашивают (для таких китов либо GPL либо проприетарные лицензии для акул) 😂

Либо вы коралл, который строит экосистему - очень выгодно быть нынче кораллом и строить что-то своё 😂

Либо вы рыбка, коих большинство, которая чистит китам усы и акулам зубки, пасётся на кораллах и строит бизнес на партнёрстве и сервисе 😂

Но без рыбок никак, они важны, именно такие ловкие рыбки 😂, потребители B2B услуг, организующие свой SMB сервис

Доходчиво объяснил! 😂👍

По части Open Source, коммерческого и проприетарного софта в Linux, а также выбора открытой модели распространения и лицензии GPL Линусом Торвальдсом для проекта Linux, а это самый большой Open Source проект в истории, я буквально недавно постил свои соображения и его интервью на TED - рекомендую пересмотреть и перечитать перед митапом

https://telegram.me/technologique/327
https://telegram.me/technologique/328
https://telegram.me/technologique/329
https://telegram.me/technologique/330

Про многопоточность и сборку мусора (GC) в Go относительно реализаций Python, Ruby, JS и Lua...

Python, Ruby, JS и Lua, как динамически типизированные языки, поддерживающие сопрограммы для поддержки псевдомногопоточности, требуют автоматического управления памятью и сборщика мусора

CPython, PyPy и тем более Jython под JVM - имеют сборщик мусора (GC - garbage collector)
То же касается MRI/YARV, Rubinius, JRuby под JVM, для языка Ruby, V8 (Node.js/IO.js), Nashorn под JVM, для языка Java Script и CLua, LuaJIT для языка Lua

Реальная многопоточность в Python (как и в Ruby, в JS и в Lua) недоступна из-за GIL и боязни авторов эталонных реализаций (CPython, MRI/YARV, V8, CLua) повредить данные в других потоках, т.к. в языке нет адекватных средств и встроенного синтаксиса для простой и ясной работы с потоками, есть только async/await в Python, future/promise в JS/ES6, fibers/call-cc/continuations в Ruby и ключевое слово yield для создания итераторов и генераторов на базе сопрограмм и продолжений (continuations), но это всё не истинная многопоточность, а в лучшем случае green threads управяемые интерпретатором и GC

В Go же используется модель CSP (communicating sequential processes, взаимодействующие ПОСЛЕДОВАТЕЛЬНЫЕ процессы), основанная на модели механизма акторов и развивающая эту идею
Используюется специальный вид сопрограмм (coroutines), которые называются goroutines или go-сопрограммы (игра слов), для создания которых используется ключевое слово go
Go-сопрограммы по модели CSP используют передачу сообщений через каналы в другие go-сопрограммы для организаии многопоточности, многопоточного исполнения, синхронизации между потоками, ожидания приёма и передачи данных через каналы между потоками (go-сопрограммами)
Сами же go-сопрограммы являются потоками green threads (или fibers), которые управляются сборщком мусора (GC) и существуют внутри потока исполнения скомпилированной и запущенной программы на Go

Все эти реализации - Python (кроме Jython под JVM), Ruby (кроме JRuby, использующего Java threads в JVM, которые основаны также на модели акторов, но имеют параллельную природу и весьма сложны при обращении с ними в реальной разработке), JS (кроме Nashorn в JVM), Lua (СLua и LuaJIT) - однопоточны и их интерпретатор выстраивает внутренние потоки (green threads, fibers) в коде, при интерпретации порождаемого им байт-кода, в очередь событий, event loop, организованную на кольцевых буферах, низкоуровнево реализованных на стеке, которую обрабатывает в одном потоке, но асинхронно, поэтому складывается обманчивое впечатление некоторой одновременности выполения разных потоков, но не для машины, а для человека
Для машины же эта последовательность событий с микросекундными разницами в итоге складывается в миллисекунды задержек (latency) при реальном исполнении программы, что непотребно для высоконагруженных проектов

Python, Ruby, JS, Lua - по своей сути внутри интерпретатора имеют объектную природу и любой транслятор этих языков должен содержать GC основанный на алгоритме подсчёта указателей на объекты в памяти, это требование стандартов языков (например PEP в Python)

Поэтому в данных языках если неграмотно организовать работу с переменными и объектами в коде так, что они постоянно используются и не освобождаются после использования, например при помощи интроспекции типов и рефлексии объектов, тогда GC не будет их вычищать, пока имеется хотя бы один указатель-ссылка переменной на объект-контейнер типа данных в памяти
Это приводит к зависшим потокам (green threads), перерасходу и утечкам памяти - память не будет освобождаться GC и потоки (green threads) будут просто висеть в памяти
Такой эффект называется постоянство памяти (persistence of memory) и напоминает одноимённую картину Сальвадора Дали (http://66.media.tumblr.com/67083591376832e41f6955187cbede74/tumblr_o5euotF2r71ugyavxo1_1280.png), где течёт не только память, но и время, что в принципе верно и для программирования, учитывая те же задержки (latency) в GC и интерпретаторах 😆

В Go то же самое с каналами, их нужно освобождать, но в Go с версии 1.5 новый GC написанный на самом Go и работающий на несколько иных алгоритмах, чем простой подсчёт ссылок и он теперь более агрессивно работеат с неактивными потоками и каналами

Нужно учиться программировать без сохранения состояния (stateless) в потоках исполнения - это хорошо подготовит вас к микросервисной разработке на Go с применением контейнеризации (Docker, LXC).

Хорошая иллюстрация того, как должен работать Garbage Collector, автоматическое управление памятью, или хорошо продуманное ручное выделение и освобождение памяти в коде...

Обратите внимание на волнообразный график расхода памяти - происходит её выделение... и освобождение! 👍

Автор Sublime Text, Джон Скиннер, точно знает как нужно обращаться с MemAlloc() и MemFree() в коде на C++ 😄👍

Говорят, что Джон Скиннер для Sublime Text реализовал не только свой кроссплатформенный графический toolkit на C++, но и Garbage Collector для редактора и движка регулярных выражений (на базе Oniguruma) собственной реализации, с оптимизированной динамической JIT компиляцией регулярных выражений!
Но так ли это - только догадки реверс инженеров.
А пока исходный код редактора Sublime Text закрыт, но есть открытый plugins API для Python 3! 😄👍

#Явпечатлён
#IhaveImpressed

Вывод из сказанного выше следующий...

Нужно сразу изучать и практиковать язык мощный и современный и не тратить попусту время на остальное, что считается очень модным, потому что мода на языки быстро меняется и завтра может оказаться, что оно лишь считалось очень модным 😆

Современный мощный язык должен содержать в себе и поддерживать параллельную многопоточность (механизм акторов) и/или асинхроную многопоточность (CSP на сопрограммах и каналах), и многие вещи/фичи, которые пришли из функционального программирования в императивное, это параметрический (импредикативный) полиморфизм (generics), сопрограммы (плюс итераторы и генераторы, yields), лямбда функции (анонимные функции), динамическая типизация, динамический вывод, идентификация и определение типов данных (RTTI, type inference), интроспекция типов, рефлексия языка, другие высшие абстракции типа монад (как в Haskell) и объектов высших порядков/классов (first-class objects)

Что-то типа Go, Rust... и Scala!
Да, я сам когда-то на ней очень увлечённо кодил, но бросил в пользу Ruby и продолжать не стал, кажется помню из-за слабого синтаксиса циклов и итераторов, которые в Ruby можно выразить 10-ю разными способами 😂, что мне понравилось, а вообще Scala очень крутая вещь и правопреемник Java!
Всё, @Luger_08 снова заразил меня этой идеей Scala!
Вот зараза! 😂

E - Evolution

http://turnoff.us/image/en/its-evolution-baby.png

http://turnoff.us/geek/its-evolution-baby/

Просто наикрутейший сайт по Large Enterprise разработке!
Очень рекомендую!

https://dzone.com

Черновик примечаний к будущему релизу Go 1.7, который состоится ориентировочно в августе этого года.

Изменения в основном касаются стандартной библиотеки.
Производительность порождаемого компилятором кода и синтаксис языка практически никак не изменятся, расширения языка ждать пока не стоит, Go достаточно стабилен!

https://tip.golang.org/doc/go1.7

Вот и сложилась вся картина этого паззла воедино!

Кто-то ещё думает что у Microsoft всё получится на мобильном рынке!?

Люди не хотят пользоваться Windows ещё и на своих персональных мобильных устройствах!

Прощай Microsoft!

И снова привет Nokia!

https://youtu.be/XnbbqetTqGg

В начале 2017-го года, когда закончится соглашение с Microsoft, брэнд Nokia реинкарнируют.
И уже есть первый прототип смартфона, Nokia C1 на Android, который готовится к выпуску в будущем году и который откроет собой первую серию линейки девайсов Nokia на Android.
Как ни крути, а девайсы от Nokia всегда славились качеством сборки, материалов, оптики и аппаратных компонентов железа.

http://www.gsmarena.com/nokia_c1-6885.php

http://company.nokia.com/en/our-businesses/nokia-technologies/hello-again

http://company.nokia.com/en/news/press-releases/2016/05/18/nokia-signs-strategic-brand-and-intellectual-property-licensing-agreement-enabling-hmd-global-to-create-new-generation-of-nokia-branded-mobile-phones-and-tablets

http://hmdglobal.com