Hacker Grandma
Many years ago, I left a high paying job to be more involved in the open source community. The primary reason I did so was my conviction that open source software is an important way to empower anyone with access to the Internet and a computer with ability to freely use, learn from, modify and share software. For me, sharing my software using an open source license is a key part of ethical software development.
As a community, enabling world-wide learning and collaboration is not automatic, nor is it easy. It requires a community that not only values diverse involvement but also guards against even well intended actions that impede free and open participation.
It is important for those of us from rich countries and regions like the UK, United States, and Europe to understand wealth is not distributed equally around the world or even within our own countries. When software and resources used to distribute and produce software, are made available free of charge, even those who live in poorer nations like Pakistan, the Philippines and India are not restricted by finances from learning and earning a living.
We need to think globally in our open source communities.
It is also important that everyone have equal opportunity to participate and influence the direction of software. When we are truly enabling broad participation it will be obvious by the diversity of our attendees and speakers at conferences, guests on community podcasts, leaders in our community governance groups and developers on our community project teams.
Today, open source involvement is largely limited to white men from the US, Europe and Australia. That means there is an enormous opportunity to expand involvement and impact world wide.
Finally, a community that supports world-wide participation understands our heroes aren’t only our experts but maybe even more importantly, our heroes are those people who help enable broader participation, especially of new developers.
Those who offer resources and free-of-charge training encourage broader participation. Those who offer tools that enable developers to obtain paid work are valuable community leaders. Any and all resources that make visible code from a diverse set of developers is a resource that should be championed by a community valuing freely shared knowledge.
A healthy open source community understands open participation will result in some bad software. Quality and security issues create problems for users and a community must work together to increase the quality of distributed software.
A wise open source community understands that how this challenge is handled, matters.
Targeting beginner software resources in a negative way by personally attacking the resource provider, or continuously drawing attention to undefined quality problems restricts expansion of a diverse, international community.
When the inner circle of established developers within an open source community is primarily a group of white men from wealthy countries, extra caution is urged before responding publicly.
Terms like “a lack of professionalism”, “significant quality issues” and “security problems” are the software equivalent to yelling “Fire!” in a crowded theatre and ultimately undermine the involvement of those not in the inner circle.
At best, approaches of that nature are not constructive. But, the damage can be significant.
Any approach intended to prevent involvement, to stop someone from participating, to stop a resource from being shared should be called for an immediate stop by a community that values diversity.
The result of influential inner circle members vocally opposing gifts that are freely shared can be discriminatory, end up simply supporting the status quo, and very possibly restricts the involvement of others. Intention does not matter.
We need to be mindful of the fact that software quality is a shared responsibility of developers, the community and users.
The only responsibility a developer has in an open source community is to release software using an open source license. It is important to make that clear from the start and to support developers in that regard. We expect nothing other than a valid license.
The message to developers must be that sharing software freely gets you in the game and you are encouraged to play. We got your back.
Wait, what??? What if they release bad software? Shouldn’t we stop them? My answer to that is no, we should help them improve their software.
From the point a developer releases software, a community can step in and promote safe and quality practices, and do so with free of charge resources to ensure everyone has access.
My personal standard as a developer is to not release code until it is unit tested with a minimum of 95% code coverage, of high quality, and in conformance with industry standards. I use Scrutinizer, Travis to establish conformance to quality and industry standards. I document using phpDocumentor.
In the end, a community can embrace and support open source software and do so in a safe way.
But what if the developer rejects the ideas and pull requests and shares bad code, anyway? Then, should we stop them then? Again, my answer to that is no. We should help users understand their responsibilities.
Users can look at how the software they use is supported. They can check issue queues for closed versus opened, verify whether or not there regular commits, determine if the project guards against backward compatibility breaks.
For frameworks with larger collections of code, I expect to see more activity than a single software package that might not change.
At the end of the day, each user is personally responsible for selecting and using open source software. As users, we are solely responsible for evaluating the software we use for suitability, safety and correctness. Not knowing how to code does not transfer responsibility to others, it simply means users must find other means to ensure they have provided for themselves in this mannner.
A leader in a community understands these three layers of responsibilities. A leader is careful not to stop but to enable participation. We can be a leaderful community if we each demonstrate personal responsibility for software we use. As developers, we lead when we use an open source licenses for software we release and when we work to build in measurable, quantifiable quality in our software.
In a community, you will find leaders quietly posting pull requests and testing bug fixes. In doing, our leaders make it clear that quality is a shared responsibility that involves commitment and work.
Finally, our leaders lift up anyone and everyone who is sharing something, anything to help engage and involve a broader, more diverse, international community of developers.
A community with that leadership is an international learning community of which we can all be proud.
blog comments powered by Disqus