This year marks 20 years after the term “Open Source” was first coined. Earlier this month John Edwards, a reporter at InformationWeek, asked Streamr project contributors a bunch of questions for a piece he was writing for the anniversary (which was actually in Feb when we published our first tranche of code?).
We don’t normally publish such answers in full but this time we thought the replies from Wei (Dev Relations) and Mikhael (DevOps) might be useful for the wider community. Enjoy!
Q. How can an employer encourage its developers to contribute to an open source project?
Seasoned developers are usually eager to contribute to open source projects, because they can earn public recognition and give back to the community. However, employers might not always have a clear policy on how employees should allocate hours between internal development and open source contributions. In some companies, you could even see a one way street system, where the management encourages developers to leverage open source tools to build their internal solutions, without sharing results back to the community as per licensing terms. The real question is how can we create an open source contribution culture across companies, similar to volunteering initiatives? One way might be for employers to allow open source projects into the employer’s tech stack, creating much more of a two way street in terms of learning.
Q. What are the potential benefits for the employer?
Potential benefits to employers when their members contribute to open source projects include better understanding of underlying codes, logic, architecture, increasing morale across employees and more recognition from the community and greater brand awareness. It also allows companies to save time and money by not necessarily having to build everything from the ground up because they can leverage the community’s pre-existing knowledge base.
And by actively contributing to projects, employers might have a say in the direction of open source projects and attract higher caliber developers who are looking for something more than just a traditional job. For example, senior Ethereum developers/researchers often demand from their employers that they work on open source projects for at least 20–30% of their working hours.
Q. What are the potential benefits for the employee?
The potential benefits for the employee are education and credibility. A seasoned developer can learn new tricks and obtain public recognition for their skills. Junior developers can learn a specific technology through getting stuck in and getting feedback from publicly recognised masters of a project. For others, it can be an opportunity to volunteer to contribute towards the public good.
Q. What is the biggest barrier preventing developers from contributing to an open source project?
The most significant barrier for developers contributing to open source projects is time. Entering an already running open source projects takes a substantial amount of time. One must understand the system, the philosophy and reasoning behind the project, coding styles, issue formats and in what way they can contribute.
Two other barriers are: worries about criticism to their code quality and a lack of clear guidelines from employers.
Q. In what direction is the open source movement heading?
It is becoming more apparent that in order for any technology/platform to become mainstream, it needs to have a strong developer community behind it. Microsoft used to be the representation of closed, proprietary software company, however even they have started to embrace the open source movement. Their acquisition of Github is the biggest sign of that shift.
With the blockchain and crypto ecosystem, we are seeing entire ecosystems revolving around the open source ethos as a viable business strategy. There is no doubt that in the future, open sourcing a project will be synonymous with credibility and transparency, similar to how companies nowadays employ auditors to certify their financial statements.
Q. Is there anything else you would like to add?
The biggest challenge for open source projects is not the lack of contributors but the lack of maintainers. Many developers pitch in with a contribution here and there, but it is the maintainers who do the more tedious work of writing specs, checking issues, reviewing code, etc. We need more maintainers.