TylerJewell

Note - we primarily make use of Gemini CLI, which is very promising, but have made pretty extensive trials as Claude Code.

Anthropic hasn't changed their licensing, just enforcing what the licensing always required by closing a loophole.

Business models aside - what is interesting is whether the agent :: model relationship requires a proprietary context and language such that without that mutual interaction, will the coding accuracy and safety be somehow degraded? Or, will it be possible for agentic frameworks to plug and play with models that will generate similar outcomes.

So far, we tend to see the former is needed --- that there are improvements that can be had when the agentic framework and model language understanding are optimized to their unique properties. Not sure how long this distinction will matter, though.

For those worrying about concentration ... the market can get even more concentrated than it is now. In the 1880s, 80% of the market was related to railroads. That concentration always mean reverts, but it could take some time.

Akka focuses on enterprise agentic with a focus on creating certainty and solving scale problems. We have a customer, Swiggy, which is >3M inferences per second for a blended set of models, both ML and LLMs, with a p99 latency of roughly 70ms.

This level of throughput is achieved by including memory database within the agentic process and then the clustering system automatically shards and balances memory data across nodes with end user routing built in. Combined with non-blocking ML invocations with back pressure you get the balance for performance.

Well, Vert.x and Spring are maintained by RedHat and Broadcom. Both of those companies measure their profit and loss tied to their broader orchestration and platform sales (Kubernetes). They fund app dev frameworks only to the degree they can drive profitable adoption of their other commercial offerings. Broadcom, in particular, after the VMW acquisition has trimmed their staffing in areas that do not directly impact the Tanzu bottom line. Not all Vert.x and Spring customers need or desire that coupling, and so that poses an interesting dynamic that is different from us.

We are a pure play app dev platform and that gets to the heart of why the business model is different. I'd argue that we are very motivated to make sure that customers are successful with app dev as that is our bottom line where our rivals are financially incentives by infrastructure sales, not app dev outcomes.

I am the CEO of Akka, formerly Lightbend.

We did a long podcast and a couple blogs that offered transparency to the rationale on why we moved from Apache to BSL, which still downgrades to Apache after 36 months. See Emily Omier for the specifics.

It came down to survival. The company faced a bankruptcy event as customers were using the software without contributions and after exhausting alternatives needed to change the license model to create a more sustainable approach.

The consequence of this choice was that there was less adoption from OSS and ISVs who need a flexible licensing model for embedding and redistribution. It also encouraged the Pekko fork which is a branch that is 2.5 years old. And that branch helped older projects and OSS distributions to maintain their position without financial consequences.

It is not cheap to maintain Akka, and after 15 years we have turned a profit, albeit barely. We are growing, finally, and have a prosperous future and most of our spend goes into development. It did allow us to create Akka 3, which is a simpler model for devs within enterprises mixed with a consumption based model that should be significantly cheaper than the traditional libraries, and cheaper than the cost to adopt most any other framework. We can debate the merits of different business models but we couldn't have maintained the 50 CVE fixes and create a modern version of Akka if we hadn't taken this step.

We need a better strategy on how to appeal to the OSS community once more. To appeal to startups and academics, we have free commercial licenses and subscriptions, which nearly 200 accounts have signed up in the last 18 months.

This is a phenomenal mixture of abstraction, design, and state management to peel away infrastructure complexity.

Ha! I maintain a public database and people can navigate it by going to tylerjewell.substack.com. It links into a public google sheet.

The tracking methodology buckets companies by the primary product they advertise. Withcoherence is in a different category that has a broader platform definition.

There are companies like gitlab and Codegiant that also have remote dev envs as features of the broader product line.

The remote dev environment space is heating up. Quite a few variants and competitors now emerging in this generation of vendors. I started and sold Codenvy to Red Hat which implements Eclipse Che and Eclipse Theia as CodeReady Workspaces.

There are increasingly limited differentiation between various vendors. The biggest improvement areas needed now are simpler configuration, faster boot times for complex projects (pre-built code, cached artifacts, IDE plug-ins configured).

Cloud9 IDE Appvia Coder CodeSandbox CodeZero.io DevSpace Desktop Tilt Env0 Floxdev Gitpod Itopia Spaces LocalStack MetalBear Azure DevTest Labs Visual Studio Codespaces Nimbus Okteto SourcePro Porter Codeready Workspaces Repl.it Stackblitz Strong.network Subpoint Solutions Tangram.dev

This is the 7th article in a series we call developer-led landscape where we look at the underlying trends affecting the commercial companies in and around the developer ecosystem.

