We are hiring a Python developer to help us developing GrimoireLab, our stack for software development analytics. We are looking for a smart, high-energy person, with a passion for learning, contributing and collaborating in free, open source projects to work with us in Madrid (Spain) area.
We offer a regular job contract, with a salary range of 25K – 35K € / year.
Commuting at least three days a week is required
No Agencies Please
Effective communication and collaboration in English
Experience developing with Python (+2 years)
Free, open source software knowledge and background
Experience with collaborative tools, including Git and GitHub
Not everything in inner source is about community building [but a big portion!] and the infrastructure is basic to foster collaboration, transparency and community building.
This post is about aspects to have in mind when deploying the tooling needed to provide support to developers within the organization and across business units.
There is a more extended version of this infrastructure topic in the work-in-progress book about inner source: Managing Inner Source Projects that we, in Bitergia, are writing. Specifically in the infrastructure chapter. This is available under a CC-BY-SA 4.0 license and anyone is more than welcome to propose new sections, improve the current ones and collaborate in any way. Please feel free to redistribute!
We are all used to open source projects. Concepts such as community, code review process, continuous integration, geographically distributed contributions, community managers, and a whole myriad of terms and collaborative way of working are usual for all of us. And enterprises are learning from this open process. Those are changing the direction of their development models to a more open one within the organization. Initiatives such as the Inner Source Commons where companies such as PayPal or Bloomberg are publicly exposing their case, help others to deal with the usual problems they face.
In a recent post we’ve seen how to set up Inner Source in your company is a cultural change question. Companies need to increase inner transparency, confidence and collaboration for breaking the functional silos in order to create a proper environment to develop software between motivated peers and enable code/knowledge reuse.
Open Source development communities use several tools for enabling collaboration and transparency. Companies can take advantage of them for their inner software development projects. Let’s see some examples from our experience tracking collaborative software development and helping companies in their Inner Source projects analysis:
In past posts, we talked about Inner Source and the benefits for your organization. Some large organizations, such Paypal or Zalando started their own process to approach Inner Source; we can say without a doubt that each of them has taken their own path, because Inner Source is more related to a philosophy or enterprise culture than to a process or static methodology defining it.
During last LibreCon we have been sharing some insights about it during our
Inner Sourcing and Software Development Analytics talk, and next months we are going to collaborate with some companies in their inner source approach. So it seems the right momentum to start a set of posts about “Inner Source”, doesn’t it?