Меня недавно спросили в разговоре: «Какие отрицательные недостатки вы заметили в сообществах JavaScript и / или с открытым исходным кодом?». Я стараюсь видеть в вещах хорошее, поэтому на ум сразу ничего не приходит. Но быть конструктивно критичным и видеть хорошее в вещах не исключают друг друга, поэтому у меня должен был быть ответ.

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

В то время я возглавлял команду из 6 разработчиков, включая меня, и вместе мы все работали над довольно крутой технологией. Вкратце, это были Uber for Kids… Correction, Uber Pool for Kids, а созданные нами приложения были номинированы на звание самых инновационных технологий года в Бостоне (см. Ниже). Нам нужно было создать 3 приложения: приложение для бронирования поездок для родителей, приложение для управления маршрутами для водителей и приложение для администрирования автопарка для компании (нашего клиента), чтобы управлять своими операциями. Заказов по требованию не было ... родители должны были заказывать поездки заранее, а затем за 24 часа до дня / времени поездки наши сложные алгоритмы должны были обработать серию оптимизаций маршрута, которые:

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

Этот алгоритм должен был быть точным и точным, учитывая высокие ожидания родителей и ограничения бизнес-модели. При выборе подходящего стека для этого мы рассмотрели несколько сервисов и библиотек. Обработка в режиме реального времени и сложные запросы - вот что в конечном итоге повлияло на наш процесс принятия решений. RethinkDB - это то, с чем я работал в прошлом, поэтому, естественно, это было одним из первых вопросов, о которых я попросил мою команду. Я обнаружил, что его синтаксис запросов является одним из самых чистых, самых элегантных и интуитивно понятных синтаксисов, которые я когда-либо использовал, и в сочетании с присущими ему возможностями реального времени это было просто проблемой! Однако его преемственность в то время ставилась под сомнение. Я нашел эту новость очень разочаровывающей. Я подумал про себя: Чувак, если бы каждый разработчик, который использовал RethinkDB, просто вкладывал бы небольшую ежемесячную сумму, мы могли бы помочь команде Rethink сохранить свет, возможно, даже получить прибыль, которую, по моему мнению, они, безусловно, заслуживают.

Но никогда не бывает так просто. Создателям / разработчикам, выводящим на рынок новые крутые технологии, приходится принимать непростые бизнес-решения ...

  • если я беру ежемесячную плату за обслуживание своей технологии, я рискую замедлить внедрение (авантюра)
  • если я беру ежемесячную плату за обслуживание, но добавляю уровень freemium, каково правильное сочетание функций, которые я распределяю между freemium и платными уровнями, чтобы не отпугивать мелких клиентов платой за подписку, а ограничивать их преимущества ровно настолько, чтобы стимулировать платные обновления как они растут? (тоже авантюра)
  • если я открою исходный код своей технологии, то мне может повезти, если я буду продавать некоторые премиальные услуги, такие как внедрение / масштабирование / консалтинг (также риск)
  • мне следует использовать модель, основанную только на пожертвованиях? (тоже авантюра)

Прежде чем я открою эту статью, я хочу немного поработать в моем направлении. Если нам, как пользователям / разработчикам, посчастливилось обладать удивительными технологиями, которые упрощают опыт разработчиков, как мы, пользователи / разработчики, можем защитить их, развить, сделать их устойчивыми и обеспечить непрерывность, чтобы мы никогда не теряли фантастические технологии, такие как RethinkDB? (* Примечание RDB ниже)

Ну вот как! Когда мои дети попадают в беду или совершают ошибку, их естественная реакция - извиняться, а затем ожидать мгновенного прощения только потому, что они сказали «извините». Мой ответ обычно такой: «Не говори мне, что ты сожалеешь, покажи мне, что ты сожалеешь». В том же духе, не говорите мне, что вы благодарны, покажите мне, что вы благодарны.

Итак, создателям крутых технологий, как мы можем «показать» им, что мы благодарны? Это просто: нам нужно открыть ваши кошельки (даже если нас об этом не просят) и / или пожертвовать свое время.

СКОЛЬКО Я ДОЛЖЕН ДАТЬ?

Это зависит. Для приложения Uber для детей, описанного выше, мы в конечном итоге выбрали поставщика Backend-as-a-Service под названием Graph.cool, и в течение нескольких месяцев, пока мы все еще находились в режиме разработки, объем нашего использования не гарантировал / не оправдывал того, что мы вышли из их плана freemium. к их следующему платному плану. Это потому, что Graph.cool чрезвычайно великодушен с ограничениями на использование и чрезвычайно удобен для запуска. Мы обсудили варианты с нашим клиентом и решили делать пожертвования / платить ежемесячно на 2 уровня выше нашего уровня freemium. Опять же, нам не нужно было этого делать, мы выбрали это, и с тех пор это моя практика. Короче говоря, то, сколько вы даете, должно зависеть от того, сколько вы получаете! Итак, сколько мы получили от Graph.cool?

