[META] To Be or Not To Be: Difficult Starter Kit

Clearly MNN, ChannelAustin, and key developers who work for those stations have put a lot of sweat and money into DSK at this point. I by no means have the answer to your question nor do I propose to tell ChannelAustin or MNN how to spend their budgets.

I do, however, represent one of the development teams that works with community media centers in Drupal. In an attempts to work directly from a starterkit, and perhaps without enough intimate knowledge of the development plans and roadmaps for these starterkits, for better or worse I am also probably one of the few people who was worked extensively with DSK. So I will offer a few thoughts.

First, and I'm not sure if this is information you are comfortable sharing, but I think it's important to understand how much money is currently being spent maintaining DSK. I do not know how much you and MNN are putting in. Thus, please keep that in mind as you read the rest of my thread.

Related to that $ question, and considering that a working configuration of DSK is, in my opinion, really to the level that will almost always involve a Drupal developer to be on hand for at least a portion of it, I propose another question: is it possible that money may be more efficiently spent and more useful to others if it is funneled into the support/enhancement of particular modules used by CM community?

It seems there is strong support of ESK and MSK at this time. I lean towards documentation and development support on specific modules from there as opposed to DSK because it seems that ultimately supports a wider community and still offers a collaborative environment for co-development. Reservations is a great example of a specific module that could be collaboratively developed by larger stations and adopted by smaller stations as it becomes more user-friendly and stable.

While I do not have extensive knowledge of the DSK, I would like to share a few observations. From what I can gather the DSK does contain Reservations API which is broadly shared though highly complex to configure. Most of the other modules, from what I can determine - seem like very customized modules with a narrow user base. And if I am oversimplifying, please comment.

Morpheus....Cinegy.....Telvue.....these are extremely important modules to those few organizations that use them but they certainly seem to make the DSK a beast to maintain.

I get the sense that the DSK is too complex to configure and maintain and adopt.

It seems like the ESK and MSK are working but that once an organization starts to tackle something like Reservations - perhaps Features needs to figure more prominently in creating some efficiency in the workflows. I have Reservations but not the DSK. I'm not sure what is in the DSK for me.

How does a DSK model work better or worse than an mou on shared an contributed code? I'm trying to visualize the difference. Of course, just getting to the point where shared code contributed back seems like an arduous challenge, but I think that is where the orgs are at right now. Wouldn't that work better for the clusters of shared development that is needed?

Hi all,

Sorry for the late chime in, its been a hell of a week.

I am Mark Libkuman and I am a worker/owner of Openflows, a development shop that has worked with MNN since 2006. Openflows built and launched MNN's internal tool Access Center using drupal 4.7 in 2009 and then helped project manage and helped develop the upgrade of Access Center to d7 Community Media.

I just completed a long call with Kevin Reynen and I left the call feeling really strongly in favor of keeping the DSK around. Access Center 2.0 was developed using the DSK. For a chunk of the development process we kept up to date with DSK and I personally rolled out a couple new versions of the DSK with security patches and new versions of things. But by summer of 2013 the rush to get a stable version up and running led us to limit development time and we stopped keeping up with the DSK.

Openflows is currently in negotiation with MNN for a new work agreement, as the old one finished with the completion of the Upgrade. If it goes as I expect, Openflows will be providing continued development of Community Media infrastructure for MNN and contribute it back to the overall community.

One of my first goals would be to get MNN on the most recent version of the DSK, then provide ongoing labor to see that the DSK gets sustainable love.

I think the DSK is important because it shows the upper bound of what you can do with Community Media. With the MOU of Channel Austin and MNN, I think can pave the way for the most robust set of functionality possible. Sure not every station will need everything, but i think every station will want at least one thing that would only live in the DSK.

Obviously, we need to make sure the process for keeping the DSK up to date is a functional one, that is supported my multiple folks with clear communication. I feel we can do this with just a little bit of organization, organization I am willing to help with once we enter into our new agreement with MNN.

I'd be willing to hop on the phone one on one, or in a group, to talk this out more.

I've feel like the description on DSK project page made it clear how this distributions was different than ESK or MSK…

