TranslateProject/sources/talk/20200903 Why your open source project needs more than just coders.md

6.8 KiB
Raw Blame History

Why your open source project needs more than just coders

Developers alone don't create open source projects that meet a variety of needs for a long shelf life; it's time to welcome more roles and talent. Teamwork starts with communication across silos

Why do open source projects fail?

Lack of funding is a major factor, of course, but it's far from the only reason that open source projects fail to achieve sustainability. Sometimes there's a lack of understanding of how to create a product for a broad market, or some fundamental misstep with intellectual property rights (IPR)—such as failing to properly license your code.

It's hard for any open source project to sustain if it doesn't get these types of basics right. Collaboration across boundaries and the ability to iterate and expand are hindered, and innovation is stifled. I see these fatal flaws especially in a lot of humanitarian projects—passion projects—and it is heartbreaking.

Building role diversity

Open source has tended to thrive in instances where it has been developers writing code for developers. Thats why so many underlying technologies developed via open source (Apache and Linux, for example) have succeeded.

However, when it comes to creating quality user experiences and products for people other than developers, open source's record is spottier. Why is that?

One of the big reasons is because the majority of open source communities dont encourage or even welcome people of diverse expertise. Sometimes, theres no acknowledgement of them. The coders get all of the love, and roles and contributions beyond coding are not even thought of.

Sustainable open source demands that communities embrace and reward a lot of different talents. There are the developers, most definitely, and they must be core for any open source project to be successful. But without contributions from marketing expertise, for example, you might not thoroughly understand what the users want. Without the input of product management, you run the risk of failing to develop a product for users other than other developers. Businesses normally invest in these and other roles because their varied contributions are critical to delivering successful results and creating products that are production ready with community support for long term sustainability.

One of the conflicts that I often find amongst open source development communities is an animosity towards product or project management. Its true that product management especially in corporate places has control issues—they may try to do things like dominate a market, or come in from a perspective of scarcity rather than abundance. It shows in behavior, and its antithetical to the spirit of open source.

But, to be fair, I think it is also true that we developers have never been taught how to work well with product management. We are told, "More people would use your product if you just did X," and we respond, "No, you can't tell me anything about my baby." We don't want to hear, "Yeah, but if you change the diaper, more people would like your baby," even if it's true.

Open source hasn't always embraced talent other than developers, and this is what must change in order to foster long term stability.

Birthing IEEE SA Open

Putting in place the tools and processes needed to encourage project sustainability is our current focus in architecting and designing IEEE SA Open. To that end, bringing in role diversity and building a platform and a tool that invites and rewards those diverse contributions is crucial in creating IEEE SA Open.

We are creating our community, marketing, and technology onboarding guides to ensure that incoming projects automatically get a level of support that they wouldn't normally get from a technology platform. We're looking at raising the maturity model into advanced processes and practices. For example, progressing to levels 4 (quantitatively managed) and 5 (optimizing) of Capability Maturity Model Integration (CMMI) requires measurement. Getting our processes right from the outset and assigning the right metrics to inform better, more consistent evaluations will support our sustainability.

This is one of the places where our linkage with IEEE is so important. One of the things that the standards world does especially well is process, and IEEE in particular has a history of making sure that its processes are fair and predicated on advancing technology for the benefit of humanity. With more than 419,000 members in over 160 countries, IEEE is the worlds largest technical professional organization dedicated to advancing technology for humanity. Its roots go back to 1884 when electricity and telecommunications began to become a major influence in society, and today IEEE has over 1,200 active standards and more than 650 standards under development.

IEEE SA Open can borrow on those best practices and lessons learned in sustainability that IEEE has acquired by experience. We aim to bridge the gap between global standards development and open source developer communities. It is definitely a balancing act, and we respect that!

Were reaching out to people all over the global open source and standards communities in a diverse set of roles to be engaged in creating IEEE SA Open. You can participate in that birthing project, and now is the time. If there are things that are super important to you and that youve seen neglected in open source, this is the time to engage, share your experiences and influence the creation of IEEE SA Open. You can help make sure we dont make those mistakes. We need your unique insights and input.

You don't need to be a master coder to contribute to open source. Jade Wang shares 8 ways you can...


via: https://opensource.com/article/20/9/open-source-role-diversity

作者:Silona 选题:lujun9972 译者:译者ID 校对:校对者ID

本文由 LCTT 原创编译,Linux中国 荣誉推出