I find that it's important to periodically understand the big picture. I ask myself, are we doing better as a whole for society and can technology aid in that?

I get inspired by reviewing the following things: 1. Child mortality rate over time: https://ourworldindata.org/child-mortality?country=

2. DeepMind’s protein-folding breakthrough signals a promising decade for the science of proteomics. Most directly, being able to predict protein shapes will enable us to discover drugs more rapidly.

3. The cost to produce PV modules: https://ourworldindata.org/grapher/solar-pv-prices

4. Advancement of geothermal as a potential energy source. The next generation of the industry, however, is a bunch of scrappy startups manned by folks leaving the oil and gas industry who think with today’s technology they can crack 3.5¢/kWh without being confined to volcanic regions.

5. Space exploration. The Space Shuttle entered service in 1981 and launched successfully 134 times. The payload cost to low-Earth orbit (LEO) was $65,400/kg. Today’s Falcon 9 is at $2,600/kg.

6. The improvement in adult literacy rates over time. So much more to do here, but a literate population is one that is more likely to contribute to our global productivity and success. https://ourworldindata.org/grapher/literacy-rate-adults?tab=...

7. Quantum computing experiments and trails are doubling the number of qubits every couple of years right now. Quantum computing will cause a re-imagining of security and cryptography of digital assets if it becomes production grade. https://www.bbc.com/news/science-environment-59320073

I am sure there are many other examples. Even though I am an enterprise software guy working at Dell, the progress we made in the areas of technology that we get to work in have some contributing impact to all of these trends.

Clever line of thinking.

Is it fair to think of IDEs that include language-specific refactoring capabilities as a providing a developer abstraction over AST editing?

Here are my notes as I attempt to wonder about whether there are investment opportunities for an infrastructure investor.

What is a dApp? https://twitter.com/TylerJewell/status/1474468145704280064?s...

What are the investment opptys for an infra investor? https://twitter.com/TylerJewell/status/1474468607295832069?s...

What are various people saying about Web3? https://twitter.com/TylerJewell/status/1474468866101157889?s...

I write extensively about developer businesses and markets: https://tylerjewell.substack.com/p/developer-led-landscape-2...

I love solutions that are working in this area. Reminds me a bit of Codestream.

Why make the pull request such a formality? The process of writing the code, developers can have active discussions with other key members of the team from within their IDE. Those conversations are then captured as essential context to facilitate the PR review itself.

So many ways and innovative companies like Axolo which are finding ways to remove barriers to better information sharing and context.

A number of interesting points that are thought provoking, but also a bit of flame bait about cloud IDEs "dying off". As founder of Codenvy, happy to say that Eclipse Che is an active and growing open source community and after our happy acquisition by Red Hat they sell it as OpenShift CodeReady Workspaces.

Cloud IDEs provide value for specific portions of the market: 1. Training 2. Remote contractors in secure environments 3. Support 4. Classrooms 5. Vendors who want embedded dev envs in other products 6. Open source clones / snippet evaluations

Codenvy was strong in the embedded dev envs for other products. When you look at the various vendors that have emerged like Coder, Repl.IT, among others, they have a tendency to specialize in one of these areas.

That is quite different from the first generation cloud IDEs which tried to compete with classic desktop IDEs.

I got my pilot's license and instrument rating along with endorsements for mountain flying and high performance airplanes. I've now started studying for my commercial pilot's license and may pick up a multi-engine license, too. Took about 2 years to accomplish all of these tasks.

Studying for the license felt like I was back in university. So I treated it as a goal, studying ground materials consistently every day while blocking out 2 lessons every week. It was effectively a job on top of the work I was already doing.

Most shocking was how much longer it took me to absorb the materials vs. studying equivalently complicated topics 25 years ago. Not to understand what they were, but to be able to have instant recall with precision.

Over the past decade, I have sought to identify every for-profit developer product.

The landscape contains 800 companies across 22 segments that publish 1000 products which generate $40B in revenues.

Today, I am publishing some of the data and analysis.

It includes products from amazing companies like JFrog, Atlassian, HashiCorp, CloudBees, Red Hat, Snyk, Microsoft, JetBrains, and VMware.

I am hopeful that we can get the community to engage by identifying missing companies, help refine segment definitions, and to bring better awareness on the the influence and reach of developers.

I undertook this effort for a few reasons: 1. Developer businesses are still misunderstood by investors and business professionals 2. To bring clarity on the size and growth of different sub-segments of developers 3. To identify long-lived trends in developer businesses and products 4. To bring awareness to my efforts as a technologist and investor, helping to identify interesting companies I may get to connect or collaborate with.

