Takers, Givers and Matchers in Open Source

Recently, a friend sent me a link to the TED talk appearing below:

I found the talk not only interesting, but also it made me think about the Open Source world, trying to apply the same concepts and thinking. I rapidly realised that the Open Source world also has its own set of Takers, Givers and Matchers.

So, let’s talk a little bit about Open Source Givers. The givers will be those who either initiate in open source project, constantly contribute to open source projects, preach and promote the usage of open source as a way of life and most importantly – they do so not because of a commercial or financial agenda – they do so because that’s what they believe in. These include people like John “Maddog” Hall, Linux Torvalds, Richard Stallman, Brian Kernighan, Dennis Ritchie and many others. These people operate under a premise that their work is vitally important, not the world, to mankind and the well being of others.

So, who are our Open Source takers? sorry to say, the number of Open Source takers is far greater than that of the givers. The takers are your “Script kiddies” or “Closed integrators”. Those people who use and abuse Open Source without acknowledging its existence.  In Israel, as an example, when Open Source was still in its infancy stage – people were roaming about claiming that they created a specific project or other. For example, I recall that in 2006, a company in Israel claimed it was the creator of Asterisk – and that their AMP based PBX system is their own creation. How Rude!

Who are your Open Source matchers? matchers are people who jump from being a giver and a taker according to their requirements. These people utilize open source projects, contribute code from time to time, promote the project – nominally due to a business reasoning – and these constitute a slightly bigger portion than the givers. While Open Source innovation relies on Givers, it’s progress into the business world and adaptation to the enterprise relies mostly on Matchers. Takers do not promote the Open Source industry, in some extreme cases, the actually harm the industry.

So, are you a giver, matcher or a taker?

Digium D65 – More than a Home Run!

I love the feeling of unboxing a brand new IP phone, specifically, when it’s one that comes from Digium. Yes, I’m a little biased, I admit it – but I’ll do my best to refrain from dancing in the rain with this post.

So, during ITExpo 2017 (Ft. Lauderdale, Florida), Digium unveiled their new D65 Color Screen IP phone. Malcolm Davenport and the good people at Digium were inclined to send me a couple of phones for testing, which I was fairly happy to do – specifically due to the addition of the Opus Codec to the hardware.

If you are not familiar with Opus – you had most probably been living under a rock for the past 3-4 years. Opus is the codec that makes tools like Skype, Hangouts and others work so well. Unlike the traditional g7xx codecs, Opus is a variable bit rate codec, provides HD voice capabilities, has superior network conditions handling (via FEC) and in all – is a far better codec for any VoIP platform. You’re probably asking what is FEC? I’ll explain later.

Consistency and simplicity are a must – and Digium phones are both. One of the things I really like about Digium phones is that they are simple to configure, even without DPMA. The screens are identical to the previous models and are so tight together, that getting a phone up and running takes no longer than a few seconds.

Minor disappointment – the phones were shipped with a firmware that didn’t include the Opus codec – so I had to upgrade the firmware. Ok, no big deal there – but a minor nuisance.

So, I proceeded to get the phone configured to work with our Cloudonix.io platform. What is cloudonix.io? Cloudonix is our home-grown Real Time Communications Cloud platform – but that’s a different post altogether. This nice thing about Cloudonix is that it utilizes Opus to its full extent. Ranging from dynamic Jitter Buffering, Forward Error Correction across the entire media stack, Variable bit rate and sample rate support (via the Cloudonix.io mobile SDK) – in other words, if the Digium phones performs as good as the Cloudonix.io mobile SDK – we have a solid winner here.

So, I hooked the phone up and then proceeded to do some basic condition testing with Opus. All tests were conducted in the following manner:

  • Step 1: Connectivity with no network quality affects
  • Step 2: Introduction of 5% packet loss (using `neteq`)
  • Step 3: Introduction of 10% packet loss (using `neteq`)
  • Step 4: Introduction of 15% packet loss (using `neteq`)
  • Step 5: Introduction of 20% packet loss (using `neteq`)
  • Step 6: Introduction of 25% packet loss (using `neteq`)
  • Step 7: Extreme condition of 40% packet loss (using `neteq`)

Test 1: Media Relay and server located under 150mSec away

  • Step 1: Audio was perfect, HD Voice was exhibited all the way
  • Step 2: Audio was perfect, HD Voice was exhibited all the way
  • Step 3: Audio was good, HD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 4: Audio was good, SD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 5: Audio was fair, SD Voice was exhibited all the way, moderate network reconditioning at the beginning, till FEC kicks fully in
  • Step 6: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 7: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in

