[Rejected] Yearly funding of the maintenance of the Aeternity Core node

aeternity Foundation Grant Applications
1

Application Status

Status: New
Last updated: 18.05.2020
Submitted by: Core team
Team: Core team
Approved Budget (in h):
Used Budget (in h):
Planned Delivery: 06/2020 - 05/2021

Specify the funding category

Open Source Development

Application Title

Yearly funding of the maintenance of the Aeternity Core node.

Applicant

This application is represented by the whole Core team, see
GitHub - aeternity/aeternity: æternity blockchain - scalable blockchain for the people - smart contracts, state channels, names, tokens for details on its work.

Value Application

The Aeternity Core node is a large and complex software product, with many
diverse dependencies and support for multiple operating systems. As such, it
requires constant work to identify and fix bugs and security issues, make
releases and lots of other work which is focused on keeping the software in
shape and ready for any new feature development.

If maintenance is not done on a constant basis, the software might degrade to a
point where no feature development is possible in reasonable amounts of time or
bugs cannot be fixed due to missing knowledge within the team.

Definition of Terms

none

Status Quo

The Aeternity Establishment has so far funded minor maintenance work on a
case-by-case basis. However, for a project of that size maintenance requires a
larger, readily available budget and should not be blocked by work on features,
or prioritized lower due to budgetary reasons.

Required Work

All processes are in place. Once this application has been approved the Core
team can start work on outstanding maintenance tasks.

Estimate

Total for 1 year: 8415 h (rough equivalent to 4.125 person years)
Per month: 701.25 h

Detailed budget reports with links to work items and discussion around them will be provided monthly.

Known Limitations

Since so far there hasn’t been an approved budget for maintenance work, the
estimate may be wrong. If its too high, the budget will simply not be used. If
its too low, the estimations and application budget have to be adapted or the
scope of maintenance work needs to be limited. Either case, it requires further
discussion when that happens.

Outlook

Maintenance of a software project like this is never finished. But, it shall
lead to a more stable, bug-free software. Specifically, maintenance may also
lead to performance improvements which can certainly be disseminated further in
case that happens.

Publishment

All work shall be published under the ISC license, like the Core node code
itself.

Maintenance

Does not apply.

14 Likes
2

I only created this proposal as a first draft. Further discussion shall be led by the whole team.

cc @uwiger @dimitar.chain @hanssv.chain @QuviqThomas @karol.chain @aleksandar.chain @danielaivanova.chain @Arthur @nikitafuchs.chain @dincho.chain

3

As @botanicalcarebot.chain writes, the estimate can be discussed. I do not think that the given estimate is over the top, but if there is insufficient funding, one could e.g. discuss a level of 4 people at 70%, expecting the remainder to come from specific projects, consulting, feature development, etc. The important part is to ensure continuity for a team of at least that size.

8 Likes
4

Yes, for the past few months supporting the Core had been really hard and yes as a results - some bugs slipped in. I double that a predictable budget would help stabilizing the process.

8 Likes
5

Hopefully it will be understood that whatever is Aeternity building - unless there’s a huge risk in strategy - ultimately depends on Core functioning as issues-free as possible.

Every issue not sorted out on Core level directly projects to applications either not working, or at minimum, degraded user experience.

4 Likes
6

Maintenance of a software project, generally, is very important and everything depends on that. The Aeternity node is very complex software product which requires constant work. Maintenance requires readily available budget which will help all the development process and avoid future problems.

Hopefully everybody understand that the maintenance on core level is very important.

6 Likes
7

I definitely agree that budget based software maintenance is a way to go. And most of us are seeing the accumulated technical debt already.

3 Likes
8

I definitely agree with everybody here, and again the maintenance of the core project - in my opinion should always be continued.

3 Likes
9

The importance of the core level is clear, but how do we keep this software out of bugs? Looking in the open issues there is a long list to be fixed. If we take only the bugs there how many hour per developer we need? How many hours maintenance were in 2019 provided? What is to be fixed in the first month?

10

That is what constant maintenance is for. Continuous testing and keeping components in shape prevents bugs.

That cannot be estimated or at least I don’t think it can. The team has changed drastically over the last year and many of the issues in there concern parts of the system which haven’t been touched in a long time, thus cannot be estimated.

I don’t remember there being a dedicated maintenance budget since what is considered maintenance work was part of the active development which was done last year. Considering 50% of a developer’s work is maintenance maybe this can be calculated, but these numbers must be provided by @Ingmarwatermark.chain or @Tina .

This is a group decision and the group won’t start prioritization until a budget is available, since that alone is plenty of work. I would expect any items marked as technical dept are good to start with.

5 Likes
11

I think that a plan is the first we need now in order to solve the issues. Maintenance does not involve new features and only fixes the bugs in the running software. We need to know what will be done and by whom in that timeline. What do we plan first and want to achieve in 1, 2 months and one year. Otherwise we can not estimate and run out of the proposed budget. Monthly reports are mandatory for the achieved milestones.

3 Likes
12

I don’t think the proposed approach has been understood. This is not a proposal to develop new features. A lot of maintenance work is actually testing work to identify bugs before they are being seen in production. We can now make a work plan and priorities up, which will change after 1 week once maintenance work has commenced since the Core team might re-prioritize issues. But if the foundation wants to stick to whatever work plan is proposed, this is a no go.

From my perspective the Foundation needs to position itself on whether it (1) feels itself responsible for funding Core maintenance (as stated on the website) and (2) trusts Core developers to make the right decision as a group on what maintenance work to do with a given budget.

