I know. It was not a serious suggestion. Only BIGGER.
Some personal thoughts.
- Web UI needs improvement on several points. IDK and Iām not the person that should suggest for a little makeup or a rework. Itās a task for the dev team. But itās needed. Period.
- IMVHO itās interest of the adopters donate to the project.
For the family firewall, obviously might be a bit overkill, however a conscious adopter could donate the value of a meal (one over 730 par year, assuming to meals by day); could be a nice āthanksā to the developers.
As companies, products mostly require maintenance fees (which are not support), and a payed product is faster and more careful when itās time to release updates starting from security one.
Good software is a value. - For the persons who reported that paying gives power over the project. IMVHO it depends from several factors.
I donāt think that users actually have power on some big IT players, itās different when itās about customers, but mostly customers have only one move for steer things: quit. Sometimes the change happens, mostly doesnāt, unless is a hefty enough portion.
However I donāt see many reasons for the team to give to other entities the control of the project. Sometimes better listening to feedback could be useful, however the value of this project is also due to the control the team exerted.
Last but not least. I play with power, sometimes. Iām no trained or professional, however some vocabulary, concepts, doās and donāts are familiar to me. And Iām not even thinking to call ABB and ask for rename labels or re-symbolize their circuit breakers, residual brakers, fuse sockets. Theyāre too polite to answer me that Iām a moron for asking that.
IPFire donāt want to become a consumer-grade router firmware, you can ask OpenWRT for that (sort of), and anyway, if routing, firewalling or (mostly) network control is the goal, people should take time, energy, patience and good will to become āstupidā and learn the basics.
It took me something like 10 years to āunderstandingā the meaning of subnetting. I used blindly the usual 255.255.255.0 subnet mask which worked like a charm every time, but I did not know why. Then i got it, and routing become so less confusingā¦
Anyway: in my opinion the Web GUI revamp is still a wonderful idea.
Hi
I agree with @pike_it so the aim of this post is to add to his comments.
Yes. The examples that I and others have highlighted are a sample of things that need fixing. I note that no-one is calling for a major rewrite. Just fix long-standing issues.
Patreon is proof that people will voluntarily pay real money for a good product without any expectation of taking control of the product or the developers . In saying that, it is my observation that successful Patreon projects have adopted customer led development. Something that is absent from the ipFire project.
When I was managing power station construction projects, I got to go to Palm springs, USA to attend developer sponsored (General Electric) user conferences. Over 2000 users were able to provide direct feedback to senior GE management and interact with other users to share experiences, knowledge and problems. These conferences were expensive for everyone, but considered good value. Unfortunately a tiny project like ipFire canāt run a conference anywhere, but something equivalent and scaled down could be achieved on-line at little cost or effort.
One of the problems I, and others, had with GE was that questions from customers during construction got lost within GE. They had no method of tracking them and no-one was responsible for ensuring questions were answered. As a result of interaction with other GE customers, I knew this would be a problem with my project, so I set up a system to track GE actions. I had weekly meetings with GE where I asked for an update on questions I was tracking. To their on-going embarrassment GE was seldom able to report progress. As a direct result of my feedback GE introduced a customer issue tracking system. Without relinquishing any control, GE implemented a change led by customer feedback. This benefited all GE customers. It is a typical example of customer-led development.
Before Pike mentioned he is in power, I had planned to use this YT video of the South Sea Bubble as an example of customer-led development. Just listen to the first 60 seconds of the video to hear their explanation of how these YouTube content developers came produce a video on a topic they thought was a boring. These developers actively sought feedback from paying Patreon users that led to the production of a video on the topic of historical finance and economics. This channel has over 3m subscribers, this video has over 3m views and over 2,000 comments on a topic the developers thought no one would watch.
In my day job, I sit on a board that exists to review user requirements. Whether developers are part of a multi-national company, or a tiny, but popular YT channel, customer led development works. ipFire needs a simple system to capture user feedback and requirements.
To be clear ipFire is already a good product. If it wasnāt, I wouldnāt be using it or writing this. I believe one of the key features of ipFire is that someone with a less than basic understanding of networks can successfully use ipFire. As they learn stuff, ipFire allows them to apply their growing knowledge. They may even venture onto the CLI. The advanced user can do what they want without limits. If a user has a problem, there is expert help available on the Community Forum.
As a user, my feedback is this:
The WUI needs (re)development effort. To do this the project needs to recruit a website developer and (ideally) a industrial graphic designer. Unfortunately I donāt have those skills, or know anyone that would work for free on an open source project. Chances are someone will know someone, but I have not seen any effort by the Project to recruit.
The ipFire project needs to shift to user-led development. To achieve that requires a system to gather user requirements and feedback. Something that is missing from ipFire at present. Customer-led development does not take away any control or ownership of ipFire from the developers. It leads to the efficient use of scarce resources to truly meet actual user requirements rather than what the developers think users want. User-led development will make ipFire more attractive to prospective and current users.
The ipFire project is resource starved. It needs a source of income to expand. Money can be transformed into any sort of resource. Patreon could be a solution but is not the only one.
So long as the users want an internet firewall, I donāt mind what else is achievable after that.
@dazz - So letās turn words into action. Please gather your list of five (5) WUI items that are long standing issues.
Others may chime-in and add their 2 cents (and their items). @dazz - you gather the items and then take all of the items and prioritize them.
Since you may end up with a list of more items, keep it to yourself (for now). Only publish the top 5. And yes, for now, ignore the rest (keep it to yourself).
You have the needed skills and the passion!
The only Dev requirements I add is:
- WebGUI only and
- no major rewrites and
- Publish the top five (5) items only!! No exceptions!
@dazz - will you accept the challenge?
Yes, action is required.
I can create a ToDo list, but it is likely to be different to a ToDo list created by any other ipFire user. This should be at least a 4 step process:
-
Someone (any registered ipFire user who can log-on to the ipFire website) proposes a change including benefits. There should be no limits on the quantity, scope or development effort.
-
All registered users have an opportunity to vote on proposed changes.
-
The Developers estimate the cost (developer hours) of each proposal.
-
The Developers plan, schedule allocate resources and then complete the top scoring change proposal.
The Developers will not be able to allocate all resources to changes. Resources will still need to be expended on routine maintenance, admin type work and other essential, but unexciting, work behind the scenes.
Scoring to rank proposals can be a multi-factor combination of:
User Votes
4 - 80% to 100%
3 - 50% to 79%
2 - 20% to 49%
1 - 0% to 19%
Benefits
4 - All users, major improvements for security / usability / functionality (not the same as adding features)
3 - Most users, significant improvements for security / usability / functionality
2 - Some users, some improvements for security / usability / functionality
1 - Outlier users, specific use-case for some change that cannot be reasonably achieved by a work-around.
Priority
4 - Must have
3 - Should have
2 - Could have
1 - Must not have
Resources (Cost)
Measured in Developer hours:
4 - Less than 8 hours (1 day)
3 - Less than 40 hours (1 week)
2 - Less than 160 hours (1 month)
1 - Less than 1000 hours (6 months)
Given the scarcity of resources, this factor may need a weighted score (eg. 2x)
Initial investigation indicates this proposal tracking voting and scoring could be done on a on-line spreadsheet that is part of the Wiki or Community website. Such a spreadsheet would be accessible to every user with a log-in. No single person (including me) should decide what can/canāt be proposed as a change.
It is my experience that user groups exist to improve something, not change it into something it isnāt. ipFire users can expect users to propose changes to make a better firewall and not something else.
All of the above might be just too much for ipFire, so a crawl/walk/run approach would be appropriate. A start could be made with a simplified version which is then scaled as required.
Developer Buy-in
I did a little digging around and it appears that ipFire may have had elements of user-led development in the past.
Monthly Video Conference
I found minutes of monthly on-line meetings here: Monthly Conference Records This is good stuff. I read a random sample of the minutes. As far as I can tell, this is attended by Developers only, but there does not appear to be any restriction on who can attend.
I found a item titled āCommunity Suggestionā and also āAddon Removalsā (8 Jan 2024). So the developers do pay attention to the Community. My scan of a sample of meeting records found nothing that concerns me. What I didnāt see was explicit input from users, and I could not determine if any of the attendees were there to represent users. Noting that a lot of the recorded topics/work would effectively be invisible to users. As such a user representative may not add value, or be relevant, to the monthly meetings.
I found this statement 4 December 2023:
Blockquote Feature Requests
On that note, a lot of recent update changes take place under the hood, not being very visible to IPFire users. We should strive at also fixing the small things in the WebUI that make userās life easier.
So the Developers have recognised the WUI needs fixing well before this thread was started. That is good. What I have not found (or looked for) is a way for users to submit proposals for changes to the WUI.
What to do?
Given that the developers have already discussed the need to fix bits of the WUI, I could create a simple spreadsheet of change proposals and post it onto a new thread. I will add any proposal from any user and repost the updated spreadsheet. It is basic, almost crude, but should provide the Developers with a list of fixes that users have identified.
Nothing will happen with this unless the Developers fully buy into all of this.
Other Actions
That would still leave other things that need actioning. Recruiting more developers being one of them. One option might be to approach a University teaching computer science or similar. One of my Professors used to set assignments to write code for a in-Taxi terminal he was working on. An open source project like ipFire would provide tutors with a real world example they can use to write student assignments. I am on the wrong side of the planet to organise that. Again, any such effort would require buy-in from the Developers.
@dazz: Nice article about a way to enhance development in an open source project.
But the topic of this thread should be the enhancements of the WUI, I think.
Organisation can be done, if we know the amount of the work.
So, I repeat @jonās request for your ( and other users ) top 5 proposals.
BTW: IPFire isnāt a commercial product and isnāt applied by customers but users. Each user is invited to support development, either by coding or consulting. For advises to other users I would recommend the wiki. Each user can edit it and it is revised by experienced members of the community.
Regards,
Bernhard
This thread is focussing on how to make a table listing all the WUI improvements that users would like to have.
It is not considering at all that the project resource level is insufficient currently to deal with everything that needs to be dealt with.
IPFire infrastructure is a key thing that has to be maintained whatever as if that breaks then no releases can be done, no emails sent, no blog reports issued, no forum workingā¦
Then there is the work on IPFire-3.x that has made definite progress during 2023 and the team are fired up to continue doing that in 2024.
IPFire-3.x addresses long standing issues about IPFire-2.x such as that it is limited to 4 zones, cannot deal with more than 1 VLAN per NIC, cannot deal with IPv6, cannot do things such as bonding of interfaces, cannot do WAN failover with DHCP connections.
Then there is any work required on IPFire-2.x due to the identification of security issues that need to be addressed. These usually need core developer resources to be able to deal with them.
Then there are all the IPFire bugs that are in the IPFire Bugzilla. These are usually issues that have been raised where IPFire is not functioning as it should under certain conditions. Some of these can be addressed by inexperienced people such as myself, others require the skils of the core devs.
If you look at the bugzilla you would see that bugs are worked on and dealt with but at a slower rate than new ones are raised.
Volunteers from the IPFire users need to come forward to actively support with bug fixes but also to support those WUI improvements mentioned.
If we just create a table of things people would like then there wonāt be enough resources to deal with them. If resources are assigned to them then it means that either functional bugs will get fixed even slower or the resource focussed on IPFire-3.x would have to be reduced again, which I donāt believe will happen because of the progress made during 2023.
@dazz -
As I mentioned in post #21 your feedback is right on for the corporate environment BUT the volunteer world is different. I came from a similar corporate world and I appreciate your thoughts and your passion.
From reading your post #46 I am not sure if you wished to accept my challenge to turn words into actions.
The challenge has some simple guardrails to help keep it away from a major re-write / effort. That is all happening with a future version Adolf mentioned.
@dazz - will you accept the challenge?
What does it do, how well does it do it? The more complexity that is added in what ever area of the project, the more there is to cause unintended errors. I like the simplicity of the UI, thereās not much to allow misconfiguration, and if I need to fondle the bits I use the CLI.
Iām glad I read this thread, Iām now aware of bugzilla for the project.
Iām going through the code because I like to know how things work, especially if Iām depending on something to provide some semblance of security and peace of mind.
Iād rather focus on how well the project serves its intended purpose than a UI full of bling.
This is a new aspect of āusabilityā. Yes, misconfiguration is not so easily possible. But this means there is much code to check this behind, you will see if you read the code.
From this aspect let me pose another question:
āWhere should the error checking be improved?ā ( In the WUI itself and the related documentation in the wiki )
It depends on your target audience, I know how to pop the hood and get dirty, but my family just wants the Easy Button.
I would place the āconfiguration checkingā code at the back-end that the WUI uses to provide configuration changes. Let the WUI validate user input.
Edit: I forgot to mention, the documentation needs to track the updates to the code base or there will confusion and lots of help requests.
If changes occur to the WUI then both need to be kept for a while otherwise people on an older CU will not have matching documentation. Also any changes need to seamlessly update existing configurations or work with both. Also need to consider how to update old backups so a restore from an older CU does not crash the system.
It can all be done and has been historically. It just needs to be included in any planning of what would be changed.
I agree, I just answered off the cuff, not wanting to get too deep into SOP.
Agreed.
Who will choose the top 5 on the list?? If the list is limited to only 5 items, this will not identify the amount of work.
The solution is to list, vote and score all proposals, but draw a line under the top 5.
I think the only difference between a user and a customer is the terms of payment. One is invited to make a donation, the other agrees to make payments.
It would be reasonable to assume that ipFire users have a wide range of skills but it is possible that they remain a largely untapped resource because of the emphasis by the Project on calling for developers.
Other areas that users might be able to support the project which may include:
- recruiting developers,
- WUI development (ergonmics, visual design etc)
- raising funds (eg. Paytreon, company sponsorship)
- finding a University to work with.
I think the Wiki is an example of very good quality documentation. Simple tasks should be simply done via the WUI and should not require consultation with the Wiki. For advanced topics, the Wiki is indispensable.
Agreed.
Agreed, because I only know that development is constrained by resource limitations. It is clear to me that the project would benefit from more resources.
On projects I run, the 3 fundamental priorities are:
repairs Fixing things that are broken is top priority to maintain the service to users. ipFire use Bugzilla to manage bugs. Note there is no ā5ā only limit to the number of bug reports.
maintenance Maintenance is needed to stop things breaking.
enhancements to satisfy changing user requirements is always the lowest priority (and mostly the focus of this thread). Empirically user requirements change at a rate of 2% so a product like ipFire there is always new user requirements. Development never stops. If it does, the product dies.
In practice, the allocation of resources between these fundamentals is constantly reviewed and rebalanced.
I note that this link indicates Bugzilla can be used for feature requests. My assessment is that Bugzilla is good at tracking bugs.
This is the closest I have seen to a description on the scope of ipFire 3.x. I donāt follow the ipFire forums closely at all, so it is entirely possible I have missed a mass of discussion on this so I did a search with the results including this thread.
With such an important topic justifiably absorbing much of the developers limited resources, I think it would be reasonable to dedicate a forum category just to ipFire 3.x. It could include highlights of the monthly meetings, project milestones achieved etc etc.
Another priority drain on developer resources.
As above, fixing things should be the highest priority.
It is my observation from afar, through a very small window, that the ipFire project requires more than just bug-fixers.
That is not how it should work. A healthy and popular project should expect a constant stream of bugs, maintenance and feature requests throughout the life of the project. The key to success is to prioritise the work queue to keep within the limits of available resources. This might mean that only the top 5 tasks are allocated resources, or maybe only 2.
I am undertaking a feasibility study and scoping out the work before I make any commitment. Through this thread, I am seeking out feedback ( and getting it).
Why keep it away from a major re-write ??? If you are referring to version 2.x, to avoid dragging resources away from ipFire 3.x then that is understandable. It is possible that this emphasis on limiting work may be adversely affecting the ambitions of the ipFire project.
Itās time for another story.
In 1985 I was studying my 4th and final year for an Electronics Degree. This included dividing up into teams of 2 to 5 for project. I was allocated to a project for the national Olympic cycling team. The task was to design and build a device that would measure the axial and radial forces on a bicycle pedal, and wirelessly transmit the data, in real time, to be monitored and recorded by the coaches in the centre of the velodrome.
In 2024, you can buy such a system off the shelf and fit it to your bicycle. In 1985, it was bleeding edge technology, and I believe it was a world first. Clearly the Cycling team didnāt have the capability or the resources to undertake such a project so they teamed up with the University. The project was sponsored and funded by a private company.
Moving forward to 2024 and ipFire. I am looking at the emergence of what the marketing departments call AI, and I call Machine Learning (ML). I am thinking that ML is a technology that has great potential for application to firewalls. An open source project like ipFire would be an ideal test bed for ML. I am confident there will be Universities teaching computer science the theory of ML to students. There is a good chance those courses will include a practical element in the form of a project. An alliance between ipFire and a University could be a win-win. Here is an opportunity for ipFire to jump ahead of the competition.
Such an opportunity will not come to ipFire. It will require identifying and lobbying suitable Universities, growing relationships and selling a concept.
I will create a simple prototype, as previously described, for review and feedback.
Agreed. simple things should be simple to do through the WUI but currently not always true.
In the āSystemā menu, there is a āDialupā item. Has anyone reading this under 25 years of age seen a modem, or dialed up an ISP?? The box on my wall is called an āOptical Network Terminalā. No mention of a modem and I definitely donāt dial up anything.
When I click on āDialupā the first line is āPPP Setupā. That is what it is, but what does it do? It is a āInternet Connection Setupā page.
Improving usability can be achieved by making things simple to understand, to make simple tasks simple to do.
Yes, me too.
If you look at what I am proposing, it is definitely not bling.
Why? Exactly what things? In what relevant context? Yours or IPfireās?
I find Adolf Belkaās comment about infrastructure being the key and 3.x otherwise the focus to be dead right. I have also some experience of bugzilla being used for enhancements as well as ābugsā. It works well in small projects with involved users.
Yes, prioritisation of some WUI improvements could be useful, maybe transferrable to 3.x, so offer some WUI proposals. Far too much space is being taken by words.
@dazz - My simple requirements are in the above post #45.
In my opinion, based on your comments in post #56, I believe you are making a mountain out of a molehill. Something simple has turned into a project with feasibility studies and analysis.
Again, Iāll reiterate: what you are doing is perfect for a large corporation. And for that environment I can agree with your passions to do it the right way.
OBJECTION! Sorry⦠too much Ace Attorney gameplay.
All arguments I read ācounteringā an approach change are to⦠ākeep things as they areā.
-Developers number.
-Project path
-project behavior (sort of)
-funding model
Might be or not the ācorrect wayā keep the things as they are.
However, not so small number of persons in this community are asking for some changes. And when provided some sorts of meters for understand whatās asked for changing, focus is kept on "one user that should fullfill a 5 point list?
IMVHO thatās pointless, that could be a unmeaningful 5 point list.
So, why not start with a poll? Discourse should thave this feature.
1 topic, 7 days, for provide a point for every post (not user). Notification via email 3 days before the poll start
Then, some days for consolidate, group, summarize proposals, discarding duplicates.
Than create a 20 points (or less) poll, 3 choices available for voting. Same notification 2 days before, poll lasting only three days (tue to thur my pick).
This will deliver (IMO) a better community drive ātop 5 improvementsā for the GUI.
Then 14 days for assessment by developers about feasability and supposed time spent for these 5 points.
Three possibles outcome for every point:
- Developers would take charge for the improvement with a supposed ETA (not binding)
- Developers would take charge for the improvement, but the budget time exceeds the current availability, so they could provide to any volonteer the āwaypointsā to implement the improvement
- The improvement, due to structure of the core or he interface is too impacting/not viable/need big enough rework to consider that change impossible, on this occurence
All this should need the most important thing: willing to listend and consider the requests of the community from develoment team.
People could provide āsomethingā to Ipfire, but⦠these ways currently are donations, bugfix, testing time before the release (then bug collecting)
And sometimes⦠for fixing the bug knowledge of the code of the project deeply unfortunately is almost cheating, when competing to someone who donāt know an FSCK.
Well. Feedback provided. Unfortunately a lot of ācountersā feel like āwe donāt want toā.