Test 2: Media Relay and server located under 250mSec away

  • Step 1: Audio was perfect, HD Voice was exhibited all the way
  • Step 2: Audio was perfect, HD Voice was exhibited all the way
  • Step 3: Audio was good, SD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 4: Audio was good, SD Voice was exhibited all the way, moderate network reconditioning at the beginning, till FEC kicks fully in
  • Step 5: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 6: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 7: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in

Test 3: Media Relay and server located under 450mSec away

  • Step 1: Audio was perfect, SD Voice was exhibited all the way
  • Step 2: Audio was perfect, SD Voice was exhibited all the way
  • Step 3: Audio was good, SD Voice was exhibited all the way, minor network reconditioning at the beginning, till FEC kicks fully in
  • Step 4: Audio was good, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 5: Audio was fair, SD Voice was exhibited all the way, major network reconditioning at the beginning, till FEC kicks fully in
  • Step 6: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in
  • Step 7: Audio was fair, SD Voice was exhibited all the way, extreme network reconditioning at the beginning, till FEC kicks fully in

Ok, I was willing to accept the fact that if I’m able to carry a good audio call, for almost 3-4 minutes, while `neteq` was introducing a static 20% packet-loss condition – sounds like a winner to me.

All in all, till I get my hands on the Digium D80 for testing it’s Opus capabilities, the D65 is by far my “Go To Market” IP Phone for desktop Opus support – 2 thumbs up!

Goodbye Elastix – we will miss you

Last week marked a sad point in the history of Open Source, the highly acclaimed and established Asterisk distribution was taken down from the Internet, leaving all of its users, followers, eco-system, resellers, integrators and more with a gigantic void to be filled.

While the void will be filled at some point, I can’t but help but observe the joy and cheerfulness of the proprietary telecommunications industry, as 3CX had rapidly taken over the Elastix business in such brutal manner. According to the various discussions in the Open Source community, the entire thing was cause by, a so called “violation of copyright” or “violation of IP” of some sort, within the Open Source communities. In the past, as far as I know, when various distributions or projects violated each other’s copyright, they would notify one another – and would ask to rectify the situation. Apparently, this hadn’t happened here – or if it happened, it wasn’t published in an open manner – as you would expect.

One of the things that the community started shouting was: “Elastix had been trixboxed”. Honestly, I don’t see the similarity between the two cases. When fonality acquired trixbox, they had a clear indication of where they are going. This is not 3CX acquired Elastix, this is 3CX obliterated Elastix. This is something completely different – and with major personas in the open source community indicating that a certain, well known and renowned, Open Source persona was involved in this happening, I can only be highly offended by the everlasting stench of people’s own ambition and personal hatred towards things that are not their own.

I admit it, I never really used Elastix in my projects, I found it to be bloated, inflated with software that shouldn’t be there, too slow for my taste and with a lack of proper project leadership, patches went in and out like crazy. Yet, I can’t argue with their success and the acceptance of the product around the world. I remember being at VoIP2Today in Madrid only a few weeks ago, and there were Elastix boxes sitting on tables. Yes, Elastix wasn’t my first choice for an Office PBX, but yes, they were a choice – the idea of a commercial company coming in and removing that choice off the table – is just annoying and troubling at the same time.

My hope is that some Elastix developers will simply post the entire source code to Github or some other public repository, slapping a BSD/MIT license on their work – telling the world: “Here is our creation, the proprietary daemons decided it should die – but no one can kill an idea!” – and Elastix will keep on living in the Open Source like other projects. If the world will forget it, then so be its fate – but if the world needs it, let the world take it in two hands and raise it up to the sky and say: “You shall not die!”

 

Python should be the first language you learn!

For the better part of the past 15 years, I’ve been a PHP developer. Really, I’ve developed everything in PHP, ranging from server side services, web services, backends – you name it, I’ve probably done it with PHP. Don’t get me wrong, I love PHP and it will always remain my language of choice for doing things really fast.

However, for the past year I’ve been increasingly developing with Python. I’ve always dabbled with Python, but never really had the chance to truly get down and dirty with it. Due to a couple of projects during the past year, specifically ones that involve Google AppEngine, I’ve had to sharpen my Python skills and get to a point where I can develop with the same agility that I have with PHP. Honestly, it wasn’t simple – sometimes I truly wanted to strangle someone with various errors a framework can spit at you. However, once you get around to reading the various cryptic messages Python may spit at you, getting around it and working with it is truly a delight.

So, why do I think Python should be the first language one learns? so here are my thoughts:

I started my coding days with BASIC, to be more accurate GW-BASIC (yes, I am that old). From that I moved to Pascal (Turbo Pascal to be more accurate), then C, then C++, C++ Builder, Visual C++ (yes, I did MFC at some point in my life as well). I then decided that my life is in the open source world – and thus, the track then went to PERL, JAVA and of course PHP. Honestly, somewhere around 2005, the mixture of C, JAVA and PHP truly gave me all the power I needed to do my job – so, I didn’t really find the time to learn a new language.