If 1 is true, but 2 is not the case and a general budget without detailed work plan cannot be funded, then the Foundation should start managing and prioritizing the maintenance work and not rely on Core developers to do that work for it.
If 1 is false, well then this proposal is obsolete.
If 1 and 2 are true, no work plan should be needed.

4 Likes
13

This type of work is not specific to AE and applies to every other project of comparable significance. So the work needs to be done, one way or another. The suggestion empovers the core team which would send a sound signal to the community, with a firm commitment.

1 Like
14

对于这种事情，社区必须说“NO”！原因是:①现在目前上所有的项目的节点都是社区维护，而非官方团队！②并不是所有的工作都需要团队去提供资金，团队从旷工抽水AE，将AE token提供给开发者，开发者再讲AE token在交易所换成美金，这是一个恶性循环的结果。③到目前为止，使用AE 主网的应用并不是很多，以后应该也不会很多，不需要建立稳定的专业节点，现在的节点已经可以使用！④根据论坛上的反馈，中国社区的WETURE申请资金很难，而如果这个维护节点的行为都申请下资金使用，给社区的印象会变成AE社区已经成为团队的提款机了。基于以上四点，我个人的意思是，不赞同这种行为。

1 Like
15

I am new to this community. So perhaps my opinion might not be clear.

But I have been doing estimations and working on projects with large number of developers for past few years.
Keeping the fresh budget for this year aside for one minute lets breakdown the problem.

Problem for devs:

For bugs estimating the hours to solve is not straight forward .
As some bugs you would know how to solve it straight forward,
some might be consequence of something else breaking .
So estimating them accurately is not possible.

@botanicalcarebot.chain please correct if my assumption is wrong .

Problem for Foundation/Business

Until a firm number of man hours as been assigned per issue on the github they wont see the transparency in how we are calculating the 8415 h and hence assigning funds becomes bit difficult.

Possible solution

There are 104 issues are open. Out of which when i filter by kind/bug I see 61.
What can be done perhaps first esitmate the critical ones from these , and share a possible man hours estimation.

This will give confidence to @lydia to push it forward as lot of the critical issue gets fixed .

Then I see the other cards are mostly new features or work. might have come from community member asking for integration etc. So those rest of the card be this year’s estimate as proposed by @botanicalcarebot.chain and the core team.

Guys please do not think me as I m trying to get into others business this is just a suggestion . I agree with both side here actually.

and I am glad for software which is this large only 61 issues are critical so kudos to the core team. And @lydia I think they are right about fund allocation for future work because rest 40% work is new features

2 Likes
16

I’m very appreciate aeternity’s Core team, and there are some suggestions to the Core team:

  1. Fork aeternity and start a new coin with lower dev fee like 10%
  2. Integrate riak, make riak BFT to compete with IPFS
  3. Replace Bitcoin-NG with NC-Max(Breaking the Throughput Limit of Nakamoto Consensus | by Jane Wu | Nervos Network | Medium) or something else, to gain better transfer experience
  4. Fine tuned token economics
1 Like
17

I agree, [Completed] WeTrue development and Aechina.io improvements proposal - #14 by Tina should be handled faster. 14d without feedback (even negative one) is not productive for sure.

From my PoV any opinion is welcome. This is an open proposal after all.

Certainly interesting to consider and further talk about. But since it is outside of this topic I won’t go into it. Maybe worth creating a separate discussion for this.

8 Likes
18

I am definitively in favor of the core team having funds to maintain the code of the base node, and to focus those funds specifically to solve bugfixes.

I would really like to see a set of funds dedicated to new features and improvements, and to be able to prioritize all this by staking your ae into the problem you want to solve. Something like being able to stake your coins on the feature or improvement that you think is the most valuable for you right now, so the features and improvement selection is community driven instead of unillateraly chosen.

— EDIT —

I remember we used a crude software to track issues and features back in 2003 that had an associated value to the resolution of a task. This value was given with a not too complex but comprehensive equation that considered age of the task, project priority (some features are needed as foundation for others to be implemented), position in the feature/bug list, perceived priority by the users, complexity, required time to code, required time to test, dependencies and affected modules/areas.

The main principle was that any developer could look at the list, pick a task and work on it, once done you submit the code, it gets incorporated and tested, and the developer gets awarded the value of that task.

After a maturity level on the tast, or by peer review, if the code seems adequeate, did not break anything and is working consistently, the developer can claim the money.

This was done so the developer that solved the most urgent/important/complex problems would get paid the most while developers that were not trying to solve issues but only wanted to test things could do so ad ease taking several tasks at a time and getting a proportionate pay too.

This was so long ago and I have not used that manager anymore (it was inhouse and I didn’t care enough to keep a copy of it) but it sounds like maybe there is someting like this today that works for this sort of projects?

The burden of this method was that the definitions of the interfaces and the testing of a solution had to be perfectly defined before accepting a finished work, so unit tests and interfaces were a must, normally everyone participated in deciding the tests and interfaces, cause different people in the team had different ideas of what was needed for each step and this ensured a reduction of erros defining tests/interfaces.

5 Likes
19

I like this proposal :+1:

3 Likes
20

Dear All, thank you very much for the discussion. In this general form the application is rejected.

The core developers need to make a priority list of the bugs/issues on which the work will progress and to update the documentation.

@botanicalcarebot.chain please submit a monthly grant application on what will be worked on, by whom and for how many hours.

So the community can see on the monthly basis how the bug list is decreasing and what needs to be done next month. The goal is in three months to have most of the bugs removed.

3 Likes