A sample of what's included: ️Developer runtimes generate 2.5x more than pre-prod ️Early segment leaders usually become dominant ️1 trillion programmable endpoints drives need for lifecycle automation and operations to "Shift Left" ️$5M ARR is the threshold between startup and going concern ️It takes a mega vendor to straddle pre-production and production ️Substantial application server businesses emerge (category creation) around programming paradigms ️Private companies have raised a staggering $50B in venture capital ... though deliver questionable capital efficiency ️Software supply chain industrialization will propel the industry towards autonomous software development

Wso2 has a fully ASLv2 licensed API management solution which also includes a high performance gateway. It has monetization items included. Deployed to 1000s of accounts and running some environments with billions of transactions a day. Excited to take a look at this new entrant.

Keeping the history of the evolution and the rationale for each iteration was great. It's really good insight into the evolution of the thinking for a passionate community team that is doing its best to communicate why their efforts should be considered by others.

I'm CEO of WSO2 and we are working on a programming language for writing microservices called 'Ballerina', and we host it's community at http://ballerina.io. Prior to the first public launch, I pulled 9 of our core community members into an offsite where we developed and implemented the web site.

It was a challenging exercise and so can relate to Rust's community efforts to the redesign. I wanted to offer some perspectives of what Rust's challenges must be.

1. It is really hard to capture the value proposition for a programming language. While working through Ballerina, there is a hard balance between a) describing the language design, b) explaining why language elements are valuable, c) describe the key types of programming workloads that most benefit from your language philosophy, d) direct those interested to learn more to the right information, efficiently.

2. As such, whomever is leading the Rust site evolution over the years shows a real touch and depth for messaging. It takes a lot of insight and careful observation to your community over an extended period of time to tease out which elements are fundamentally what is driving your audience. Having said this, I have a tendency to feel that the messaging in the latest version might be creating a messaging abstraction trying to appeal to a wider developer base vs. the messaging in the current site which is more strongly appealing to existing system developers. Is this a conscious choice of the Rust team?

3. The rust team has figured out, through years of promotion, that the first (and last) question language teams get is always about "who's using the language? how big is the community?". The hardest part about birthing a language is the chicken and egg problem - someone needs to be the first big production app. Dogfooding is really the only way. Rust takes this head on.

I am not a big design person, so don't have an opinion about whether the minimalistic design is better than the new flowing design. A lot of the design influences for ballerina.io came from Go and Rust lang's web site - we are fans! So, I guess you could say that we prefer the minimalism concept.

The Ballerina programming language (ballerina.io) has a syntax designed in such a way that any syntactically correct program can have its sequence diagram generated automatically. It's a type of self-documenting programming language. It only documents for the scope of the service that is being programmed, but eventually if many components and services are programmed with Ballerina, system wide architecture diagrams can also be constructed.

@cyphar - I would love to chat with you about SUSE's policies and encouragement to enable working exclusively on upstream-first. We are working to bake that concept into our policies at WSO2 (I'm its CEO). While we practice that in motion, we are codifying it within policies. If you could email me tyler@wso2.com, would appreciate a chat about it with your or management there.

Thanks - forwarded onto marketing.

I am CEO of WSO2, an open source software company, with 500 enterprise customers and competitive to IBM, MULE, and RHT.

I have packaged up my observations on the acquisition and the impact to open source in this blog post.

https://medium.com/@tylerjewell/ibm-acquires-red-hat-what-th...

WSO2 - an open source integration software company - is exclusively OSS. We will do $50M in sales this year with 80% of that subscriptions for on-premises open source software. We are the 6th largest OSS company by revenues. We'll probably jump up to 5th next year because of the RedHat acquisition of IBM.

42. Ground and tower comms related to pursuing private pilots license.

I'd argue that our company, WSO2, which is now the 7th largest OSS company is doing well. We will push $50M in sales this year, EBIT positive, cash flow positive. Growing 60% yoy. All of our software is Apache licensed.

Disclaimer - I am CEO of WSO2, a pure open source company. We philosophically oppose open core business models.

The author is speaking to the differences between the open core and open source business models. I've been writing increasingly about the differences between these models on my Medium blog about WSO2's growth story, our thoughts on the MULE acquisition by CRM (another open core vendor), and our open source business model.

WSO2 is a pure open source business model and we believe that it's more honest, efficient, and scalable. Also, if executed in the right manner, there is no risk from IP exploitation. We have been able to demonstrate that as we are growing on an ARR basis faster than MULE with an equal customer net dollar retention with negative churn, while getting to cash flow positive operations.

