The new Atlaskit public “mirror” (Bitbucket) does not mirror the source code used to produce the publicly distributed modules (on npmjs.com). The “mirror” does not appear to have been updated since it first appeared 3 weeks ago, and this source code diverges further each day with the “built” production modules that Atlassian continues to update daily via npm. This creates various difficulties for our team with builds, identifying and fixing bugs, etc
Additionally, source code for many Atlaskit modules is not available on the “mirror”. (Only the “core” section of Atlaskit is included, which for our product, represents only about 40% of our Atlaskit usage. ) This Apache-2.0 license source code is no longer available in any form. I assume that these modules are those referenced by the README.md file in saying that parts of Atlaskit are moving from open to “closed” source.
So, I have two questions:
Is this “mirror” the last update that developers can expect of Atlaskit source? Or can developers expect that the publicly available source for Atlaskit will be updated frequently to reflect the npm modules and the Atlassian application binaries that we maintain for our customers?
When will Atlassian be announcing the specifics ot its move from the Apache-2.0 license? Specifically, exactly which modules are no longer open source?
We are working on making the mirror updated periodically as soon as possible. We aim to have it automatically updated on a weekly basis.
We don’t have plans to make changes to the licenses of components currently under Apache 2.0. We’ll move those license files across to the mirror as well.
Thanks for bearing with it while we are working these out.
Hi @jcheung,
do you have a timeline on when this is supposed to happen? It’s kind of hard to develop things when you guys start pulling the rug out from under us. I mean… that mirror repo is over 3 weeks old, and setting up a cronjob to periodically update it can’t be that hard.
Also, what about the missing components like media, editor, etc. When will those be available in the mirror?
@jcheung
+1 for the questions from @ademoss. Can you please make it a priority to setup the automated periodic update? Because you basically have an entire ecosystem of vendors loosing time on finding how to work with AtlasKit that they could have also spent on delivering value to Atlassian (& vendor) customers. Even if this proves to be a multi-day task, it’s well worth the investment!
Is there a way in which we can agree that AtlasKit is of as much value for Atlassian as it is for the EcoSystem? I mean, I assume that Atlassian teams are not suffering in the same amount as vendors (in terms of lack of access). I don’t fully understand why the ecosystem, the main consumer and a strong revenue driver, is not considered a stakeholder of AtlasKit to the same extend as the internal teams?
I understand that there is an distinction between internal Atlassian and the general public (NPM), but given the nature of the EcoSystem I think we should all agree that vendors are to be considered as either a separate (and more inclusive) group or, if it’s easier, as internal Atlassians (given that we’ve all signed an NDA, something which the general public has not).
An alternative solution (maybe even a better one) would be if sources were packaged inside npm packages.
It would also be helpful in terms of getting the sources for specific version of package.
Very helpful, @jcheung. One point I hope you might clarify:
When the general change was first announced in early January, the README.md advised explicitly that some of the existing components, would become closed source – in other words, that licensing for some components would change, and that these would no longer be available.
Your answer, 2., above, suggests otherwise. Has Atlassian changed its position here, such that all of the previous components will continue to be publicly available with the same, Apache license?
@ngault Just double checked the README. It’s consistent with what I’m saying here if you see the 2nd question in the FAQ. Bitbucket Hope this clarifies.
We turned on the sync to the mirror over the weekend so you should be able to find the latest source for Design System / core components here This will run weekly from now on.
I will get back to you all later this week on getting the other components onto the sync and about publishing source to npm.
All the docs for Atlaskit components are still available at http://atlaskit.atlassian.com/ and
will continue to remain up to date. Although, some components may eventually be removed from there
Technically, the responses to Qu 3 and Qu 5 can be true at once, and that is exactly what concerns many of us. In other words, modules may, per Qu 3, continue to be licensed under Apache v2 but, per Qu 5, Atlassian will not make them available publicly. Nothing about the Apache 2.0 license requires that the licensor make future updates available.
Thanks for the latest efforts to get this code pushed. I appreciate it.
After the sync, when trying to git pull from the latest design-system-mirror, I am getting a fatal: refusing to merge unrelated histories error from Git. It looks like the sync process is creating an entirely new commit without history or ancestors, which makes it very difficult to use this repo to track any local modifications.
Is there any chance the sync process could be updated to retain history so that we can do a normal git pull? I understand that the sync process is using a snapshot approach rather than including Atlassian’s own commit history, but even taking a snapshot of the tree and using git add -A . to apply it to the design-system-mirror repo would be helpful.
I will get back to you all later this week on getting the other components onto the sync and about publishing source to npm.
Can we get an update on this? What’s the hold up? If this is going to take a while, that’s fine, then at least let us know a timeline so we can structure our development accordingly.
Atlassian has been pushing us vendors to move to cloud, move to cloud, move to cloud. This is getting increasingly difficult with the lack of communication and the lack of access to critical resources like this.
For regulatory reasons, our corporate customer, which has >2k Jira seats, just asked us to replace all the Atlaskit modules for which the source is not available. Following established process, the company waited 80 days since the source disappeared on Jan 2 to come to this decision. Our team has now got 10 days to replace these modules.
Since Atlassian isn’t complying with the legal terms of the existing Atlaskit license, I propose that it would be to everybody’s benefit for Atlassian to give us all clarity now by formally announcing either:
a new license (which Atlassian has every right to do) for which source of future development will not be available, or
that the existing licensing terms remain in place AND will be followed.
These are the terms of the license that Atlassian has publicly and formally committed to (see Open Source Initiative), but is not complying with in holding back Atlaskit source for the past 90 days:
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Thanks and sorry for the delay as we adjust to new ways of working during this pandemic. We will update the weekly synced mirror repository to include other components by April 15. We will also try to fix the git pull issue @scott.dudley mentioned by then. This should alleviate the concerns raised here.
Thanks @jcheung for the update. I appreciate the steps forward you’ve proposed.
While working with the new repo format, I also wanted to mention that the absence of tags, combined with the relative infrequency of mirror updates, poses another significant problem.
For example, suppose that we want to be sure to have access to the source for components that are used in our products. While we might otherwise select the most recent version published on NPM, we are now constrained to using only the specific component versions that are visible in the weekly source snapshots. The fallout of this is:
Some component versions may never have sources available (if they are updated more than once between snapshots).
To be assured of having sources available, we would thus need to pin to specific component versions in package.json (ie. no more “^x.y.z” to accept minor version updates) because we don’t want to accidentally ship one of the packages that doesn’t include sources.
Even to figure out which version of the component actually has sources available, it looks like we need to pull the mirror sources and dig through the directory structure to find the individual package.json for the component, which is inconvenient at best.
All of these make it substantially harder to use Atlaskit in production. This could be fixed if sources were guaranteed for every published component version, and if these sources were easier to find.
For example, could the mirror be updated every time you push a set of new packages to NPM? And could the component-level version tags from your internal repo also be propagated to the mirror, so that we can track which versions are current and also make it easier to find historical versions?
In discussion on this thread 2 months ago, there was concern that only part of Atlaskit was now being made available in source form. When you were asked specifically whether the source for all of Atlaskit published under the Apache 2 would be made public, you stated that it would be shortly.
As of today, more than 5 months since the source was originally removed, a large portion of Atlaskit is still not available in source form, even as the built modules continue to ship with the Apache 2.0 license (which is not in compliance with the terms of that license). For those of us shipping source for customers in regulated industries, this is a serious problem.
Can you please give us an update on the availability of this source code and Atlassian’s interpretation of the Apache 2 license.