current community

your communities

more stack exchange communities

Stack Exchange Inbox Reputation and Badges
tour help
Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.
up vote 4 down vote favorite

I'm creating an open source PHP project that reuses other open source code instead of reinventing the wheel. I'm using composer to pull these projects into my vendor folder. What happens if these vendors delete their repository & all traces of their code from the internet? Now composer can't download the project. Should I fork every project I'm depending on, and depend on the fork? Seems like a pain, but the only 'safe' way to ensure the vendor can't delete things my project needs to run.

share|improve this question
1  
using the fork also protects you from breaking changes... –  ratchet freak Jul 6 '13 at 15:43
    
That's handled by composer.lock, but it assumes the upstream doesn't delete a tag & create a new tag that differs from the original –  Josh Ribakoff Jul 6 '13 at 15:47

2 Answers 2

up vote 3 down vote accepted

I wouldn't start out with the assumption that the maintainer of a third-party library that you use will pull the rug from underneath you. It is far more common that a maintainer leaves a project abandoned on the net than that they actively remove it.

In the off-chance that a dependency of your project does get pulled off the net, chances are that you still have a local copy of the source code of that project somewhere in your build, test or deployment environment and you can use that to fork the project then and there.

share|improve this answer
    
"It is far more common that a maintainer leaves a project abandoned on the net than that they actively remove it." I had that the website of a library I needed was down. Luckily I was able to acquire the ZIP from another website. Anyway, forking is overkill, just keep a local backup of the files, just in case. –  Jop V. Jul 8 '13 at 9:11
up vote 0 down vote

OK, I'll play the devil's advocate here: forking in today's DVCS world is so cheap, and so low impact that yes, I would definitely fork. Aside from the possibility of the project owner executing a Mark Pilgrim and actively seeking to delete their online presence this has the added benefits of being able to work out things that appear to you to be bugs in the original project while still relying on an online repo (and all of the associated benefits thereunto) without issuing a pull request for your changes and also without having to update your vendor-relying code to point to your new fork when you decide that you need to fork to try to address an issue you've found.

In fact, I wouldn't rely on another project without forking it first - it protects you against all manner of possible chaos, and costs very little to maintain.

In addition, and this is somewhat github-specific, but one measure of the adoption of an open-source project is how many forks it has, so in one sense you're adding credence to the library you're consuming by saying "I think this library is important enough that I want my own fork."

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.