sogrady

If you're referring to licenses that - at times intentionally - blur the definition between open source and proprietary, yes. It is not in favor of those licenses.

The implicit argument that these licenses singularly benefit SaaS is much more nuanced than is implied above, however, in that some licenses actively discourage SaaS (e.g. AGPL) and other open source projects (e.g. Postgres) have actively benefitted from SaaS (or more accurately DBaaS).

This article consists of a few highly selective observations, glued together by make-believe. Open source was the industry default? On what planet?

"Team, make everything open source by default, unless I tell you otherwise" --- said no CEO or other boss, ever.

We have a lot of open source; a lot of it is very advanced, and forms critical infrastructure, sure. But proprietary software has not gone away even slightly.

I disagree with this assertion. Twenty years ago, the average enterprise developer was mostly using proprietary software. Examples: Browser (e.g. IE), IDE (e.g. Borland), OS (e.g. Windows), application server (e.g. WebLogic), DB (e.g. Oracle), CMS (e.g. Vignette), etc.

Today, the enterprise stack is dominated instead by OSS options: Browser (e.g. Chrome), IDE (e.g. Eclipse - VS Code is mostly open source, but includes proprietary elements), OS (e.g. Linux), application layer (e.g. Kubernetes), DB (e.g. Postgres), CMS (e.g. Drupal/Gatsby/WordPress), etc. Which is not to mention the thousands of underappreciated open source dependencies that applications rely on.

Proprietary software has certainly not gone away, and will not depart any time soon. But the implicit claim that nothing has changed in the balance of power between open source is not supported by the available evidence.

> Open source licenses, after all, offer the same equitable terms to all players, and limit neither competition nor usage.

Really? The sole proprietor of some GPLed program is on the same level as any other player?

In terms of their rights to and responsibilities for the source code? Yes. This is the express and intent and purpose of copyleft licenses. Knowledge of the source code may be asymmetric; the rights to it are not.

And how can you write a lengthy article on these topics without even mentioning what is probably the biggest issue to free software: it is not some "bait and switch" where open source projects get relicensed. It's that much software people use is now a service. The user has no control whatsoever; they are not even getting to install a binary executable on their own machine. The licensing is irrelevant to the end user.

