OSS project maintainers have a serious load on their shoulders. They are responsible for authoring and maintaining tools that enable developers to deliver business value faster and easier. Gone are the days where a developer has to start every project by defining their own IO, data structures and sub routines. Modern developers rely on frameworks, third party libraries and other niceties that use to take hundreds of developer man hours before writing any business logic. Being a maintainer, and focusing that level of effort is a labour of love, but a labour not the less.
We as .NET developers shouldn't rely solely on Microsoft to provide tooling. We shouldn't be naive in thinking that the latest update to a NuGet package just magically materializes from the ethers. These things happen because our peers make them happen. They provide time, talent, and capacity. This is time they could be spending with their kids, learning to play guitar or preparing for the next 5K. Developers that consume these tools can change the narrative. We can get involved.
There are many levels of involvement. Creating Issues when we encounter odd experiences. Pull Requests if we happen to find and fix the root cause. Feedback on how easy the tools we use are to consume and integrate into our pipelines. Monetary to offset the "free" software your business is getting value from consuming.
There comes a time when a single point of failure in an application can bring down an entire system. This happens in OSS as well. The maintainers of ReactiveUI have done an amazing job putting together a library that allows for use of Functional Reactive paradigms. Now is the time to help alleviate a single point of failure and setup a scalable system to take ReactiveUI into the next era of Open Source Software.
We, the consumers of this library, need to find a way to pull together and maintain this library as a community. We need to establish a road map, identify new features, create a community stand up, delegate work so we can continue to react long after the current maintainers step away for some well deserved rest and relaxation.
We have to accept that if we don't contribute, ReactiveUI won't grow. That there may not be a fresh NuGet package when we need a bug fixed. There may not be not be a library when the next evolution of .NET comes out of Microsoft. I urge you to get involved. We don't want a tragedy of the commons. We want a healthy way to tame mutable state in the .NET eco system. ReactiveUI has been our tool this long, and we want to keep it healthy, stable and fresh for years to come.
I believe the community needs to take the following steps:
- Establish a unified vision and product road map
- Create teams to help delegate tasks
- Organize our approach for delivering value
- Preach our successes, and get people interested in ReactiveUI
- Grow the community, and help each other learn
There has been a lot of conversation in the community around these topics over the last two weeks. We are planning an overhaul in the way we deliver ReactiveUI. These topics have been at the forefront of the ReactiveUI teams discussions and there will be some announcements over the next week explaining more. If you can't wait for these announcements because you've just got to know how you can get involved, join us on Slack ReactiveUI Slack and head into the #reactiveui-succession
channel to find out how you can be part of these changes that will shape the future of ReactiveUI!