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 
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 README.md 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!
cheers,
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.
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.
