There has been some discussion on a Github issue of SilverStripe Ltd’s openness in its work on the SilverStripe core project and our commercial influences. We’ve recently started using UserVoice to keep track of potential features and roadmap, and because we haven’t clarified the process by which those turn into commits on master, we’ve ended up sending the wrong message.
How a feature is designed, and whether it's appropriate for inclusion is something that should be discussed by the community, and eventually decided on by the core committers group.
When it comes to what actually gets worked on, that's up to individual contributors, including SilverStripe Ltd. In practice, much of the work that goes into SilverStripe and other open source projects comes as an extraction of client work. For our part, we sometimes use client work as a way of getting feature development funded—and these features happen sooner—but we don't let clients dictate architecture. We assume that other contributors to SilverStripe work in a similar way, and see it as a pretty common part of the “do-ocracy” that is that open source.
One point of conflict was discussions on which version a particular change should be included in. As mentioned in a separate thread, we think it’s worth adopting semantic versioning, which will make this much less of a grey area. The response from everyone who posted there has been very positive, so as mentioned there we’ll be looking to do that from now on. On the specific point of namespaces, it means that namespaces *must* be left until 4.0. Our hope is that, in adopting semantic versioning, we eliminate one cause of tension by having a standard that clearly defines which release a feature is appropriate for, putting SilverStripe Ltd and the rest of the community on a level playing field with respect to deciding which version a change must be released in.
In addition to that, we’re looking to make the following behaviours a standard part of our work on core features. We’re starting with these internally, and we’re hoping that others will follow our lead.
* Significant core features will be raised on UserVoice as soon as it’s something that we’re considering developing.
* Before starting work, a discussion will be started on silverstripe-dev, and the UserVoice feature will be marked as “Planned” (this is a slight change from what we did on namespaces where we raised an issue instead - however given the response, silverstripe-dev seems the more acceptable venue).
* Any internal/offline discussion that results in a decision that will affect the outcome will be summarised on the silverstripe-dev thread.
* The core contributor group will be expanded with additional people that the existing core contributor group feel have made a significant impact to the project and shown pragmatic decision making in line with our vision for the future of SilverStripe as fast as is practical.
Where I’d personally like to get to is that the core contributor group is big enough that we can institute a rule where a PR is never merged by another individual from the same company, but we’re not there yet.
We believe that these changes will help to make SilverStripe development more inclusive, but we’d welcome any feedback if you disagree with any of the above. We don’t expect that this will be the last time we look at ways of improving the working model for SilverStripe development, but we believe that continued incremental improvements will create good results.
In addition, SilverStripe are looking for other ways of exposing both SilverStripe Ltd and the core contributors group’s thinking and long term plans, and we hope that the community will enjoy and get involved with these. We’ll post more about those shortly.