- The intention is not to propose Open/Inner Source just for the sake of publishing the code (this is just a mere side effect).
- What is more important is the mindset transformation. The transparency, developer empowerment, better collaboration, knowledge exchange to name a few are way more important than just pushing the code to GitHub.
- Are we going to force every Developer in Amadeus to be involved in Open Source? Definitely not. Open Source cannot be centrally orchestrated. It has to be organic in nature if we treat it seriously.
- The Open, as well as the Inner Source practices bring the ability to break the silos. Suddenly people are empowered to study their ecosystem, to understand the inner-workings and to be involved in shaping it. They are no longer passive. They are becoming the change agent. - This approach helps in driving innovation, building togetherness and moving from treating the work solely as a means of earning their life - a proverbial job - into something that they feel proud of, their passion.
- In the scope of the Manifesto, we don't differentiate between these two approaches.
- We believe that in regard to the intent, they have a lot in common; therefore, we will promote both with the same strength and determination.
- We acknowledge that Open Source may not be an option in some contexts. Practicing Open Source principles, minus publishing the code beyond the organization, is the second-best approach, and that is Inner Source in our high-level interpretation.
- We should be driven by pragmatism here. In the end we are not a charity organisation and what we do should positively impact the business side. Nobody will contest that fact.
- We start with the acknowledgement that we are not suspended in a vacuum. We are largely dependent on Open Source components and the sooner we start incorporating the efforts to improve them and contributing back into our regular schedules, the better.
- Appropriate time in this context means we allow our engineers to work on the Open Source libraries, frameworks the same way as they work on the internal solutions. There should not be much of a distinction here. As long is it's driven by the business needs it is justified.
- We have numerous examples of these practices already well implemented in Amadeus: ng-bootstrap, Perses, Otter, AgnosUI, Argoproj, Podman, Kind, some parts of RedHat ecosystem and many others.
- We acknowledge that the activities around Open Source are likely to improve the brand, support the hiring process and talent retention. Having a friendly and collaborative working environment definitely helps.
- We may not be the leaders of applying the Open Source to our daily work. Nevertheless, this is not a foreign subject to us either. We need make it official. Naming the exact amount of time here is pointless. We need to be rationale driven.
- What we're trying to achieve, will eventually impact the morale of our engineers in a positive manner. Ideally it should be organic. Not forced and not applied to a wrong context.
- The engineers draw a lot of satisfaction from working in the environment where they can see a clear impact of their actions - beyond their organisation. This opportunity alone means a lot.
- We also need to address the transparency(subject to legal constraints) and working with communities/projects. The internal ones we are trying to animate are already great achievements, but we can do better. We can work on solutions benefiting literally everyone, not just our company. Giving back is just fair and contributing to upstream always pays dividends in the long run.