Hello to all.

I have agreed to lead the development of Kora.  I'm going to split this intro into three posts.  This first post will let you know some things about my experience and my development philosophy.  The second post will discuss the already-expressed concerns and questions I have read in the Kora forum.  I realize there are a great many questions about the road ahead, and to be honest, we are in the very early phases of this project, and a successful project is not just about sitting down in a dark corner and pounding out code.  There are a lot of discussions yet to be had, and a great deal of planning as well.
The third post will discuss in more depth the phases of the Kora project.

I have been in tech a long time, working for and with every type of company from corporations to small businesses, government and non-profit.  I have worn many hats, from IT manager to developer to lead developer to project manager to database admin, and much, much more.  I have worked in both Windows and Linux environs.  I have coded all manner of languages, compiled to interpreted.  I have led projects that lasted many months, and ones that lasted days.  I have experienced the thrill of delivering a significant development project, only to have the project cancelled on release day.  I have fixed bugs that were simple syntax or spelling mistakes that took a few minutes to find, and I have debugged distributed systems that required hiring teams of consultants and subject-matter experts, and taken months to complete.

My most recent projects involved writing a number of payment card industry interfaces, and leading a team through PCI-DSS and PA-DSS, which processes are heavily vested in forensic examination of code and the platforms on which they run.  To say the payment card industry is proactive with security is an understatement.  In addition, I have written a number of apps and interfaces in support of telephony initiatives, for third-party control of analog or digital phones.

My development philosophy favours simplicity and elegance over complexity.  I believe in starting small, but with big blueprints, and therefore I believe that the best apps are ones that provide a core function and do it well, but are architected such that they are extensible and scalable.

As for coding, I prefer code reuse whenever possible, up to and including cloning an entire cryptocoin codebase.  I see people all the time singing praises of some app that has an "original" code base.  That might be worth a brief price pump, but what does it really mean?   More often than not it means that someone spent an inordinate amount of time writing an original clone of an already finished product.  There is a time and place for that, but it pays to explore existing solutions.  And more importantly, there should be a very good reason or reasons to start from scratch.

If you go through the codebase of any coin, you will see that most code is not truly original in the aggregate.  Who is going to write a new java library when one already exists that is both optimized and free?  Why not use the boost libs in C++ instead of writing your own?  Or STL?  Even the web uses libs now.  Go to any modern website, and you'll see the prolific reuse of JQuery and hundreds of other JS libs that are free to use and customize.  This is not cheating - it's sensible.  When a civil engineer builds a bridge, he doesn't build a new kind of bridge.  Instead, he reuses best practices and designs that have proven themselves effective.

I am not a language purist or a language snob.  I don't have any opinion about what the best language is.  I have coded a number of them, some I guarantee nobody has ever heard of or ever will hear of.  The fact is, most modern high-level languages will get you where you want to go.  There may be business reasons to use a specific language, such as prevalence of people who know a language, or even client requirements.  It would be somewhat insane to code Kora in LISP unless there existed a huge pool of people who know the language, and who could be easily and cheaply recruited.  So, if I decide the way forward is in CPP and not Java, it does not mean that Java sucks.  It means that given the project requirements, CPP satisfies more business requirements than does Java.  And the reverse may be true.  I'm not saying that I have made any decision about language, this is merely an example.  What I am saying is when the time comes, I will choose the language based on the business needs of the Kora project.

Now that I've regaled you with a bit about myself and my development philosophy, the next stage will be to post something soon that answers questions from the main forum, and also a post that defines the project and its phases.

Stay tuned.

-nio

Exciting times ahead indeed. Great to see you on board nio.

I get what your saying, and we all signed up for Kora, a clone of Qora.

Just saying Qora isn't doing all that great.

NEM started off with the same intention, to clone Nxt. If they did that, they would have been tiny, like NAS.

Just saying no one thought Kora was going to be some top ten crypto. That's for sure. But its going to be great and fun. It has a great community already. This happened with NEM. They did the switch, decided to write the code from scratch. Yes, of course they still used a lot of the same stuff in the code where it made sense, but also made their code, their own, and became not a copy of Nxt, but took their inspiration from Nxt.

NEM will launch in the top ten of all cryptos.

Just saying, if you have the skills to write Kora it's own code. You would make history. Kora would be BETTER than Qora.

You would have a great community behind you. And if you can do it, and have the time, I'm sure the Kora community wouldn't mind you using the amount of stakes saved for the dev fund with NEM as a yardstick for Kora.

Just saying, you might surprise yourself, and come up with something even more unique than originally planned. Think about it. You would be compensated well for doing this for us. (See NEM Development Contract for reference)

Anyway, whatever we do, I am happy to see such a great and talented person as yourself becoming a part of this community, in such an important role!!!


Thank You,



Chris

+1 what Chris said. New code will set Kora apart.

However, I see a lot of promise in the way that Kora, Mac Red and nioccoin interact.

I get the impression that the so-called 'devs' are communicating well in whichever role they are involved: as project manager, as administrator, or as programmer.

Not only that, they invite participation and input from others - from us. This team is going to go far!

Pentamon

i agree with chirs try something new and please choose another name not Kora 

Kora is on right track with great community and developers , keeping watch on this thread.

Just an update for the Kora community:  I am working on the planning documents for the Kora Coin project, and also the same for the koracoin.com website.

I.    The first phase of Kora was to gather stakeholders.  Mac Red has done a fine job on this, though his task is not yet over.

II.   The second phase of Kora will be to get a website up and running.  This is a marketing tool, for now, and is more for non-stakeholders to help them evaluate Kora.  One of the things people look for to legitimize a coin is a website, plain and simple.  In a few months, I can all but guarantee that Kora will look nothing like it was first envisioned.  At that point, the community might desire to reinvent the website to more closely match what Kora has become.
Having said that, the website will also be intended as a portal from which you may download the project documents.  So it is also for the Kora community.  This may change, and these ideas will all be discussed in the kora website project plan.

