So, I had been working on "woodcoin-b", which was just another woodcoin wallet / full node, but built on a fork of the current bitcoind / bitcoin-qt version as pushed by "the power rangers", a.k.a. what you get at github.com/bitcoin/bitcoin.git.
The idea was, why not have another client? It can't hurt and could strengthen the network. Currently, the reference client for woodcoin is, at least is afaik what most you folks run, a fork of litecoin with the woodcoin algos and genesis block dropped in, as advertised at github.com/funkshelper/woodcoin.git. Woodcoind and woodcoin-qt : solid, reliable, and fast wallets.
So then last week, the litecoin team (that is, the folks who update github.com/litecoinproject/litecoin.git), comes out and "moves to the 0.10 branch". I'm not going to get into what that means for litecoin, but basically it means I have to make some decisions on which codebases to maintain here. Simply saying "git merge" won't work here.
I'm not going to pretend that any of this controls the coin. Github could drop off the face of the earth, and me as well (and by the way, we both will), and woodcoin won't really care. However, I am going to do what I can to help the codesbases that I see as important while I can. In this regard, I am going to maintain our current reference client as is (forked from litecoin 0. as long as possible. A source tarball, with checksum and signature, sits at woodcoin.org/woodcoin.tgz at the moment (see download page for details). I encourage you to grab a copy just in case.
I'm also going to try to continue with a full whatever-we-find-at-bitcoin-github client, to be merged with any changes to that project.
-And- I am going to make a 0.5.3 woodcoin reference ciient (no gui), to be merged with any changes to that project (see thebitcoin.foundation for more info on that project).
However I don't at the moment see any need to try to duplicate the direction github/litecoinproject is going, that is we don't need to merge changes into our reference client in that way, not if the above two project are being maintained. Of course if you want to do that, you are welcome to it.
Please let me know if you have any concerns over the state any of this software is in, or have better ideas. Other related projects on the table for bounty:
LOGd (fork of BTCd written in GO)
LOG Android Wallet
OK, thanks for listening. This has been a forest-wide public service announcement brought to you by:
funkenstein the dwarf
This is really awesome.
I wholeheartedly agree with your "no merge" statement. If we're going to have a concensus network with multiple clients, a free range of used code would be best rather than everything being inherent of something else. So, for example, let's use the same general idea, but I really like how each project will take on a level of ambiguity of its own.
As for the direction of code, "In Funk We Trust" really comes to my mind. I think I can give a really sucessful example for a coin I've been involved a little bit in for a while. When Clams started out nearly a year ago, it was simply a fork of Blackcoin, which had its inherent forks (Peercoin, and so on). Now, however, it's taken on multiple characteristics of its own, and doesn't follow any code line of any other coin. The most important thing is when to know (key word, when) you should add a commit, and when not to. For example, it has some BIPS implemented, and some not implemented. It has the bitcoin autotools build system, which most coins don't have but has become a huge asset. I could go on and on here, but just one of these things can make a huge difference in the overall prospect of our user base, while another could make them neutral or turn them away. The important thing is leaving out the "extra", or feature creep that will turn users off. Again, it depends on the time. This is what makes coins truely great. From my experience, it's important to simply make the best decision on behalf on the coin at its current state (however impossible that may be) and not try to dilute it into just "being like these other coins". This is where your personal preference comes in, and you need to nitpick the code. There really isn't any other way. This is what will make Woodcoin, Woodcoin.
I almost think any indirect question regarding how to aim the project properly is almost a fallacy, but I see where you're trying to go with getting a general concensus of code direction. These new projects (in my opinion) should broaden our base for incoming developers, so that's the best thing really to do. I think in the case of Woodcoin, you really are the best judge. In fact, that's really the best thing you can do. In my opinion, this is what separates your style and other coin devs that would simply add feature creep. You're a thinker before a doer.
I hope that made a little bit of sense.
TLDR: In Funk We Trust!