Our biggest rationale on why this is the case is that our internal teams do not compromise productivity by perpetually wrestling with where the “for free/for pay” line must be drawn. It is expensive for an enterprise vendor to determine the best model of where for-fee options reside. Not only does the vendor have to develop a strategy, but they must communicate this to all their employees and then justify it to the open market. This is evidenced in this thread and in the many HN threads for Gitlab - their management team has to invest time and energy into explaining the philosophy that was used to establish the line. It's rarely intuitive, so some non-zero effort goes into that education internally and externally.

These costs are passed along to customers and require significantly higher forms of capital from investors. This line does not stay static, either. The nature of open source is that is erodes and impedes upon the areas where a vendor is selling their proprietary extensions. This means the “for free/for pay” line must be periodically rethought. This is a continual process, and this is time where inefficiencies are introduced.

In the pure open source model, we just tell our developers to design and build. And we can focus on a single pricing solution of value in and around that overall platform. It saves us a lot of emotional capital, too, because people get very committed on where they think the free / for pay line must be drawn.

Finally, it lets us be more up front with customers. They know that our sales reps have nothing to gain by suggesting one tech stack over another. Customers can use the entire stack before they talk to us and so if they are really engaged, then we are engaged for a value added subscription for all of the right reasons, and we don't have to lengthen the sales cycle while they try to decide which route they want to take - open source or proprietary.

[1] https://blog.usejournal.com/wso2s-growth-story-and-why-open-...

[2] https://blog.usejournal.com/salesforces-acquisition-of-mules...

[3] https://blog.usejournal.com/wso2s-open-source-business-model...

I doubt you are trouble, it's a natural question.

On the surface every networked call feels like a method call, so absolutely, within any other language it could be done with a nicely prepared API wrapper for a similar type of connector. And, ultimately, that is what happens within a lot of ESB products that standardize how a connector should be deployed, versioned, and consumed by client applications within that environment.

Beyond that, though, the approach to the language design and the underlying implementation of connectors offers simplicity benefits that should make consuming new connectors easier and more reliable. A few things: 1. All network-bound calls are required to use arrow `->` notations instead of dot `.` to make some important distinctions. One is that sequence diagrams make this distinction and we can auto-generate sequence diagrams from any code file as the code structure is designed to reflect how integrators model their services.

2. Treating an endpoint as a native keyword and how that endpoint object is initialized within the language makes it opinionated, which ultimately makes configuration of some complex connectors simpler than what would be seen in API wrappers. If you take a look at the circuit breaker example, the circuit breaker is added as a configuration parameter to an outgoing HTTP connection. Of course, other languages can be opinionated about this as well, but they almost always delegate this to an add-on framework, and there are always some minor quirks to how frameworks work with their language of choice. So we get to bypass that and ultimately the syntax gets minimized to the point where it's easier to embrace and learn.

3. The underlying concurrency model in the language's runtime is based upon workers for parallelization, which are how sequence diagrams are modeled. Languages like Java map threads to classes. Node maps threads to the event processor, and so forth. When an HTTP -> call is made, we can do some nice internal optimizations such that while the code that you write will see that network call as a blocking call, behind the scenes, the runtime treats the outbound request as one worker and receiving the response as a second worker. Each worker is mapped to a different thread and you get some nice throughput mechanics because the system's scheduler releases a thread when the request is made. Because we know that any connector's invocation is going over a network with this syntax, there are interesting thread scheduling algorithms we can implement. We are seeing about 5x the TPS with a simple routing service built in Ballerina vs. the same type of service that we would implement in an ESB like Camel or Apache.

There are other thing that the designers will probably comment on, too.

Yeah, the way it works in Ballerina is that an endpoint is a keyword that can create an object that represented a networked location. This could be one of three things - either the caller that invoked your service, the service you author which is listening as an endpoint, or a service you want to invoke.

For the services that you want to invoke, you can create endpoint objects of different types. The objects during initialization use connectors to establish the communication. It's like doing a constructor call in an OOP. You can import different packages the way you would with any language and shared packages are available on central.

Once you have one of those endpoint objects, you can do type safe invocations against it. So you might create a Twitter connection creating a "tweeter" object. That connector then has functions which can be invoked, "tweeter -> tweet (params);". This returns a data structure that is strongly typed and mapped to the payload expected in return from the service.

It's also pretty simple to write your own packages which have your own connectors. The push / pull dynamics of packages with central are similar to Elk or DockerHub, but applied to code modules.