Because this particular piece is about relicensing. There are other pieces about the topic you mention. This one from six years ago, for example, discusses the threat posed by the cloud to OSS software (https://redmonk.com/sogrady/2016/06/02/future-of-open-source...).

This entire article is about the bickering among developers: who gets what kinds of rights to which infrastructural pieces, with it being understood that everyone's shared goal is cobbing something together with those pieces in order to hold hostage the hapless users of some god forsaken SaaS application.

I'd argue that it's less about bickering between developers than the reality that commercial entities are using OSS licenses to grow their project traction, and once a critical mass is achieved, pulling the rug out from under developers with a non-open source license with more restrictive terms.

OK, so sure; if we put developer blinders on, open source is the default. My compiler is open source; my editor is open source; the OS is open source; the browser is open source; the database is open source. Hey open source is the default!

Precisely.

But don't forget the front end framework (e.g. React). The static site generator (e.g. Hugo). The testing framework (e.g. Playwright). The software catalog and developer portal (e.g. Backstage). And so on.

Meanwhile, Average Joe: social network isn't open source; webmail isn't open source; crap running in Joe's automobile isn't open source; Joe's phone isn't open source; Joe's TV streaming box isn't open source. Neither are the half dozen apps Joe relies on for this and that, or services like online banking. Almost not a single everyday use case or solution for the average user is open source. How can you talk about a default with a straight face. And this is just the consumer-facing stuff I'm talking about. For instance, let's switch to business. What enterprise runs their finances, operations and logistics on open source?

Average Joe generally isn't building a social network, a webmail offering, a car, a phone, or a streaming TV service.

Average Joe, in most case, just wants, say, a database. The easiest of which to acquire used to be open source but these days is as likely as not to have transitioned to proprietary software.

Which is not ideal.

By way of disclosure, I'm the author of the linked piece.

That said, having spoken to most of the parties involved prior to their decisions to relicense, I can tell you that investors were a major motivating factor in many if not all cases.

In certain instances, this was because a particular investor convened private meetings between groups of commercial backers of open source projects - both portfolio companies and not - to propose non-open source alternatives, and companies went along with it. In other cases, board members were swayed by arguments from these same investors. Either way, pressure to try and replicate proprietary software profit margins from investors was a significant, if not sole, motivating factor in the decisions in question.

If you look at the history of investors in many of the companies involved the pattern is notable.

glad to hear you got something out of it

Disclosure: I'm the author.

Appreciate the feedback, will keep that in mind in future.

There is not, though we have historical rankings for the top 20 available here: https://redmonk.com/rstephens/2019/03/20/redmonk-top-20-lang...

Ha! We get asked about CSS every time. Our general answer is that we try very hard not to editorialize, and let GitHub’s Linguist make determinations. We do make decisions, but to date, CSS has continued to make the cut.

As for how languages are used, we spend a lot of time trying to understand that broadly, and where the rankings reveal anomalous patterns (e.g. Kotlin a year or two ago) we do more targeted research to understand those.

I can understand why people criticize it, but I personally like Fi. The multiple carriers give me coverage in areas I don't expect it like Maine islands or the Sangre de Cristo foothills, and the price is reasonable if not the lowest available.

Additionally, the one time I've had to contact support, I had an email reply in 27 minutes.

Throw in perks like the seamless international support (if you travel internationally at all this is tremendous) and the data SIM for an iPad, and I've been pretty happy with the service.

That could all change the next time I need support if they're still overwhelmed with new users, but so far so good.

RedMonk | Analyst | US-based | Full-time

We're a small, developer focused industry analyst firm that researches a variety of infrastructure technologies from hardware to software. We're trying to help companies understand and adapt to a world that has changed, one in which developers are the new kingmakers.

We're looking for a data-driven analyst, ideally with solid quant skills (R or Python) and a passion for technology and the people who build it. Previous developer experience is not necessary.

You'll be working remotely unless you're based in Portland, Maine, but given the travel requirements we're looking for someone based in the US.

More on the role and how to apply here: http://redmonk.com/jobs/

If you can find analogies in which sports teams are willing to use solutions to play with fewer players or practice anything remotely close to loyalty and thus fit within the context of this, by all means let me know and I'll include them :)

Understood. We're always looking for better ways to visualize this data, so we'll bear these comments in mind.

This is more or less our position. COBOL has never been ranked, for example, because COBOL isn't highly visible on GitHub or Stack Overflow. The last time we checked, for example, COBOL was present in 11 total repositories on GH.

Which obviously stands in contrast to the reality that there are many enterprise systems - some of them mission critical - still running on the platform.

But from our perspective, that tells us less about what might be used moving forward than what is actively being discussed and written in by developers on the platforms we survey.

So no, we would not argue that these rankings accurately reflect the current distribution of languages within large enterprises. We do feel that the actions of a large number of developers from two different properties has the opportunity to be more predictive, however.

Setting aside the specific Julia functional merit questions, the answer is that in general, no, the difference between 51 and 52 is not particularly significant.

That being said, the macro perspective - in which Julia is growing more slowly than other languages, or arguably not at all - is relevant for those wishing to see more adoption.

Much of this is attributable to these rankings being counting stats rather than rate states, which makes age an asset. There's a surprising amount of Haskell in existence, but certainly if you're looking at rate at present Swift is growing far more quickly.

Dart held static at 37, which leaves it 11 spots behind TypeScript. We have seen very little movement in the language generally, and it hasn't really gotten any notable boosts from outside drivers.

The rCharts package we're using doesn't handle that, but if there's interest we can look into releasing a larger version.

The reasons you cite are certainly the reasons we found the original analysis by Drew and John compelling.

It's not a perfect analysis, in part because there isn't one, but we've found it interesting both as a snapshot in time and for observing long term trends.

RedMonk | Analyst | US-based | Full-time

We're a small, developer focused industry analyst firm that researches a variety of infrastructure technologies from hardware to software. We're trying to help companies understand and adapt to a world that has changed, one in which developers are the new kingmakers.

We're looking for a data-driven analyst, ideally with solid quant skills (R or Python) and a passion for technology and the people who build it. Previous developer experience is not necessary.

You'll be working remotely unless you're based in Portland, Maine, but given the travel requirements we're looking for someone based in the US.

More on the role and how to apply here: http://redmonk.com/jobs/

Disclosure: I wrote the linked piece.

When discussing the potential risks of data-oriented models, it's necessary to recognize that all data isn't created equal.

Facebook, Google and others are obviously trying to accumulate personal information in an effort to advertise more efficiently, but there are other models that involve no actual personal or company data. Operational telemetry, for example.

I might not want to share the data from a MySQL database, for example, but its operational characteristics: size, query length, query speed etc are substantially less concerning.

A company like New Relic, for example, could provide a service like the now discontinued App Speed Index because it has visibility into a large number of running application instances. This data, particularly in an aggregate form, poses little or no risk to customers that share it, but can be valuable to businesses that see its potential.

[Disclosure: I'm the author] No argument that up-front, perpetually licensed software is currently a huge, profitable business. Windows and Office alone, as acknowledged, generate essentially $44B by themselves. There are also profitable businesses that pursue the traditional perpetual license model - Palantir being perhaps the most notable example (although from conversations with employees there, they are increasingly being pushed towards alternative models).

But the point of the Software Paradox is not that companies are not currently and cannot in future make money from software, and that there are no exceptions to the rule, it's that the trajectory broadly is not promising. Looking across a variety of software categories, from mobile to operating systems to infrastructure to tooling to consumer, the trendline is downward in terms of their up-front realizable revenue potential.

None of which should be taken to mean that software is going away. If anything it's becoming more important, hence the use of paradox. But developers and companies seeking to monetize software should at least be aware of the market context which is that it's becoming more difficult to make money from it the way that it was possible to even a few years ago. Even the lock-in mechanism, which is correctly cited as a method proven to monetize customers efficiently, is more easily replicated in services businesses (e.g. cloud) than it is in traditional on premise software, where open source has become both an expectation and a means of combatting lock-in.

If one looks at all of the available evidence and decides to proceed with a traditional software licensing approach in spite of the observable challenges, it is certainly not impossible for them to a) generate revenue and b) be profitable. But the degree of difficulty attached to this model has gone up considerably, and looks to only be getting worse. And this isn't just an academic theory, it's something I hear almost daily in conversations with vendors.

