The Changelog: Software Development, Open Source

Look, Slava and Mike are incredible guys and ridiculously smart. If Slava thinks "I wouldn't spend a dime of that money on IP" then you should do that for two reasons:

1) He's the original founder and should be respected out of courtesy.

2) He just gave you an amazing opportunity to not worry, so take it.

I explore more of my thoughts on Open Source license and the post-mortem on this just-released The Change Log podcast episode - https://changelog.com/podcast .

One of the things that we are doing is making sure to always license our code as MIT or ZLIB or Apache 2. This is a promise (and a legal one too) to developers that the ideals and values of Open Source will always be there, first and foremost. In fact, the license was determined by a community vote (see here: https://github.com/amark/gun/issues/17 ).

People have asked why others (like us) won't shut down in the same way Parse and Rethink have, I think the answer is simple:

5 billion new people are coming online by 2020 and the technical challenges of creating scalable systems still exists. So the opportunity is enormous and proportional to how scalable your system can be - which means decentralized tools will win out over time compared to their centralized alternatives.

Second, unlike attempts to sell support licenses or DBaaS or crippleware premium upgrades, we're taking the approach of partnering with developers/companies that build industry transformational product and solutions for governments and enterprises. We believe that if we can enable others to be able to create answers for the needs of large organizations, then we both can mutually benefit by creating revenue shared partnerships. This is already happening with several companies, and we're rolling out to a government (but I can't disclose who/what/how yet).

We think this will work, and it will pave the pathway for other Open Source vendors that a real business model can work, without any of the unfortunate alternatives strategies others have taken (open core crippleware, unlikely support licenses, struggling DBaaS). This creates the best "win-win-win" environment, where startups get to piggy back for free while governments and enterprises pay for the much needed technology solutions to handle the coming transformation.

What transformation am I talking about? Again, the 5B new people, the advent of IoT and every autonomous car or burrito delivery drone, and the demand for doing machine learning on the whole system, at a global scale - see this article on distributed machine learning with gun: http://myrighttocode.org/blog/artificial%20intelligence/part... .

This transformation won't succeed unless it can be built on top of truly Open technology, and that is why license is important.

I recently wrote a blog post on my favorite podcasts:

http://mlafeldt.github.io/blog/podcasts-2015-edition/

Here is the list:

* Beats, Rye & Types (http://beatsryetypes.com/) -- An entertaining podcast about music, food, and programming. I love listening to Michael Bernstein and Aaron Quint, especially when they're talking about Computology and Hip-Hop. A rather interesting mix. Also noteworthy: the only show in the list without a sponsor.

* Home Work (http://5by5.tv/homework) -- A weekly podcast for people who work from home. I'm currently able to telecommute once a week (which is great, by the way). But even if you're not in the position to work from home, this podcast offers many useful tips on productivity, work spaces, tools, and more.

* The Writer Files (http://rainmaker.fm/series/writer/) -- An in-depth look at the "habits, habitats, and brains of a wide spectrum of renowned writers to learn their secrets of productivity and creativity". I care a lot about writing. It's no surprise that I'm interested in the work habits of people who write for a living.

* The Binpress Podcast (http://www.binpress.com/blog/category/podcast/) -- A series of interviews with creators and founders on how they built a business around their digital products. I've always been fascinated by the idea of monetizing (open source) software and creating a sustainable alternative to working for someone else.

* The Changelog (https://changelog.com/podcast/) -- A podcast dedicated to "the intersection of software development and open source" covering a wide variety of topics. I tend to skip most of the episodes on web development, but I listen carefully to anything about Go, Rust, CoreOS, etc. Bonus: The Changelog Weekly newsletter is excellent too.

* Invisible Office Hours (http://invisibleofficehours.com/) -- Hosted by the smart and funny Jason Zook and Paul Jarvis, this podcast includes topics like side projects, launching products, and writing books. I've read all books by Jason and Paul. I also enjoy their weekly newsletters. As I'm writing this, I'm already excited about the third season of their show.

I tried making a living selling free software. It failed to provide revenue close to covering the stress I ended up dealing with.

I'm very much interested to know about these profit-making OSS projects.

How many of them are profitable enough that they are able to pay their developers $80K/year, which is the median salary for software developers in the US?

From what I can tell, the majority of them are "profitable" in the sense that someone else pays for developer costs. For example, when Guido van Rossum was at Google, Google paid for him to work 50% on Python development. The other core developers seems to be in similar situations. How many of them are paid by the Python Software Foundation?

The Django Software Foundation is profitable. It doesn't pay for any developers.

The Sage project didn't get a full time developer until 2016, and then only because of an EU grant.

Project Jupyter funds their developers. Their Form 990 schedule O for 2016 says they had $665,619 in contract labor. They could do this because they had $2M in grants.

These are for widely used projects.

Then there are the profitable OSS organizations like the Cloud Native Computing Foundation, which has operational control over Kubernetes. It charges high membership fees. I think it's best to interpret this as a way for Google, Amazon, and others to reduce their costs and prevent competition by commoditizing hosting. (See https://changelog.com/podcast/300 ).

MySQL made money from shaking the big scary GPL at people who didn't want to pay for Oracle. Some of the companies who dual-license under the AGPL use a similar tactic.

So, which profit-making OSS projects are you thinking of?

How many of them have the ability to pay 3 full-time developers (that seems to be the number of people at Hiri)?

How big was their developer/user community before it was able to pay for 3 developers?

I can research the last two questions - I just want names.

But if you don't know the answers, then perhaps your views of how projects with 100K+ users work might not scale down to projects with only 5K users. Yet 5K users willing to pay $100/year is enough to fund three developers full-time.

See also https://caddy.community/t/the-realities-of-being-a-foss-main... , which talks about some of the 'bad' and 'ugly' realities of being a F/OSS maintainer. And yes, I face some of those problem (like entitlement) in running my F/OSS project.

Note that that link is an example where the F/OSS project development was not sustainable as-is.

I was building scalable node applications a few years ago for a very large e-commerce player- millions of customers. I think node.js is a great platform, but its apparent simplicity means there are hordes, and I mean like 90+% of the community, that can "just get things done" without understanding what is going on under the hood at all. And to be fair, for most startupy types of companies that need to iterate fast, that is what you want to optimize for.

My interview screening question was pretty simple- "Is node.js single threaded or multithreaded?" And to most, they spit back the blogspam headline- "Single threaded!" I think the most correct answer is "its complicated" but would accept that because most people would say that is the "right" answer. So I would follow up with- "what exactly happens in a default installation if we have say... 5 requests come in at exactly the same time to just return some static content from disk?" (Node's default threadpool is 4). And here is where you could see their understanding just fell apart. Some would say they would be handled entirely synchronously, others completely in parallel- but then had no idea what the cause of the parallelism was. Very few actually understood that node is an event loop executing javascript backed by a threadpool for async operations.

Before reading this post, I was like eh this is a waste of time- its typical medium bullshit- they almost certainly found they were doing some blocking call in the event loop and then removed it and voila, 30x speedup. It was interesting because it was a lot worse! They spent all this time and hard work figuring out everything but what was taking so long in the event loop, and it seems that was the last place they actually looked.

Anyway, node can be a highly scalable platform (https://changelog.com/podcast/116) but you need to understand it or else it will bite you in the foot. When I was last doing this stuff, upwards of 80% of our time was being spent essentially just JSON.parse()'ing, and we were looking to move to protobufs to avoid that.

I was really excited about Elm after listening to The Changelog episode #218 (https://changelog.com/podcast/218). Elm is in the style of React, but the flavor of Haskell. For my part, I had a hard time with the syntax and functional approach of it from the get-go. It was very new and awkward to me, which was a speed bump to my adoption. However, I felt like it held the promise of allowing potentially better/ more maintainable code. Evan Czaplicki (the creator) and Richard Feldman (a prominent evangelist) both talk about how the Elm language and style led to more effortless refactorings in larger front-end codebases they were working on. Sounded really good to me! But, I eventually ended up leaving my Elm journey and starting my Vue journey because the Vue documentation was so good (comparatively) and the style of Vue felt more natural to me. It kind of came down to the question "how do I do CRUD with this?". For me, the story was easier and more fleshed out with Vue. Currently, I'm working with Angular 2 mostly because it had a more definite answer to this question than Vue. And, the testing situation seemed way more fleshed out than Vue's (at least at this point). But, I plan to check back in on both Vue and Elm in the next year or so to see where they've landed. I understand what people are saying about JavaScript fatigue, but there's also so much exciting and cool stuff happening in this space right now. It's hard not to love all this innovation.

> I think GitLab is at a cross roads and this setback might be the eye opener they need. Moving forward, they really need to re-evaluate how they develop and evolve GitLab.

Judging by their about team[1] page, they are currently short an Infrastructure Director. When you read their job listings, even for DBAs and SREs, it' all "scale up and improve performance." Very little "improve uptime, fight outages." One assumes it's upper management approving the job descriptions, so the missing emphasis on uptime, and redundancy probably pervades the culture. And again, judging by the team profile, they've hired very few DBA / SRE experts, and instead appear to have assigned Ruby developers to the tasks.

Perhaps they simply have to bet the farm on scaling much larger to sustain the entire firm, which is troubling for enterprise customers, and for teams like mine running a private instance of the open source product. Should probably review the changelog podcast interview[2] with the CEO and see if any quotes have new meaning after today.

[1]: https://about.gitlab.com/team/ [2]: https://changelog.com/podcast/103