Then, about a year ago, I decided it’s high time to learn something new – specifically, I became increasingly interested in the Google AppEngine platform. Yes, I’ve been using Google Compute and other cloud platfroms for a few years now, I’ve used most of Amazon’s services, ranging from EC2 up to RedShift and their hosted Hadoop clusters. But when Google AppEngine came out, it only had Python, Java and GO to work with. Java is the least favorite language in my tool box – honestly, I hate it. I’ve never coded in GO, and didn’t really feel like starting out with it. And Python, well, I dabbled with it – but can’t say I’ve done something too serious with it. In 2014, Google added PHP support to Google AppEngine. Damn, that sounds cool – let’s play around with that. So, I built a few applications atop of AppEngine and the PHP SDK. I rapidly realized that while the PHP SDK gives you some power, Python is the more natural choice for AppEngine. So, I more or less sat my ass down for 3 days and decided to teach myself proper Python.

Took me about 3-4 days to get around the quirks of AppEngine and how to get it up and running using PyCharm (if you use Python, by far the best IDE I’ve seen). Then building up my first application, then migrating an existing application (a fairly big one), from PHP to Python on AppEngine. I then rapidly moved along to using easy_install, pip and the other Python tools that make life so easy for developers – honestly, right now, I can’t figure out why use anything else other than Python for shell environment tools. But, regardless of that, I honestly think Python is the first language you should teach students, not C/C++, not JAVA, not Ruby and surely not PHP (and I’m a huge PHP advocate).

Why do I say this? here are my main reasons:

  1. Python is objected oriented from the ground up, which means, that teaching object oriented programming using Python is easy and straight forward for new comers.
  2. Python is strong typed, which means that syntactical issues are dealt harshly – promoting proper usage of syntax, indentation, capitalization, variable handling – all the nice things that make good code – readable code.
  3. Python’s physical typing construct, where blocks of code must be tabulated in specific manner in order to make the code work in specific manner – is GENIUS. I’m very much a “Source Code Nazi” (Imagine that coming from a Jew, right?). For me, indentation, proper loop blocks, proper case blocks, making sure things are wrapped really tight without too many white spaces – this is what makes code look nice.
  4. Python is interpreted, not compiled – but yet, it is strong enough to hold the most complex multi-threaded of tasks.

In other words, if you take the above and teach to a new developer, someone who writes code for the first time in his life – your result will be a developer, that may not dish the best code at first (after all, a beginner), but it will be readable, manageable and maintainable. Python automatically promotes these by its structure, by its rigidness and by its agility at the same time.

As part of my academic studies, I’ve studied education and how to teach computer science to high school students. I’ve learned that you should start with Pascal or C, then move to Object Oriented, then move to more advanced stuff. I have one thing to say: BULLSHIT! Honestly, the first thing you need to teach is Python, after Python, the rest are just syntax. Nothing more, nothing less – pure, simple, straight forward syntax.

Would love to hear your opinion on this one…

Hyper Engagement – Enabled!

So, it has now been 2 months, since I started my own little social experiment. Early November, I decided to silence down all my mobile device notifications and mute any “distracting interaction” I could find. No, I didn’t silence off my mobile phone completely – it will just make it useless, but I didn’t make it as less intrusive as possible.

So, about 3 weeks ago I decided that it’s high time, to put my trusty Lenovo X1 Carbon Touch to its final resting place. I was contemplating what notebook should I get. My gut feeling told me: “Time for another Lenovo”. But, somewhere in the back of my head was this ever annoying question: “Is a Mac truly better?”. So, in a spur of the moment, I decided to buy a Mac. Because I am what you would define as a power user, I decided to get the most bang out of eace one of my spent dollars.

So, now I’m closing a month with my Mac and combined with my “Hyper – Not!” regime, I started a fairly lengthy road of re-getting used to using a Mac. Have to admit, El-Crapitan has its quirks. Who am I kidding, compared to previous versions, El-Crapitan is somewhat annoying. However, after getting used to its little quirks and kinks, when you combine the Good of the Mac and “Hyper -Not!” – I managed to reach at least a 40% increase in my productivity.

Time that used to be spent on waiting for things to launch properly and setting up on my Lenovo, just cut by almost 70%. Issues of the machine halting on me or requiring a reboot – gone. Issues that required me to go into Task Manager and seek a process to kill – gone!

In other words, I spend far less time on BS and more time on actual work that needs to be done. Previously, I was able to focus on 2 projects – tops. Today, I’m able to focus on 5 different projects and be involved with 2 more. Is it purely to moving to a Mac? I doubt it. Is it purely related to my “Hyper – Not!” regime, i doubt it as well. It must be a combination of the two. How long will I be able to keep this up? donno, I’ll keep you all updated on my findings.