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

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
https://github.com/aeternity/aeternity/ 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.

13 Likes

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

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

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

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

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

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

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

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

3 Likes

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?

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

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

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

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.

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

1 Like

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

1 Like

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(https://medium.com/nervosnetwork/breaking-the-throughput-limit-of-nakamoto-consensus-ccdf65fe0832) or something else, to gain better transfer experience
  4. Fine tuned token economics
1 Like

I agree, WeTrue development and Aechina.io improvements proposal 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.

7 Likes