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.
54 readers like this
54 readers like this

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 projectspassion projectsand it is heartbreaking.

Building role diversity

Open source has tended to thrive in instances where it has been developers writing code for developers. That’s 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 don’t encourage or even welcome people of diverse expertise. Sometimes, there’s 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. It’s 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 it’s 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 world’s 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!

We’re 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 you’ve 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 don’t make those mistakes. We need your unique insights and input.

What to read next
headshot of silona
Silona Bonewald is the Executive Director for IEEE SA Open, a comprehensive platform offering the open source community cost-effective options for developing and validating their projects.

3 Comments

Yes. This is a real problem with visible effects. Projects are often run by programmers who speak a different language to usability or graphics people. Communities sometimes communicate over IRC, unfamiliar to most non techies. On one well known project I was told I'd need to use the command line to contribute graphic designs. A usability fundamental, "listen to users", gets dismissed with "users are stupid". Or "If I can do this [hack], so can the users." There is a cultural difference and barriers to "outsiders" everywhere.

You need to have a welcoming environment, irrespective of the expertise of those who come your way. Sometimes you need to explain something to someone asking questions or making suggestions. Just by explaining, you help yourself out by making sure you can clearly articulate what your project is all about and how it works.
Sometimes people seem to come just to complain. It's worth the time to at least listen, and then point out the errors in their thinking that you see. There are times when they actually have an excellent point, just not formulated well, so that with some to and fro, you come to see the merit in their suggestions.

Thank you for sharing

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.