Not a fork

Freshness Warning
This article is over 9 years old. It's possible that the information you read below isn't current.

A question has come up here and there about what we’re doing with this community platform, especially now that’s it’s been dubbed "Gnomepal." Are we forking Drupal?

We have no intention of forking Drupal. That would be nuts. Drupal has such a great developer community, why would we want to toss that aside and build our own little fiefdom? What we’re doing is creating a pre-configured instance of Drupal with the right themes and modules woven together. With the custom code that’s needed to get it all to work.

Drupal does a lot of things. We’re taking one of those things (community) and building all the little things that are needed to make it work right out of the box. Much of it already exists either in the Drupal core or third party modules. But getting all those things working together and working well is a challenge for the non-developer. It’s not going to be for everybody and not appropriate for every site. And that’s okay.

Someone made this apt analogy. We’re Ubuntu to Drupal’s Debian.

We’re creating a way to install and use Drupal. We think it’s a better way for the types of sites we’re targeting. We think that Drupal’s power and flexibility makes it a fantastic platform to develop content sites on top of. We hope that lots of people still build their own custom sites using it. But for those non-developers who want to put together a site for their school PTA, their baseball team, or their department’s intranet, we’re building an app that can be downloaded and launched in minutes.

Eric
March 27, 2008 1:30 PM

I was wondering if you are looking for a solid beta tester to be included in testing out the new platform. I would be interested in using it for a site that needs all the features you guys have been discussing and could be a solid launchpad and live case study for the project. Please let me know if you would like to work with a great web producer that can give you good feedback and test things out in a live environment.

Dries
March 28, 2008 12:12 AM

I wrote about this two years ago: http://buytaert.net/drupal-distributions -- take these guidelines to heart. :-) Looking forward to collaborate.

Adam Kalsey
March 28, 2008 1:07 PM

Dries -- Certainly. The whole goal of this is to have something that someone can simply install and use. That updating is possible, not by trying to figure out what the latest version of module X is, but by getting an update of the whole package. Eric --We're quite a ways off from a beta, really.

Kieran Lal
March 29, 2008 7:01 PM

Hi, CivicSpace was a fork of Drupal because we couldn't initially get the core worthy installer that would meet the core developers needs. At the same time, we needed to meet end-user needs, particularly the tech saavy grassroots organizers, NPOs, and political folks who wanted the power of Drupal but needed an on ramp. Much has been made of forking Drupal and why it's a bad thing. Having gone through an expensive unforking process at CivicSpace forking is certainly something you shouldn't do lightly. But here's some guidelines for branching that should maximize your flexibility. 1) Drupal's principles include experimentation. You should experiment as well. There's nothing wrong with adding patches to a version of Drupal that meets your users needs. Just clarify that they are patches, and include them as part of the distribution so that people can easily go back to core Drupal. 2) Drupal code is really clean, and easy to modify for a PHP app. One of the advantages of this well documented code is that it welcomes changes. If you make changes to core, and a huge amount of developers do make core changes, include patches and comment well. Make sure your patches run cleanly through coder, and follow Drupal community conventions. Be sure to post your patches to a Drupal.org issue so others can review those patches and give you some insight how to get them into either a contrib module or a future version of core. If you introduce a security vulnerability, you'll want thousands of developer eyeballs to be familiar with the patch code style so they can easily spot it. 3) There's good stuff in HEAD, use it. Your users or your business might not be able to wait for the Drupal development cycle to put out it's next release. If you aren't running five patches from head by the end of a Drupal release cycle, you aren't paying enough attention to the excellent work being done in head: CSS aggregation, Javascript aggregation, Master-Slave, contrib replacements of core modules, back-ports of Forms API are all things we've used at CivicSpace in the past. Open Source isn't just some moral high ground, make practical use of your access to the source. Make Drupal better by distributing patches from HEAD to your users and tell the Drupal core developers how it's working, particularly in production. 4) Have a yellow light stopping distance. That's the imaginary line when you decide to blow the yellow traffic light by speeding up, or slowing down to be safe. You should have a roadmap that states when you are going to stop hacking your own distribution, and commit to getting something into core. At CivicSpace, we committed to getting the installer back to Drupal core in 4.6. We submitted patches in 4.7 and kept at it through HEAD in Drupal 5. By the time everything was said and done a lot had changed, but that's part of the collaborative process. So don't be afraid to make radical changes and experiment, just make sure you are building meritocracy points (testing other's core patches, making smaller patches to core, etc.) so that your commitments to get changes into core are credible. 5) Use terms like distributions, or branches, instead of forks. The word fork contains a lot of drama for open source communities. Avoid it if you can. But Linus and Alan Cox each maintained their own branches of Linux. Almost every Drupal hosting company has their own "Branch" in SVN which meets their own security, feature, and business needs. All the consulting companies, particular those that deal with big sites have branches that deliver higher performance benefits, often with improvements that are customer specific. Don't be afraid to do the same, but keep a patch for core up to date in a Drupal core issue for your distribution. It will make the core contributors comfortable that you are being open and transparent. Hope that helps. Drupal community Adventure guide, Acquia, Inc. Founder CivicSpace LLC

