@patmast3r’s last point is probably meant to be “NEM Health Report”.
thx, corrected 
Thanks for the explanation. Is the transaction through the proxy synchronous or asynchronous e.g. does the proxy wait for blockchain confirmation before signalling commit to the client?
@patmast3r Thanks for your input.
After reading some more of the docs, really appreciate the effort put into the proposal, and understand a little more of their intention. This is not some fly-by-night team who slapped together an idea overnight.
While I’m onboard, also feel the price is somewhat high.
Seems though this whole process is lacking in terms of negotiation. As a community we can only vote yes/no, which doesnt leave any room for dialogue in coming to an agreement.
What if we agree with the whole proposal but feel it’s only worth 10million XEM or a flat $2million USD? or we don’t like the DSL component but everything else. Not quite sure if each of the milestones are dependent on each other or do they stand alone, which would allow breaking the milestones into separate proposals with separate budgets and voting on each one. Just thinking out loud …
2 Likes
Would it be possible to use some of the silver coins funds also for community projects like this one?
I am no technical person, but the price tag for this project is surely quite high. I would appreciate to split the proposal for different pieces rather than one large project.
NEM-Library
A lot of people has shared their concern about NEM-Library component, and we want to address more information about it.
NEM Library is the first layer of the whole NEM Framework. So, it must ensure the next characteristics:
-
Standardized Contracts: Guaranteeing interoperability and harmonization of data models.
-
Loose Coupling: Reducing the degree of component coupling fosters.
-
Abstraction: Increasing long-term consistency of interoperability and allowing underlying components to evolve independently.
-
Reusability: Enabling high-level interoperability between services and potential component consumers.
-
Stateless: Increasing availability and scalability of components allowing them to interoperate more frequent and reliable.
-
Composability: For components to be effectively composable they must be interoperable.
All characteristics are important, but I want to focus in one in order to explain a huge benefit of Composability and the relationship with NEM Authenticator.
NEM Authenticator is a site-project that we have already start sharing with some beta testers (view forum post here) with great results, but a lot is still pending to be done. A goal of NEM Authenticator is allow users keep their assets safe and use their private keys in the new emerging projects that will uses the NEM Blockchain. So, in order for new projects to use the NEM Authenticator, we need to provide them a easy-way to integrate with.
Here is where NEM Library has its importance. NEM Library is based on composability to allow developers build a module which everyone using NEM Library could import and easily use it.
So, developers could do npm install nem-auth-module, and they get a nem-library extension/module, being able to develop something like:
NEM Library Standard function → Uses nem-auth-module (specific business logic is hidden from NEM Developers) → returns NEM Library standard function.
It’s possible due the abstraction and the composability of NEM-Library.
Another benefit of creating a modular NEM-Library is the uncertainty of Catapult release, in the NEM Framework Technical Reference we added the next text:
4.5.1. Catapult
The Catapult release could imply a strong endpoints logic rewrite and more endpoints.
We intend to work closely with the core development team in order to adapt the Framework to the upcoming release, however due to the lack of information it is currently very hard to estimate how Catapult’s release may affect the roadmap.
We know, as you do, that the uncertainty in the software is high, but we expect the change and we prepare the NEM Framework to allow a fast adoption of Catapult. The main concerns are:
-
What happens if something already implemented change? Thanks to be developing in a higher abstraction, we will need to rewrite the specific logic, it could take time, but it’s needed. The software build on top of NEM Library will not notice it.
-
What happens if something is new and not implemented? We would love to add it! It could delay the roadmap, but we all want the new features, it’s not bad at all.
-
What happens if a component is not useful given a Catapult feature? The components have a long live to add more features, we will consider the replacement for the native features and view new features that could be build.
-
What happens if Catapult is modulable? We will love NEM more! And NEM Framework has that characteristic in its core.
-
So, are you using the native features always? Yes, NEM Framework is a layer on top of NEM Blockchain, to make it more easy, fast and business centric solution. We want to use the NEM native feature as much as possible.
So, NEM-Library focuses on extensibility and interoperability with itself and third party software. We have notice, as you, that developing using a blockchain requires a lot of time reading documentation to be familiar with. That implies that we will need to create/maintain the components documentation that will allow people to learn, use and extend the NEM Framework, not just the NEM-Library. Then, you will see a huge work done by NEM Framework developers documenting the whole project, the technical parts to contribute as a developer, the uses cases, samples, how to guides, etc.
Because of all reasons described above, we require to build the NEM-Library from scratch to ensure that characteristics.
We will not rewrite all the crypto features! They are already developed, and we will use it. We apply DRY as much as possible.
Finishing, it will allow us to really focus on the goal of creating a NEM Framework, which provides easy-to-use tools for NEM Blockchain to allow other industries adopt NEM as their favorite blockchain.
NEM-DSL
NEM-DSL (Domain-Specific Language) components is delivered inside the NEM-Library, and their full power is to be used together.
Meanwhile NEM-Library is created to talk with NEM-API in an abstract way, NEM-DSL is the approach to create the domain models to provide:
- Contextualization: The setting in which a word or statement appears that determines its meaning
- Domain: A bounded context, which is the NEM Blockchain.
- Models: The abstractions that describe selected aspects of a domain and can be used to solve problems related to that domain.
- Ubiquitous Language: A language structured around the domain model and used by all developers to connect the concepts with the software.
So, it creates a set of models that talks the NEM Blockchain language, it uses the type system to ensure that they are correctly applied with the NEM API contract, and it gives developers an easy way to compose domain events using a Object Oriented Paradigm.
What the DSL will do for NEM Developers is that they will start to use the same words when they talk with each other and the code expresses that concepts. So, a developer will be able to switch between NEM projects and understand the model, the structure and how to extend it. A consequence of DSL is a better codebase shared with the NEM developers.
You may notice that Domain-Specific Language is related with Domain-Driven Design (DDD) approach, we decided to put it in another point/milestone due to the characteristics that it has to provide. If you are not familiar with DSL or DDD, it could be described as we will create a set of models that share a high quality standards to ensure a shared language/knowledge of NEM Blockchain, making it easier to develop on it because the concepts shared on blogs, documentation, etc, are in the code, so the developer just has to use them and not re-learn.
The be more concise, NEM-Library and NEM-DSL will be delivered as the same component, that it will be called nem-library.
I totally agree about this part, who is doing the negotiations? In our companies, CFO checks the budget, IT guys (technicians, developers) give OK for the feasibility, managers decide on timelines and total amount of workforce needed. 3 alternative offers is a must for such large projects. Where it is not possible to get 3 alternatives an ad hoc comparison should be made with similar project on different ecosystems. Can anyone comment on what we can do here? Is there a governance structure for this, how was it handled previously?
2 Likes
Quite a long read… Great stuff you guys are offering, how does this stuff go through though?
The voting aspect? who decides whether this will pass and get the green light or what not?
I’m really happy to see this initiative !
Taking into account all the comments above I’d like to share my personal opinion.
Let me start off with the sensitive matter. 
Yes 15M XEM is a lot of money. Certainly at the current valuation of XEM.
But what if this proposal had been made two months ago?
Two months ago, 1 XEM was less than 2c$, back then 15M XEM was ten times less than now. One thing we should take into account is that Atraura is also taking a risk here. We have seen the price decline from 2798 satoshi ( June 28th, 2016) to 285 satoshi ( Jan 5th, 2017), so we know a price drop is not impossible. This is not just a dev doing this as a side project, this is an actual business that has to pay their employees.
I agree, 15M XEM is a shit load of money and it could even be worth much more by the time this project is finished. But think of it this way; good developers are a scarce resource. Good developers with blockchain knowledge even more so and I personally think that Atraura is able to deliver. Even more so, the fact that they want to dedicate their time to this instead of launching some ICO 
means something to me too.
So there are two sides to the matter. In order to make the right decision we need to assess the potential benefit of this framework for the NEM ecosystem.
We all love NEM blockchain technology and most of us (that are not here merely for the investment opportunity) are quite able to come up with concepts using the NEM building blocks (multisig, mosaics, …) as I like to call them, to solve real world problems.
Over the past months I have personally worked on some concepts and assisted other people/companies with this, but doing so, increasingly I have become aware of the fact that standardised way of doing things will be a key to success. Mind that this is not just about reducing development cost, but actually creating opportunities that reveal the true potential of the NEM blockchain.
One of the great opportunities blockchain presents is that it enables different parties/people to interact with each other without needing to trust them. But if we do not present sufficient standardisation for interactions beyond specific applications we risk to see a [functional silo syndrome] (https://en.wikipedia.org/wiki/Information_silo) that will limit the possibilities substantially.
In order to prevent this, we need to provide standardized ways of doing things on the blockchain.
Look at the success of Ethereum ERC20 tokens, people have called it the first killer app of blockchain. We might not agree, but its success demonstrates the benefit of standardization.
Even though we all see the potential of NEM blockchain technology, we shouldn’t rest on our laurels nor should we assume what we have is sufficient to get mainstream adoption.
If we provide an entire set of standards/best practices it would generate opportunities way beyond code reuse, it would enable cross app interactions on the blockchain and so much more.
In my opinion that is the main value proposition of this framework. It would become part of a good foundation upon which we can build the entire NEM ecosystem.
Sure this is only a part of what is required to achieve our goals.
Sure there might be parts of this proposal that turn out to be less beneficial than others.
Sure there will be other things that need to be added to this in the future.
But if we do not take on the challenge of solving the issues that are inhibiting real world blockchain adoption ASAP, other blockchain projects will beat us to it.
Ethereum might have critical mass, but it will have a hard time getting adopted just like Bitcoin. This gives us time to prepare, but sooner or later other projects will figure this out and come up with their own solutions.
Keeping all of this in mind, I’m pretty sure this idea evolved over time while Atraura was working on their projects. They are probably the ones with the best track record for building on NEM at this time. I must admit that I lack the technical background or experience to analyse the cost/benefit for some parts of the proposal, but overall I think it’s a great idea that will bring great benefit to the NEM ecosystem. The fact that they did their homework and are on top of all the questions gives me confidence and shows they are highly motivated. Don’t forget that it would ruin their reputation if they would fail this project
You probably noticed that I have made up my mind. After weighing all the pro’s and con’s, I believe it is best to fund initiative like this while NEM needs it the most.
But that is just my two XEM, just give it a thought
9 Likes
I agree with @patmast3r.
I think that it is necessary to vote for each proposal.
The Atraura members are wonderful engineers.
But If other wonderful ideas were born,
Members of Atraura are bound by this work More than 20 months.
It is also a loss.
I want them to do the work that seems to be necessary at that time.
I would like to vote in devided.
I decide priority, I want to vote each.
Is that possible?
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.
4 Likes
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.
6 Likes
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.
http://www.altcointoday.com/experienced-blockchain-developers-demand-big-salaries/
1 Like
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.
1 Like
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.
6 Likes
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 )
when is the voting on this proposal?
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.