I can understand why you think this, and it is possible that in the longer run this may happen (but I wouldn't hold my breath).
I'll just very briefly explain why:
Because both OpenPDroid and PDroid 2.0 are GPL v3 (as a result of being derived from PDroid, which is GPL v3 licensed) good ideas and code can move between them. I like to think of it like CyanogenMod and AOKP - there is a lot of cross-over but some differences; good ideas and code can be ported from one to the other, and the variants suit different people's needs.
- Right now there is no clear way of submitting code (or even issues, in any structured way) to PDroid 2.0, whereas in OpenPDroid you can fork on github and then add a push request. You can lodge issues in github along with details, and that allows feedback to be provided. If people post suggestions in here, then we can add them to github as 'enhancements', they can be discussed there, and those discussions can be entirely visible to users. The basic idea is that the whole process is 'open' and visible - and open to further discussion.
- The development life-cycle for PDroid 2.0 is that CollegeDev does a bunch of development, then releases a monolithic patch with all those changes and without anyone seeing the code before. This pattern means that code review is not possible before release, that compatibility changes can not be made in other apps (e.g. PDroid Manager, and any other pdroid-interfacing apps that may appear) prior to release, so compatibility will inevitably be broken at time of release.
- There are aspects of the direction of PDroid 2.0 which are not consistent with what we have in mind for OpenPDroid. For example, the current PDroid 2.0 App suggests that 'task killing' will be integrated into the framework changes for PDroid 2.0. Currently (acknowledging we have not seen the framework code changes), we have no desire to include this functionality in OpenPDroid. There are very good task killer apps out there, and it doesn't really fit in the purview of a privacy management mod. Similarly, there has been discussion of incorporating encryption/authentication of manager apps, and of the data. This may seem like a good idea, and may even be a good idea - but it may have side-effects which outweigh the benefits, and without having an alternative like OpenPDroid no-one has any option but to accept it.
Thanks for this clearification of your sights and reasons to do what you do :good:
I hope CollegeDev will see the advantages of the "open" source way (github, code reviews etc.) and join it. Within such an important and even sytem critical app like PDroid, it's not a good idea to have only one dev who has a real life and can't react to serious bugs etc. as fast as it could be nessesary. Here the power of some more dev's all working on the same codebase would be a perfect situation. Four our six eyes can see more than two, which would be a good thing hunting difficult bugs or discussing new features. How fast can you be stuck in an dead end you haven't foreseen
I hope this will become true