Evolution of a growing community

 

As the community guidelines are now available, I thought it useful to expand a little on what the core TrueOS developers are looking to do over the coming year(s). We’ve had lengthy discussions in the office about the current relationship between the core developers and broader community, and ways to improve it. This isn’t to say the current interactions are poor or wrong. Far from it. The TrueOS community is a constant source of inspiration and value, and I hope all can see the underlying respect the developers have for our users/community.

That being said, Kris and the others identified a few areas where the core developers can improve, in order to better serve and expand TrueOS as an Open Source project and community.

 

Assumptions and improvements

 

In our collective navel-gazing at the office, we’ve identified a few areas of improvement:

 

  • Encouraging the community to make strong/large improvements to TrueOS. Currently, one perception/assumption among the developers is the broader community is timid about submitting changes or patches to TrueOS because its “Kris’ baby and he won’t like my changes”. This may be a misconception on our part, but we want to formally dispel that idea with the publication of the community guidelines and other in-progress documents. Part of the longevity of the TrueOS project is due to Kris and others anticipating the users’ needs/wants, but they can’t get it right every time. The infrastructure for you to take and guide the TrueOS project is in place, and we promise your patches won’t hurt our feelings.

 

  • Be like FreeBSD (but not quite). Everyone in the TrueOS core group comes from or currently is part of the FreeBSD community. Naturally, we’ve decided to base some of our community guidelines and interactions off their model. However, there are a few key differences from FreeBSD we would like to attempt. We think these changes will better serve the TrueOS project, given its size and disposition. First and foremost, every contribution adds to the project. If there is no discussion or concerns over a pull request, that request will be automatically merged. The developers want the contributors to quickly see their contributions integrated in the project. Another key difference is the elimination of commit categories. Again, TrueOS is much smaller than FreeBSD, so we think a contributor who has earned a commit bit should have access to the entirety of the project. Finally, simplification is key. The first element of our contributor guidelines that we all immediately agreed upon was simple. To that end, you shouldn’t expect to see the guidelines drastically expand. The core idea is to put up a few small fences, and let the community run with their ideas.

 

  • Expand or change the “core” team. One element we are still discussing is how the core developers function, or if we should create a process for community members to become part of the core team, similar again to the FreeBSD model. This goes back to the idea of letting the community further “steer” the project, and alleviates some of single points of failure in Kris or the current core developers. Let me emphasize we are still discussing this, so no formal announcements yet, but feel free to discuss it with us on Gitter or Discourse.

 

Short and Long-term

 

As with most TrueOS development, how these ideas play out is largely dependent on the users/contributors. Short term, we would like to see pull requests and/or discussion of patches/changes to TrueOS increase, with perhaps a bunch of community members earning commit bits. In the long run, we want the community to continue to be vibrant and resourceful, with a significant role in guiding and crafting TrueOS to be the best Open Source OS.

Are we crazy? Tired of walls of text on the blog? Would you like to know more? Get in touch with the developers through one of our many community channels. If you want to start contributing to TrueOS, there are a number of guides in our handbook to help you get started.