Topic: NXT :: descendant of Bitcoin - Updated Information - page 500. (Read 2761624 times)

Yes, I need to think about how this should be done. Before the source was public, the problem was how to decide who is trustworthy. Now that it is open, how do we decide who is good enough?

Companies conduct technical interviews. Those will filter out the completely ignorant, but for more experienced people it becomes difficult to judge who is better. I am also not confident in my own skills as an interviewer, and also some good people perform bad at interviews because of the stress and pressure to perform. Especially for an open source project, I don't feel doing interviews is the right approach.

For paid developers, we could consider trial projects, which they would do on their own fork of the repository, and if at the end we like the code and integrate it into the main repository, we accept them as paid developers. This would mean they would have to spend a few weeks without pay at first. Or, we can take the risk and do it as a one month paid contract, with the option of making it permanent. This would be something the NXTtechdevfund committee should discuss.

I would need to research how other open source projects decide who to accept and trust, e.g. how the linux kernel development is organized, and see if we can adopt their project management practices.

In terms of skill set, being a very good Java developer is the only requirement. The code does not depend strongly on any specific tool or library. We use a database, so some familiarity with relational database and SQL is needed, but there are enough areas of the code one can work on without touching the database at first. We also use servlets and Jetty, so again familiarity with servlets and the http protocol would be helpful, but most Java developers already have that.

Good object-oriented design skills are essential. So is writing clean and maintainable code. For developers with main background in languages other than Java, I can tell immediately that Java is not their native language - I have seen lots of Java code that reads like C. The original BCNext code was very foreign too, so I had to rewrite lots of it. So for somebody coming from C/C++ background, if this is going to be their first Java project, they would need to learn a lot, so that the code they add actually reads like Java.

In addition to Java developers, and in fact much more urgently, we need a good cryptographer. This person doesn't even need to be that fluent in Java, the language background wouldn't matter (well, he should at least be able to read and understand the Java code). But I don't have much cryptography background myself, so this is an area where we currently lack skills, especially after the departure of BCNext.

If you´ve read my PM, I am trying to help you build a core dev team...

I did my research on random string generator libraries, it seems apache RandomStringUtils is not compromised.

Does it shut down NRS when you close it?