Codegeist 2022 IMPORTANT UPDATE Coding & Judging

We have an important update about sharing access to your project code with the judges.

Please allow the judges to access by either:

  1. Making your code repository public OR
  2. Sharing your private GitHub repository with and OR
  3. [Changed] Sharing your private Bitbucket repository with and

NOTE The sharing emails are different for GitHub and Bitbucket. If you have already shared your Bitbucket repository with, please reshare with

Please let us know if you have any questions by posting on the Atlassian Developer Community with tag Codegeist2022

Good luck! #codegeist2022


Is this a new rule that we have to share the code with Atlassian? Considering the Atlassian developer terms of service (section 17) - that pretty much rules out anyone that might want to create their app as a commercial entry on the Atlassian Marketplace later.


This is a good point. What assurance do we have that Atlassian will not use the submitted material to produce competing features?

Also, is it mandatory to use github/bitbucket?


Hello! Michelle from Devpost here. :wave: It is not a new rule that participants need to share their code with Atlassian and Devpost. Sharing the code is just for the purpose of judging and testing your Submission. The new difference is that if you are using BitBucket, the Atlassian team has a different email for that. After the winner announcement you can remove that access.

1 Like

Good questions! Please note that all Submissions remain the intellectual property of the individuals or organizations that developed them. For more on how Intellectual Property Rights are handled within Codegeist please see the section in the rules here: Codegeist 2022: Forge the future of teamwork — build collaboration apps on Atlassian Cloud — $300,000 in prizes including a trip to Las Vegas. - Devpost

Github/Bitbucket are the easiest ways to give access, but the requirement is just to be sure that you grant the Judges and reviewers access to your Project code repository. The rules highlight to do this by either making it public or giving access on GitHub or Bitbucket in the above described way.

1 Like

For “judging and testing” the source code requirement is a bit vague reason. Rhetorical question, but why do you need the source code?!? If we have the app available in marketplace you can access it there, if we build bad app and it wont run - we lose, if the documentation does not describe it well enough - we lose. Last year all testing was done without access to code - currently that requirement stops us to participate cause the need is not really justified.


Sorry to hear it is a blocker. During project review we might use the repository to check that the work done is during the hackathon and if there is a technical judge on the panel they might like to dig in a little more to assess the implementation.

I have never seen this as a requirement before and there has been multiple codegeists so this is quite disappointed. And again I will note that your developer terms actually preclude us now from participating.


The source code does not show when the work was done. It can just provide some information about when the commit was done to this specific repository. I can easily create whole new repo and commit my life work in one second… Also about the technical implementation reviews… “The colour of the cat doesn’t matter as long as it catches the mice.”
So I strongly revise you to review your requirements cause right now this need is just not really justified and vague subjective aspects about the judgements make it even worse.

1 Like

Additionally, here is a commit graph from GitHub:

Just illustrates that commit dates can be changed. I remember analyzing the commit graph of my boss after a hackathon, and in other news I don’t work in that company anymore (Joking - I left for unrelated reasons but that boss was awesome and I shouldn’t have done that, I still wake up at night thinking of the right wording for an apology letter).

=> Not only analyzing git commit dates is not very reliable, but also, pre-commits happen frequently by the best hackers, and it’s good for competition. It’s not a race for the quickest to type code during codegeist; It’s a race for the best apps in the end. #LessonsLearnt (PS: I’m not in today’s Codegeist, so I’m not trying to weigh).

1 Like

@MichelleDesrochers Would like to chime in here as well to say we feel quite uneasy about submitting source code access for entering the Codegeist. Others already gave good reasons why this is problematic. Just to add one more:

I do not think Atlassian can give any guarantees that our source code remains within the Codegeist judging team and is being removed after the judging. Once we give Atlassian access, it is basically out of our hands. We do not even precisely know who within Atlassian will be able to access the code - it could be one person, or it could be 1000.

If this requirement remains, we will seriously reconsider entering Codegeist or we will have to look for ways to mitigate our risk/exposure.

1 Like

Hi folks!

Thank you for raising these concerns.

To avoid any ambiguity, our intent with requesting access to repositories is for verification and judging purposes only: Atlassian will not use the project material for any purpose other than selecting a winner for the contest and all submissions remain the intellectual property of their creators.

However we also care more about you all participating in Codegeist than we do about reviewing your code, and have decided to relax the requirement to some extent (details at the end of the post).

With that out of the way, let me share a bit more context about Codegeist, and how Atlassian treats your code.

Internally, we are very careful about how any access to third-party code that is not explicitly permissively licensed is handled, as we absolutely do not want to get into a sticky situation with respect to your or anyone else’s IP. We largely run Codegeist to incentivise developers to build awesome apps that will hopefully make it to Marketplace as wildly successful commercial offerings that delight our mutual customers — we do not want to steal your code!

As @MichelleDesrochers stated, the reasons we are interested in source code for Codegeist is partly to attempt some verification of the fact that code was created during the contest window, and partly to facilitate judging.