ЗАЧЕМ ПЛАТИТЬ / ПОЖЕРТВОВАТЬ, ЕСЛИ ЕСТЬ УРОВЕНЬ FREEMIUM?

Это просто: сервис Graph.cool сэкономил нам примерно 120 часов на затратах на внутреннюю разработку, которые в противном случае нам пришлось бы понести. Graph.cool сэкономил нам более 10 000 долларов США. Выплаченная сумма уровня, которую мы решили жертвовать каждый месяц, была наименьшим, что мы могли сделать для команды Graph.cool, чтобы «выразить» нашу благодарность.

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

Expo.io - еще один сервис, с которым я испытал колоссальный прирост производительности. Это компания, поддерживаемая YC, но даже это не обеспечивает устойчивости рынка. Наши пожертвования / поддержка укрепляют их способность постоянно обновлять опыт разработчиков React Native.

Что делать, если я не могу пожертвовать деньги

В прошлом году на рынок вышла новая библиотека под названием React Navigation. Поскольку сообщество React еще не консолидировалось на стандартном API навигации, эта библиотека была долгожданной. У них было немного ухабистое начало, и многие поспешили пожаловаться; многие были неуместно отрицательными. Я поделился некоторыми из их разочарований и понял, откуда они взялись, но они не должны были быть такими резкими и неконструктивными в Github Issue Tracker. Я подумал про себя, вот команда, пытающаяся продвинуть сообщество javascript, которое свободно отдавала свое время только для того, чтобы увидеть тон неблагодарности? Некоторые разработчики действовали так, как будто библиотека была им обязана, что ее нужно было настроить или переделать, чтобы она соответствовала их собственным потребностям / запросам. У этих разработчиков было чувство права, которое немного отталкивало. Я помню, как высказывал некоторую конструктивную критику, но старался относиться к ней уважительно и тактично. Но затем на сцену вышел кто-то новый. Спенсер Карли. Вместо того, чтобы жаловаться, требовать или усугублять проблему, он присоединился к команде, чтобы быть частью решения. Я ценил его лидерство, и он был для меня отличным примером того, как мы все должны составлять себя как разработчики, получающие бесплатные технологии. Спенсер помог авторам улучшить их документацию и помог сделать отслеживание проблем более организованным и контролируемым. Так что, если вы не можете пожертвовать деньги, сделайте пожертвование! Отправить PR. Улучшайте документацию. Создайте демонстрационное приложение, демонстрирующее библиотеку. Примите участие в его продвижении. Отдайте свое время так же, как и создатели! И если мы не можем сделать что-либо из этого, как минимум, давайте оставаться позитивными и стильными в том, как мы взаимодействуем с авторами, которые любезно делятся с нами своим временем. Им не пришлось. Они выбрали это.

Что делать, если я не могу пожертвовать свое время?

Может быть несколько причин, по которым вы не можете тратить свое время. Возможно, ваша тарелка уже переполнена. Возможно, у вас еще недостаточно опыта, чтобы отправить PR. Какими бы ни были ваши причины, я уверен, что они оправданы. Вот что вы можете сделать вместо этого: распространять любовь. С гордостью расскажите о своем технологическом стеке, возможно, на экране настроек или в нижнем колонтитуле вашего сайта. Расскажите другим разработчикам о своем стеке, его зависимостях, используемых сервисах и почему вы выбрали их. Будьте сторонником любимых технологий. Будьте евангелистом! Подпитывайте их принятие! Во много раз это больше, чем любое денежное пожертвование, которое вы могли бы отправить.

ЗАКЛЮЧЕНИЕ

Вспомните время, возможно, 10 или 15 лет назад, когда было значительно меньше инструментов, меньше библиотек, меньше проектов с открытым исходным кодом и меньше фреймворков. Да, когда вывод новых приложений на рынок занимал от 6 до 12 месяцев или даже больше. Мы пишем код за день, когда мы можем вывести на рынок потрясающие приложения всего за 2 или 3 месяца, предоставленные вам энергичным сообществом JavaScript и открытым исходным кодом. Можете ли вы представить, что вам нужно написать приложение на простом ванильном javascript, без помощи Axios, Apollo, или даже Angular, React Native или Vue? Конечно, за некоторыми из этих технологий стояли титаны, обеспечивающие их внедрение, но многие, такие как Redux, стали популярны отчасти потому, что мы, разработчики, так или иначе поддерживали их. Давайте всегда помнить о щедрости в том, как мы поддерживаем этих создателей, как они были с нами! Я надеюсь, что бесплатно никогда не станет причиной отказа от великого проекта. И то, что вам не нужен платный уровень, не означает, что вы не должны его получать! Давайте поддержим этих создателей и сохраним инновации живыми и устойчивыми!

Примечание RDB: RethinkDB обошла Grim Reaper и, к нашему большому облегчению, в конце концов нашла новый дом в Linux Foundation.