mary
April 15, 2008 7:51 AM

This an interesting topic to bring up but the follow up done by CivicSpace was extremely helpful. I find the most interest in the use of terms instead of "fork" in open source communities. I can see where the drama induced by this term could spark a conflict of interests but I guess I don't find it to be as much of a problem. I am not an expert so I cannot add constructive insight like before me, but it was this very a helpful topic that clarified a few key points. Everyone should consider 4 and establish their own "yellow light"

Your comments:

Text only, no HTML. URLs will automatically be converted to links. Your email address is required, but it will not be displayed on the site.

Name:

Not your company or your SEO link. Comments without a real name will be deleted as spam.

Email: (not displayed)

If you don't feel comfortable giving me your real email address, don't expect me to feel comfortable publishing your comment.

Website (optional):

Follow me on Twitter

Best Of

  • How not to apply for a job Applying for a job isn't that hard, but it does take some minimal effort and common sense.
  • Simplified Form Errors One of the most frustrating experiences on the Web is filling out forms. When mistakes are made, the user is often left guessing what they need to correct. We've taken an approach that shows the user in no uncertain terms what needs to be fixed.
  • The best of 2006 I wrote a lot of drivel in 2006. Here's the things that are less crappy than the rest.
  • Rounded corners in CSS There lots of ways to create rounded corners with CSS, but they always require lots of complex HTML and CSS. This is simpler.
  • Debunking predictions Read/Write Web's authors have some goofy predictions.
  • More of the best »

Recently Read

Get More

Subscribe | Archives

9

Recently

Physical camera shutter for Cisco Spark Board (Jul 6)
A 3d printable design for a camera shutter for a Cisco Spark Board
My Travel Coffee Setup (Jan 20)
What my travel coffee brewing setup looks like, and how you can build your own for under $100.
Turkey Legs (May 30)
Product naming gone awry.
Speaking for Geeks: Your Slides (Dec 17)
Tips and tricks for creating great slides.
Speaking for Geeks: Writing Your Talk (Dec 14)
Don’t wait until the night before the talk to write it. Crazy, I know.
Speaking for Geeks: Tell a Story (Dec 13)
Telling a story keeps your presentation focused, keeps your audience interested, and makes it easier for you to remember your talk.
Speaking for Geeks: Where to speak (Dec 11)
You've got a great idea for a talk. How do you find conferences to submit it to?
Speaking for Geeks: Getting your session accepted (Dec 10)
Your conference speaking submissions are not getting accepted because they're bad. Here's how to make them better.

Subscribe to this site's feed.

Elsewhere

Tropo
Voice and communications platforms, including Tropo and Phono. Work.
SacStarts
The Sacramento technology startup community.
Pinewood Freak
Pinewood Derby tips and tricks

Contact

Adam Kalsey

Mobile: 916.600.2497

Email: adam AT kalsey.com

AIM or Skype: akalsey

Resume

PGP Key

©1999-2017 Adam Kalsey.
Content management by Movable Type.