RedMonk - http://redmonk.com/jobs - Remote or Portland, ME or London, UK

Analyst

## Who is RedMonk

We're the analyst firm that thinks developers are the most important constituency in technology. Our work shows up here on HN from time to time.

## What You Need to Have

- A rational, fact-based based approach. Opinions are fine. Data is better.

- The ability to synthesize disparate data from different sources, both quantitative and qualitative.

- Excellent communication skills, and ideally experience presenting.

- The ability to write clear, digestible and insightful analysis of complex technology – and not take months to do it.

- A reasonable online presence. You don’t need to be Taylor Swift, but if you don’t know what Twitter is there’s a problem.

- Deep and relevant technical expertise in technology infrastructure.

- A personality that both we and our clients enjoy working with. You can call this the no assholes rule.

- The ability to travel regularly to industry events and client sites. - A passion for developers.

## It’d Be Nice If You Had

- A background in statistics, economics or both.

- Exposure to/training with statistical programming languages (R or Python if you must).

- Experience as a developer, whether as a hobby or profession.

- A broad range of technology exposure (as opposed to being expert in a tiny niche).

- Familiarity with media creation and editing; audio, video or both.

- An affinity for craft beer.

To apply for the position, please submit a cover letter, project samples, resume and anything else you think we should consider to hiring@redmonk.com.

Portland, ME. Several colleges in the area, can rent an apartment in town for < $1K, an office with parking for less than half of that, good airport 15 minutes from downtown, < 2 hrs from Boston, tons of outdoor activities (hiking, sea kayaking, fishing, etc), burgeoning startup culture (see: http://startupportland.com), high end craft beer (Allagash, etc) and a great food scene if you're into that (e.g. http://www.bonappetit.com/columns/the-foodist/article/portla...).

The one negative people tend to bring up is the weather, but Portland tracks Boston temps pretty closely. It won't be mistaken for Miami or Southern California, but the foliage is fantastic and snow can be fun.

Personally, I enjoy having a repository of my location history that I can browse easily. Where was I on such and such a date? Easily looked up.

As for the privacy issues, they are real, but my carrier could easily replicate this data if required to anyway. So if it's going to be generated with or without my consent, I may as well have access to my own copy.

I'm in the market for a solution here, but really need one with calendar integration. If I have to go back and forth between the app and my calendar it doesn't save me that much time over email.

App looks great otherwise.

the numbers for both axes are their respective rankings, not actual tag counts. their positioning, therefore, isn't directly proportional to the actual tag volume, but how they rank relative to one another. if we had actual numbers on the github side rather than just the rankings, we'd account for this by introducing a logarithmic scale, but we're constrained by what the data we have access to.

(disclaimer: i'm the author) it's important to keep two things in mind when considering any ranking: first, and most obviously, no language ranking will be perfect for all readers, because the metrics for ranking languages will vary on an individual basis. second, the intent of the ranking. for our purposes at redmonk, this is an important consideration, because we neither intend to nor claim to produce rankings that are representative of language use broadly. if the rankings were representative of all use, languages such as COBOL would have a substantial presence on the list. we are rather interested in communities that we believe to be more predictive in terms of future use, of which github and stackoverflow are two obvious examples. the sustained strength of javascript on both properties has been one example of their ability to identify trending languages.

as for the criticisms regarding the usage of stackoverflow above, this is why we correlate the stackoverflow rankings with github. one represents discussion and research about a language, the other is manifestation of activity within a language. what's interesting is that the correlation between these properties has historically been strong and appears to be getting stronger over time.

again, no ranking is perfect - ours included - but we feel that measuring programming language interest and traction via these properties is at the very least an interesting datapoint.

[disclosure: i'm the author of the above] opinions differ, I know, on the performance (e.g. https://twitter.com/derekcollison/status/245530906067095553), but ultimately you're correct that Go represents a compromise. it won't offer the performance of the lower level languages, nor the flexibility of the dynamic alternatives, but the adoption we're seeing is generally people who are willing to live with those compromises in return for a mix of the aspects to low level and high level languages they like.

no! it's crucial to my daily usage. its loss is killing me.

i've had no issues with ad-hoc hotspots working off a Galaxy Nexus and a Xoom, FWIW.

GPS location is, agreed, not technically impressive. but successfully leveraging location history alongside of real time traffic data to intuit home and work addresses and the drive times between them with zero user input and an acceptably high level of accuracy seems somewhat impressive here.