III.  The third phase of Kora will be the coin itself, which is really what we are all here for, right?  The purpose of this phase will be to get a coin and wallets working, primarily so we can distribute stakes.  This is intended to be a baseline project, and will have little in the way of frills.  The reason is the more complicated this phase, the longer it will take, and aside from major structural or architectural changes, there is nothing that cannot be added to this deliverable that cannot be done in phase IV.

IV.   The fourth phase of Kora will be to build new features on top of the base coin.  This phase is the most iterative of all, because it gets repeated ad infinitum, with new things each time.  There will be some overlap with phase III.  Some of the overlap will be significant.  The reason is that from an architectural standpoint, phase III needs to be as loosely-coupled as possible to allow for changes and additions.  However, having some idea of what phase IV will include is necessary for phase III to succeed in creating the hooks for new features.  When I begin asking for feature ideas, it may seem premature, but this is the reason why:  As many of the phase IV ideas as possible need to be gathered during phase III, if even they aren't implemented in phase III.



So, we will kickoff with the koracoin.com web project, which will give us an opportunity to work together and give everyone a taste of how the coin project itself will likely proceed.  Since the website is a much, much smaller project, it allows us to blow through the project phases pretty quickly and get accustomed to how this all works, and make adjustments to the process as needed, without fear of stepping on landmines.  It gives us a chance to work together when the stakes are lowest, and the stress level is lowest.  This is no guarantee of future performance, as they say, but it will allow me to see the community and how we work together.

Meanwhile, I will be addressing many of your questions and concerns about the Kora Coin within the soon to be released project plan.  The "baseline" project is to clone Qora.  This may or may not be in Kora's best interest, but this will be our starting point for a community-wide discussion.  I am aware that many of you have anticipated this baseline, and have already panned the idea of following in Qora's footsteps.  I am not ignoring you, and in fact your concerns are already written into the baseline plan under the "risk register", because what you have pointed out constitute the risks of cloning Qora.  I hope I have covered them all, with your help, but if not it is easily amended.

The advantage of a formal project approach is it will help us to discuss the project in a holistic manner, to make certain we neither miss any opportunities, nor take any license we may later regret.  But most importantly, it will help us to scope the project, so that we stay within the project's boundaries and in so doing we will (hopefully) not have to slip the schedule.  The Kora Coin deliverable doesn't mean the project ends, it merely means it enters a new project phase in which we embellish our creation with new features that set Kora above competing coins.  And the final phase is "rinse and repeat" as many times as is needed.

After the project plan is released, we will enter a feedback loop in which the Kora community provides commentary on the elements of the project plan.  In theory, we then would begin modifying the plan until we come to an agreement on how we want to proceed.  At that point, we would break out of the feedback loop with the business requirements in hand, and go to work designing the code.  Upon completion of the code analysis, we may have to reenter the project plan to adjust for technical implications, and enter that informed feedback loop again.  At some point we would arrive at the code development phase, and in theory the deliverable from that phase would end the project phase III, and begin the maintenance phase in which we add features.
I would like to point out that this process will certainly not be linear, but cyclical.  We may get to the end of phase three and have to go back to the project phase to make changes or additions that cause refactoring or redoing the code analysis and therefore the code itself.

As your ideas are considered and as we attempt to enroll them into the project plan, I will be working on concurrent analyses to evaluate and attempt to quantify or qualify the impact of those on the facets of the project such as the timeline, the scope, and the budget.  That will give us some solid standing upon which to decide what to include and what to exclude.  Again, phase III is purposed to be about delivering a working, basic coin.

I'd like to briefly address your ideas in general.  We will endeavour to listen to all comers, with all ideas.  There will be some ideas that will be embraced by the community, and some that will be rejected by the community.  Within reason, I will be adding these ideas to the project (though I will be reserving the right to combine similar suggestions into a simpler overarching one).  That does not mean your ideas will be included as features, but that they will be documented.  

Whether the ideas are accepted or rejected, the rationale for that acceptance or rejection will be described in writing.  The reason for this is the eternal nature of ideas.  Some ideas, I grant you, are just plain bad ideas, objectively.  But I've seen many ideas that having been rejected for one project or phase, ended up being incorporated as a solution to a problem or challenge elsewhere.  I have personally borrowed ideas from an unrelated project to solve problems in a new project.  You never know when an idea will blossom, and the purpose here is to capture the idea, even if we keep it captive until it is needed.


kind regards,
nio

Hi Chris, thank you for your insightful comments.  I can't say I disagree with you on any of those points, except my vision is for Kora to be a top-ten crypto

Correct me if I'm wrong:  Your suggestion seems to be "hybridize the code", making it part original and part rote, and that would split the difference?

Building this idea out a bit, we could clone parts of a coin, the "mission critical" parts such as staking, algorithms, etc.  This is the stuff that it makes no sense to write from scratch, because the security implications will drag out the testing, delivery, and make it subject to code review requests.  By cloning the critical parts of a "known good" coin (or coins), we dodge a few time-consuming bullets.  Then, we would build a working proof of concept, and use that as a jumping off place to start innovating.

I will add this to the project plan, as a candidate solution to the issue of cloning Qora.  If you could confirm I have correctly interpreted your suggestion, I would appreciate it.

If anyone sees any problems with such an approach, or has any addendums to this suggestion, speak up and I will incorporate them into the plan.

kind thanks,
nio

Oh yeah baby!!

 

Here we go!!!!

haha, another guy like me with that "Oh yeah baby!!" spring in his step!!

Kora (and reading nioccoin dev posts) are good for your health