Regarding milestones:
I agree with patmast3r that the community together with the foundation should first vote on the components. There are always must haves and nice to haves. There should be a focus on must haves before we can talk about nice to haves.
Regarding the proposal:
Blockchain technology is moving at a rapid pace and what might seem a good idea for a future milestone now can become outdated in a matter of months if not weeks.
This is why I will not support the current proposal. However, I will definitely support the funding of a NEM library (including a tech doc) should you decide to propose it. This is what is needed the most and you will probably encounter the least resistance in getting funding for this.
Regarding the funding sum:
Currently you are asking for 3 million USD with a projected completion time of 14 to 22 months (as stated by @bcn ).
If you are expanding your team to include another 3 developers (making it a team of 10 people) and want to have job stability for 24 months instead of the stated 22 months your total salaries would be 1.4 million USD (at an average of 70k USD per person per year).
Include a few hundred thousand for overhead and marketing and you are looking at 2 million USD (realistic revenue for a 10 man company for 2 years) and that is only true if the XEM price stayed the same but we are all in this because we expect the price to rise over time. Hence, the funding sum you are asking for is high (too high in my opinion).
Conclusion:
In my opinion it would make a lot more sense to fund you with the equivalent of USD 500k for a proper NEM library with documentation and go from there once it is finished. I really hope you propose this.
I support the proposal. Yes 15M XEM is a lot but there is risk involved, the team would be sticking their necks out. If they are successful in lowering the development threshold (critical to the mission IMO) then good for them, they deserve it. I am not bothered by the XEM volume.
I do agree it may be beneficial to have the milestones more dynamic. Projects with long horizons need to be dynamic and able to adapt. That said, we also need a means to measure if the team delivered. I’m curious what the community thinks about this: IMO it should be possible to -maybe using a voting mechanism- change the milestones halfway through if this is deemed desirable.
I have confidence in the technical aspects. Area’s that could end up getting too little attention are documentation and marketing (yes this framework also will need to be marketed IMO). Both of these are key to adoption.
NEM really needs this work done. I have 15 years as a software producer and I have seen a lot of project bids. If we were going to hire a specialized crypto software development firm to do this the price could easily be MUCH higher. We are in the blue chip category now. We can’t afford to sit back and hope that volunteers want to do this stuff.
IMO the risk of letting NEM fade away from moving too slowly is much greater than the risk of paying for projects that may or may not deliver to expectations. Adoption and business partnerships are going to be the lifeblood of NEM moving forward and it’s time to open up the throttle.
Developers who have blockchain experience are in red-hot demand right now. Some of the guys on this team could probably make a quarter million USD a year working for a bank.
The following is just the opinion of a non-expert.
I admit that it is not possible for me to accurately estimate the value of the deliverables they will be working on, so I can’t say if what they are asking for is too much or the right thing. From the little I know about the project, I would say that since they will be building tools that will attract more developers to develop tools based on the NEM blockchain, that will benefit NEM greatly in the long term (assuming everything that is described in the proposal is delivered and works as expected). In fact, I would say NEM needs something like this to be able to compete better with the likes of ethereum.
As long as:
The core developers and the majority of the comunity members agree that the work described in the proposal will add value to the NEM ecosystem in the long term.
There are (selected?) community experts that are willing to review the work done at the end of each milesone and confirming that value was added to the project. I would like for core developers to be somehow engaged in this process, but I don’t know if it will be (always) possible since I think they are very busy with NEM development.
I would say the project sounds like a good idea to me.
After having read the proposal and all messages in the forum, I want to share my personal opinion.
I really appreciate the effort put in this proposal. I find it really positive and a great initiative.
However I have some questions and remarks that I hope you find answer worthy
On the proposal itself, it seems to be very broad and covering very different items, which doesn’t match the agile approach that would be taken in the development of
this proposal. As mentioned by other a split proposal might make sense. What’s your opinion on that?
Is DSL really a correct name? From what I understand it is a library, not a language. I understood nem-library would handle all lower level interactions with the NEM
network, and what you call the dsl would be a higher level library. Is that it? A good library is more needed than a Domain Specific Language I think.
What is the real reusability of the proposed view components? Wouldn’t it be better to make it super easy for devs to build their own views? Without being a front-en
d developer, I’m afraid everyone would end up developing their own widgets. For example, you don’t see login widgets in web development frameworks, because everyone wa
nts to present it their own way. What exists is frameworks to facilitate the login management in a web app (eg devise for rails).
I find the proxy an important component, but there was a question raised about redundancy the catapult components. And this highlightens the problem of the development of catapult behind closed doors. As developers are very secretive, do you expect to get information from the core team? I would hope for the core team to be more op
en as this would benefit NEM, but can we reasonably hope that will happen?
testrpc is a really good idea, but isn’t it a nightmare to maintain? Would it benefit from reuse of code from NIS/catapult?
in the platforms, electron is mentioned, but I don’t see where it fits in the proposal
covering Apostile could be interesting (more than views for example in my opinion)
you mention Mijin integration. Is it relevant for NEM funds to finance Mijin integration? Wouldn’t TechBureau be more indicated to support such an initiative?
You mention it will be a full-time work. Does that mean that the funds will keep your company afloat during the development of this? But on the other hand you also talk about the alertry product, so you also have other endeavors and work on nem-library will not be full-time?
What is the legal framework of this? Are you invocing the NEM foundation? Or is it an investment from the NEM foundation?
will the funds be used to build a team of developers? How do you plan to grow it? Do you expect your work on the framework to generate some revenue? Some sort of a business plan regarding the funds you would receive would be helpful.
You have proven that you are capable of building solutions on NEM. iCorrect me if I’m wrong, but most of them I see as Proof of Concepts, and not products that are marketed and finalised. Will it be different in this case? It is crucial that what is develivered is a solid, usable library, and not a proof of concept. Delivering the
nem framework might not be the hardest part for a talented team as yours.
You talk about some marketing initiative, but I didn’t see anything about building a community around the initiative. Did you think about that?
A (irrealistic?) desire for a cross-language approach, which I share, was mentioned in the thread. I never used it myself but could Haxe be of any help here?
Overall, I am thrilled by this proposal. It shows a vibrant community and I agree with @xpedite that we should support such initiatives.
I’m afraid rejecting such an initiative might be damaging for NEM on the long term. And the risk for NEM is limited as payments are done after milestone completion.
I think it still can be improved though by emphasizing some elements, and dropping others. A split proposal might make it unnecessarily complex, but a dicussion focused on this point might help.
Also the secretive approach of the Catapult development makes it hard to assess long term viability of the library to be built and the expected effort required to port it to catapult.
Exactly what I wanted to say. 70k yearly rate (cost) of crypto developer is compete joke.
People like this cost more like 200k a year (not what they earn, but what their company would charge us/client )
Following this and while I personally think of it as a good idea, even better one is really splitting down the proposal. I am aware that the team proposed budgeting by milestone but i don’t think it’s a good idea to accept the whole 2 year plan in advance.
As mentioned, Catapult is unknown factor in this project, and we still don’t know if anyone really knows where and if they overlap.
You are missing the point. I am challenging the numbers because there is a lack of transparency in that regard. I stated on telegram that I would like to see a cost rundown. Maybe the numbers actually make sense?
Secondly, do not get stuck on the numbers. The main question that has been raised multiple times is: Does it not make more sense to focus on the must haves now before we decide what the nice to haves could be?
I simply do not like the idea that we must buy a pimped out car now (7 milestones with uncertain features) just because we need the base model (2 milestones with must have features) to get us to our destination.
Well isn’t actually as easy as that… Simply take all 7 milestones and start with the 2 most important once. The payout will be in phases anyway and by the time these two are down we’ll for sure see some kind of catapult update / Beta release / etc. By then the milestones could be reviewed and amended… Or something like that.
Still waiting for core developers to chime in. I agree it can be made into a smaller project and then other phases can be voted on. However it will slow down the process. Can you propose a smaller but useful project on its own that can be completed within a couple of months? Then the NEM catapult will be released and then we can assess any remaining proposals after that.
We have been a little bit busy this last couple of days discussing how to move forward so please take these answers with a grain of salt.
Please let me reply inline:
We are thinking about it, we would like to be as agile as possible although at the same time we would like to have the resources and path to move forward with a clear aim.
The DSL is a layer on top of the Library that would organize the different functions depending on how they will be used by their domain.
The main reason for the view components is to offer an standarized (easy to use) set of views that will help any developer get bootstrapped fast if they don’t require customized templates. Think of oauth login popups for example. In the future we would like to try to add an extra layer of security trying to separate the password and therefore the keys from the rest of the system.
Core devs are working hard and they have their reasons to do it this way. For instance, constant community support requires a lot of time. However, I don’t think it can be completely overlapping since even with a complete rewrite the client and the server will always be separate entities.
TestRPC would be based on the Proxy, it is intended to mock the Blockchain.
Some of the languages mentioned are merely examples of the platforms that could easily use the framework.
It is our opinion that Mijin is one of the most important components that NEM offers. Very few chains allow easy private-public interaction. Why would you not want to improve interaction between both?
It is our understanding that the Community Fund is not intended to be as open as you are requiring (as the guidelines say). We have been completely transparent and intend to keep doing it, but you have to understand that it is not the same to be doing bounties than to aim to build and bring to market a project this size.
However we would like to announce that this proposal is on hold for the time being since the best path forward is being discussed with the core developers.
We appretiate your attention and implication on the process and are happy to see that NEM has such a strong community.
I hope the issues are worked out and this goes forward soon. I’m very much looking forward to it and I feel the NEM blockchain would benefit greatly with a standardized framework for creating applications.
Hello everyone out there.
wanted to say a lot of thanks as reading through this thread I found a lot of very useful information for me. my wife got me out of house because i don’t take cialis anymore and i have to learn this in order to make money would you people mind if i am going to ask some questions that may or may not be already asked here? thanks!!