Master branch is not receiving much commits anymore?


We are wondering is development pace is somehow changed or are we looking at then wrong version: (master)

The version there used to update very often, but since September commit pace has decreased a lot.

Is there any plans on the roadmap that we might have missed that explains this? :slight_smile:

Welcome to the Cesium Community!

Thank you for following our updates and commits. We appreciate the feedback.

CesiumJS work has been mostly maintenance-related recently while we prepare for some exciting launches in other parts of the Cesium platform. That work will be valuable to the entire platform, so stay tuned. Meanwhile, we just released a CesiumJS update which you can check out here: New CesiumJS release

It would be important to know about the roadmap that cancels the development of the cesium.js lib. Right now it looks like stalled project and we need to consider changing to other platform.

Hello. I’m sorry you got that impression - definitely not stalled! CesiumJS is at the heart of our platform. Hopefully some of what we have coming up will be helpful to your work. Are you able to tell us about what you’re doing?


Out of curiosity, what other platform would switch to?

As an alternative OpenLayers is very strong for many of our use cases. We are a bit puzzled how the current commercialization of Cesium will affect the open source project.

Why would you use Cesium if OpenLayers meets your goals? Adding 3x the amount of code for no net increase in functionality?

That’s like taking an X-37 for a grocery run.

Too funny!

1 Like

I do understand your concern. We’re using an open-core approach to build the Cesium platform. This means CesiumJS and other open-source projects are the heart of the platform, and value-added commercial products and services generate revenue.

CesiumJS is open source and always will be - we won’t change the licensing and are committed to its development. Occasionally we have to dedicate the team to other projects (including other open source work), and in the last month that has meant less love to CesiumJS. That will change soon.

We’d love to hear more about your requirements and why you’ve stuck with CesiumJS as the X-37 so far. :slight_smile:


The concept of “open source” comes in mainly two flavours; “open” as in, you can download it and fiddle with it yourself but you’re not in charge of how the project evolves, and “open” as in everyone can integrate any changes back into the main repository. The ideal sits somewhere in the middle, which is where I think CesiumJS currently sits. The history of open source is littered with branches and fractions and politics, and it’s a fragile balance between all the people invested in the project. I think is doing a great job of having an open community around the platform, and using Git / GitHub for developer integration.

But if I go back to the OPs concern; how do you measure the health of an open source project? There’s more than commits to the main branch to consider here; there’s uptake, smaller bug fixes, larger feature adds, version flows, community chatter, support activity (open and semi-open), issue tracker chatter and engagements, code quality and style, the evolution of said code quality and style over time, the profile and visibility of the core team of people involved, etc. Commits to the repo is only one of those factors, and in my opinion not even one of the most important ones. For me it’s more about the core people’s willingness to interact with the community at large, in forums like this, and in git / issue trackers, talking about bugs openly, their engagement in issues and solutions, and how they communicate about the future.

If an open source project becomes successful, there’s a few more things to consider, mainly for the parties that have commercial interests in it. Here it gets tricky. We’d all love to make this the best and free and most open project in the world, but development is a costly affair. Smart people making smart and complex software for free is not a sustainable model, and for all who’s involved in Cesium there are tons of other things we do besides working on the shared core. There’s apps (that use the core), and frameworks, and admin, and testing, and support and all that other stuff, which also costs money. The key Cesium players must all consider how to balance the cost of the shared platform we all enjoy the benefits from.

In short; some weeks are slow on the core, other weeks it’s too much. Sometimes we focus on the community, then on testing. Some bugs are fixed, sometimes a pull request is granted, other times not. The branch activity is not a measure of the health of the project. We, the people in this community, is.

And with that, come on in! This is a healthy community where I’ve never seen a single negative thread, which, as far as open source projects of this scale usually go, is quite unique and refreshing.


Alex (not a guy)


Cheers @Alexander_Johannesen, what a great overview of the relative complexities of maintaining a highly technical open-source library.

I hope that Cesium remains profitable and sustainable due to the amount of national security systems that rely solely on it. When I worked for AGI my biggest complaint was that Cesium can be used for free on multi-billion dollar contracts for the government without any funds going to Cesium directly.

The biggest issue is that those that control funding for government systems have little to no technical knowledge.

I have literally pulled senior leaders out of classified briefing spaces over to the local Starbucks to view the Cesium homepage because they didn’t believe me that (insert big defense contractor here) was not the author of the base code library.


Thank you! Highly appreciated answers!

1 Like


It’s sometimes hard to push gratitude back into an open source project, especially in a monetary way; who gets the money, for what, and how? Even if you, as a third-party, develop some software or fix a bug, how is that gift taken back into the software? Sometimes it fits, sometimes it’s obvious, but this project is big and complex.

I recently had a problem that can share some further light; I had a customer who’s done their own tiling, and in viewing those tiles crashed CesiumJS after some time. But those tiles can’t just be openly shared, coming from a customer with rather sensitive data. I made a fix in CesiumJS core (a simple added test, so nothing crazy), and created a pull request. However, how can Cesium accept that fix if they can’t test that tileset? Chickens, eggs, etc.

There are other cases where I’ve created a cool feature, maybe a workflow of sorts, or a cool way to colorise something, but as much as I’d like to “give back to the community”, it will most likely just end up in an obscure git repo that no one uses. “Giving back” or accepting thanks, money and code is hard. And, unfortunately, costly, both for the giver and the getter.

Edit: as to your point from the owner of the original project, I can understand how that is hard. It kinda depends on what value you get back from having a community (in terms of adoption, bug fixes, apps, awarenes, etc.). If got nothing from it, I’m sure the first “open” model would suit better, so they must be getting something from it. Often, adoption is the key to your own success, even if it means others will use the same code as a competitor. Some times that means instead of having all the money from your 10 projects if your code was closed, you get the money from 30 of the1000 projects we all are doing. It’s juggling. :slight_smile:




For government contracts, the onus is not on third-party developers or contractors; everyone is fighting for their own project / funding, and it is nearly impossible to “give back” to open-source with either funding or code on government contracts. Every one I have performed on is structured specifically to disallow it.

No one else is doing what is doing, not even close, and no one else has the expertise to fork it and maintain it. If can be profitable with their current model, that is amazing. Otherwise I would encourage them to explore more restrictive licensing terms, at least as it pertains to government use.

Per your “chicken / egg” statement, you are making the case for developing and strictly enforcing data standards. I am actually fighting a standards battle right now, so that tools like this can be used isomorphically on all networks.


Hehe, I was there in the early days of CSS standaridisation, Topic Maps standardisation, and RSS 0.74 vs. ATOM 1.0. I feel and understand your pain.

Government contracts are a bit of a special case, for sure, and it would be great if a license for governments could stipulate a reasonable fee back to open source projects (given it’s public money). Unfortunately, the onus is on whoever picks up the tab at the other end, and if it’s free, then why? Having said that, though, I’ve been part of government projects that supports open source in other ways, either through people’s time, and / or hosting or hardware cost, so it is doable. It mostly comes down to the people in the middle negotiating either way.



1 Like

There are other revenue streams out there for them, I think they’re doing a good job keeping multiple irons in the fire. I would love to see some of the government customers using Cesium-derived tools in the defense/intel space contract with Cesium to provide terrain and/or photogrammetry data services. The great part is that if they do stand up service endpoints on tactical/operational networks, I can plug my tools into it with a single line in the config file.

1 Like