Going from consumer of open-source to participants in active development

[MikeKSmith-Pfizer]

Often it seems daunting to a new developer to actively contribute to an open-source project, particularly one as big as the pharmaverse. "What can I do, I'm not really an expert coder..." This leads to the vast majority of people being consumers of R packages rather than actively engaging in development.

But participating in development can involve testing, creating vignettes, improving documentation, filing issues & bugs, suggesting new features. It would be good to highlight the different levels of engagement in development of open-source packages, and emphasise that it's not just coding functions. (BTW - I suspect that a large number of participants at posit::conf are very aware of different avenues for participation, so we may want to think about discussing this more widely).

What is stopping folks from actively engaging with pharmaverse development?

[danielschiff32]

There are a multitude of areas that can cause potential participants from being involved in contribution models for pharma related R packages. Lack of time to allocate to the cause, No knowledge about the groups, no knowledge of how to get involved, corporations that are not currently involved because of lack of interest or have created internal or propriety packages.

I feel having a discussion or split roundtables at R/Pharma virtual would be beneficial because there will be a pool of R users that are pharma specific to get involved. Try to get buy-in from biometrics heads through the industry to have people contribute, find ways to make the functions standard/automated towards all sorts of CDISC data, where we can use the metadata provided for different therapeutic areas or corporate standards that need to be met,

[Coutuan3s]

I'll add a few more, worries about IP, organizational constraints for participating (review and approval), worries about licenses. It's also difficult to code for everyone... and that must be part of your design. Removing company specific components (say for User access management) or specific metadata.

[kamilsi]

@Coutuan3s you've articulated the barriers to contributing very well. I think many of us in the field can relate to the challenges you've outlined. While these are valid concerns, I also believe that overcoming them comes with its own set of rewards. These can include professional growth and the development of more resilient code. It's almost like a rite of passage that can make us better developers and collaborators over time.

Moreover, I think this is a mindset that could be beneficial if promoted among managerial staff as well. As someone who straddles both the developer and management roles, I've found that integrating open-source contributions into our team's skill matrix has been incredibly valuable. To me, open-sourcing isn't just a development practice; it's the pinnacle of professional development, serving to improve not just the individual but the team and even the broader community.

So yes, the journey is tough, but the benefits—both personal and communal—often prove worth the effort!