However as @Margus_SoftComply and @aragot have colourfully pointed out, Git history is inherently and trivially mutable, and this is not a foolproof way to verify when code was created. While this isn’t a perfect guardrail, I hope that you’re all acting in the spirit of the competition :slightly_smiling_face:

However primarily we request access to facilitate the judging process. Sometimes this is simply to test the app — last year we had to build a couple of apps from source to get them to run. However we may also review the code of submissions that are particularly impressive to understand how they have pulled off aspects of their functionality. Not to steal your implementation, but rather to revel in the glory of your innovation, and award points accordingly.

If I may draw your attention to the judging criteria (at the bottom of the DevPost page). While the preliminary and final judges have some discretion, the things we are all looking for are:

Quality of the Idea
Includes creativity and originality of the idea.

Implementation of the Idea
Includes how well the idea was executed by the developer.

Potential Impact
Includes the extent to which the solution can help the most Atlassian users.

While your idea and the user experience of your app tends to have a large impact on the judging process, being a hackathon we are also interested in how you built it. Forge is a constrained platform, in part due to its aim of platformising security and data privacy where possible. These constraints mean that some use-cases are harder to solve natively on Forge than they would be building on external infrastructure, and judges may credit that hard work where it impacts the judging criteria.

To illustrate, imagine we hypothetically had two similar submissions that both implement Confluence macros that use text-to-image algorithms to generate stock photos. The macros read the surrounding Confluence page content and generate some appropriate stock imagery using NLP and stable diffusion (or whatever the new ML hotness is these days). Both have similar user experiences, but one app works by passing the Confluence page content to an external service or ML API, and the other implements the same functionality natively on Forge. Despite being similar, the Forge native app would likely score higher than the other app, because implementing ML inferencing in the Forge FaaS environment is a creative use of the platform and would require some impressive technical execution due to its constraints.

That said, we do empathise with your concerns around IP. The Atlassian Codegeist team have discussed this at length and have decided that at the end of the day, the most important thing for us is fostering the next generation of Marketplace apps and ensuring our developer community enjoys the event.

As such we’ve decided to make sharing your project’s code optional this year, and will also factor this feedback into the design of our next Codegeist.

To keep things simple, please still submit a repository as per the instructions, but it’s up to you as to what that repository contains. You can choose to include all of your app’s code, or your code with sensitive portions redacted, or just a Manifest, or a describing your app’s general approach, or whatever you would like our judges to judge. The only hard requirement is that we do require either:

so our team can test your app and verify it meets the eligibility criteria. We will update the DevPost instructions accordingly.

I hope this allays your concerns, and if not feel free to follow up on this post with further feedback. We wish you the best of luck in the competition and are super excited to see your submissions!


Tim Pettersen

Head of Developer Experience

Note: This reply was updated October 21, 2022 to reflect the fact that access to a test instance is also acceptable to meet Codegeist judging requirements.


Hi @tpettersen - thank you for elaborating! However your response and the changes in submission requirements (as also announced by Devpost just now) do leave me feeling very unsettled. We are currently building an app that will work in production once Atlassian enables Forge app support for anonymous users - however, since that’s not currently the case, our app currently works best on a preconfigured instance, that we planned to provide unrestricted access to for testing purposes. Also we will be sharing the entire source code repository with the judges in full.

In the expectation that these previously defined entry requirements will be sufficient, and that we will have some more time to get the app production ready after the hackathon, we currently cannot provide a useful installation link for our app.

Can you please confirm that the aforementioned submissions of full source code repository and unrestricted access to a testing instance will still sufficiently meet the eligibility criteria?

Thank you!


@JonathanPusinelli great question and apologies for not anticipating this scenario in my initial response.

Let me double-check with the team, but I don’t imagine that would be a problem. Creatively working around existing platform limitations seems reasonable, and if that means needing to do some special configuration and provide access to a test instance for convenient judging I suspect that would also be fine (and appreciated by the judges!). I’d encourage documenting your approach in your so that our judges can understand your rationale and score your app fairly.

There is also a “Forge feedback” prize so clearly documenting any creative workarounds (or hacks) that you’ve put in place is helpful. The fact that you’re building an app that can’t be brought to market until a particular Forge roadmap item is delivered is valuable feedback in itself :slight_smile:

I’ll confirm with the Codegeist team and assuming there are no issues will update my response above and the DevPost posting to make it clear that providing access to a test instance is also acceptable.


@JonathanPusinelli confirmed, the Codegeist team are fine with access to a testing site in lieu of an installation URL. Providing you supply any required instructions on how to set up and test the app, together with the necessary access to the test site, the judging process should go smoothly.

I’ve updated my reply above, and Devpost should be updated soon.

Thanks for your feedback, and have a great weekend!


I would have created a test instance with anonymous access allowed, but this is only available for paid instances. Maybe you could think about changing this or give some sort of promo-code to Codegeist participants.

Another option is to share a free plan instance with 2-3 test users (maybe the same users as for the code)?

I think in some cases it is much easier to test, if some data or settings are already provided. A rich documentation costs some time, which is short for a hackathon done in the slack time :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.