Unlike the Easy and Moderate Starter Kits, the difficult kit is used more to communicate changes needed for the layer of customizations the stations building on top of it need. Stations can override the version of a module included in the kit to a newer or older version, but the goal is to continually push those changes into the distribution to maximize collaboration and minimize costs. As custom modules developed initially for these stations mature and become well documented, they are pushed down to the Moderate Starter Kit. Most organizations running the moderate kit have selectively added some functionality found at the difficult level.

We just finished a code review for PCM where we compared the versions of all the modules running on channelAustin, MNN, and PCM as well as identifying all the code that hadn't been share and configurations that could be exported as Features or shared in some other way. I'll share this as a Google doc with anyone interested, but since it shows versions of modules with known security issues publishing it publicly would put the sites that haven't been updated at risk. Even using 'drush pm-list --type=Module --status=enabled', it several hours to create this comparison. Despite the fact that all 3 sites are running some version of a CMD distribution, less the 25% of the code is the same version. This makes it very difficult to divide the cost of funding new development. The good news is that getting the code updated is a relatively easy process, but that is only because of contributions from channelAustin (me) and Arlington Independent Media (Ginko Street Labs) resolved issues with API changes in several of the CiviCRM related modules.

In the future, an export from https://drupal.org/project/profile_status_check should only show a handful of different module versions and custom modules that differentiate the sites.

It seems there is strong support of ESK and MSK at this time.

I really take issue with that statement. I'll agree that there is a lot of interest in using the ESK and MSK, but I've seen very little evidence of "strong" support. The same people continue to do most of the work and that is only possible if the organizations paying them have been willing to comprise some of their needs to benefit sites installing the code next.

Morpheus....Cinegy.....Telvue.....these are extremely important modules to those few organizations that use them but they certainly seem to make the DSK a beast to maintain.

It isn't. In fact it's actually much easier to maintain the DSK than the ESK or MSK because the target audience for the DSK are other developers maintaining existing sites. There is less need for documentation (we can just read the code), update hooks, user friendly installers, forms, UIs, etc...

The DSK is a tool for communicating changes, testing, and adhering the MoU.

At it's core the DSK is really just a list of the versions of modules that the larger stations are using. The MoU between channelAustin and MNN focusses on "doing no harm". All updates funded by either station (and any additional stations that agree to operator under the policies of that agreement) need to take the code and workflows of the other stations into consideration. That's only possible when the code is published. It isn't possible to take the configuration of stations like OKV or RETN into account when making updates because so little of the code and configuration has been shared publicly. Doing a screencast where you show new features and functionality that users can't download or configure isn't really sharing... it is just taunting. Even if the code is just a Feature export committed to a sandbox project on Drupal.org, it's a starting point for future development. If the only way another site can replicated a feature on a site built on a CMD distribution is to rewrite the code or figure out how the modules need to be configured through trial and error, something is wrong. That's not to say that everything in the SKD should be code another station could download and install. It may eventually get to that point, but the reason for adding it to the SKD is that any station committed to sharing any code that could benefit another station and operating under the MoU is using that code and it needs to be taken into consideration by the developers working for the other MoU bound organizations.

There is going to be a lot of activity around all of the distribution in the next 2-3 week. MNN has given ZivTech the green light to use ESK as the starting point of the mnn.org D7 upgrade. @avguy and I will be prioritizing the issue in #2185665: [META]Easy Starterkit Release Blockers that would make the most sense for ZivTech to take on. I've also been given the ok to end the channelAustin code sharing hiatus I've been restrained by. All of the developer collaboration will be done on Drupal.org, but nothing will be committed to the distributions that hasn't been RBTC.

As Digital Media Manager at MNN, and project manager for all MNN's Drupal projects, I'm happy to confirm that we've signed a new Work Agreement with Openflows, and that Zivtech are currently working on the ESK as they build a new D7 brocuhreware site for us.

One substantive issue here has been the need to deploy first, share second. Now our CMD installation is deployed, we can start to share and commit the work that's been done. It's frustrating that things flow this way, but means MNN will be sharing quite a bit over the next few months.

That includes, I hope, continuing to work on the DSK as a collaborative endeavor, and helping to setup whatever needs to be done to make sure channelAustin and MNN can be on the same codebase now, and hopefully bring PCMTV into the fold too.