Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm new to the opensource world. The project I'm working on resides on Github. (Just for reference) The project I'm working on is a plug-in for the Plex Media Server. I plan to submit my plug-in to Plex so that it will be included in their "app store". Now to my question.

When I first started out, I found an older semi-abandoned plugin that did some of what I wanted but not very well. I started by contributing to that repo. I was immediately made a collaborator with full rights to the repo since the current owner said he was too busy to mess with it anymore. However, as I started to dig deeper into the code I realized that it was futile. The existing code base was terrible and there was no efficient way to fix it. I ended up just starting from scratch. The only code I used in my new plugin was the code I committed initially.

Now the project is ready to be released. However I am unsure as to how to go about doing this. I see my options as follows:

  1. Create a new repo and just forget about the existing one. I'm not sure if I should even mention the previous repo and or its contributors. I didn't use any of that code/resources and have created an entirely new code base. While the plugin does some of the same things the old one did, it does it in an entirely new way and more efficient way.

  2. I fork the existing repo, delete the existing code, and commit my new code. I'm really new to Git, so I'm not sure if this is even possible.

  3. I commit my changes to the existing repo and see how the current contributors have to say.

Of the three options, I'm strongly leaning towards the first. BUT! I'm new to open source and I want to make sure I'm doing things according to proper etiquette. I don't want to have my first project blow up in my face and become a disaster. Option two doesn't sound bad but I'm not sure if I'm supposed to do that. I'm not sure how the history and diffs would work. We're only talking about 500 - 1000 lines of code at most. So it's not a huge code base.

Thanks for any input you can provide!

share|improve this question
10  
Since it's all new code, I would tend to go with #1 because the history of the old project is really irrelevant. But it would be nice to add something to the README along the lines of, "Based on an idea from ....". –  Peter Rowell Mar 3 '13 at 20:17
2  
@PeterRowell please put that comment in an answer so I can upvote it! –  MattDavey Mar 3 '13 at 20:49
    
@PeterRowell Thanks for the advice. That's a great idea. –  Matt Keller Mar 3 '13 at 22:18
1  
@MattKeller: Done. Thanks for the nod. –  Peter Rowell Mar 3 '13 at 23:21
1  
For 2, there's no need to delete the existing repository. Whatever you do, I'm sure the original developer would appreciate you telling him you're forking the project –  James Mar 4 '13 at 0:00
add comment

1 Answer

Since it's all new code, I would tend to go with #1 because the commit history of the old project is really irrelevant. But it would be nice to add something to the README along the lines of, "Based on an idea from ....".

I'm a big fan of acknowledging where we (or our algorithms) came from. If you look back into the mists of history, you'll see that we are all standing on the shoulders of those that came before—all of us. For example, I developed and marketed a similarity search engine back in the 1980's, and it seemed pretty radical to some people (Boolean was King back then). But the heart of the algorithm I was using was based on work started by Gerard Salton at Cornell 20 years before me.

share|improve this answer
add comment

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.