Correct.
But: How good will be the docs, i.e. for usage of ubus and procd on openwrt, in case not provided by an author ?
Way to twist my words...
I am not an OpenWRT developer, but there is a limit to how much time/effort I would/can put towards a hobby. How much free effort would you commit to?
UPDATE: How much $$ have you contributed/paid for this software? Nothing is free, so you end up paying for it with something else than $$. Like your time and effort.
1 Like
I appreciate this statement. As it confirms increasing "Risks to the Public" . Anyway, you had a good idea, too: Some type of commercial offerings. Like "to-be-payed-for" docs.
What exactly are you referring to with that?
I think this was a reference to the case when a free project becomes too popular and too much burden on the author for no monetary benefit.
I.e. if LuCI is super user friendly, then more people would be using it, more inexperienced users will get on board, more support for no monetary benefit.
1 Like
That will not work as it is too easy to abuse: several people pitch in and then publish the docs.
Would that be abuse? In the end the author will have gotten paid. Is it reasonable to expect a "rent" instead of a one-time payout? Sure current copy-right espouses the "rent" concept, but in the context of abuse I consider normal fairness concepts more relevant than the "law".
I think something that cannot be easily copied/replicated (like a router as a piece of hw) is way better. Otherwise we are all just subsidizing the consumer router manufacturers even though we are not using their software.
But I have no say in the matter.
I guess I lost track of the actual argument here....
I thought that the proposal was to charge for documentation? Not sure who was supposed to write the documents though...
Only someone who gets a financial insentive to do so 
1 Like
There was/is on ACM a series of reports regarding "Risks to the Public" because of software issues. Which are more likely to occure in case of software, developed as a hobby. In contrast to
serious software development, which is some type of engineering, or handicraft, nowadays, which usually needs some preps before to start (specs) and some work after completion (docs).
Which should be the author(s), of course. As a famous example, I already mentioned the almost hidden activities of procd, or ubus, on openwrt, behind the curtains.
Who is able to document the (intended) functionality, or usage, besides the author(s) ?
...and there's little to no interest changing that policy so in that regard you probably need to look elsewhere which probably makes people turn away from the project when whatever fix/change they need is applied as many finds working with undocumented software frustrating. The image generation process is also more or less completely undocumented and while this (https://github.com/openwrt/openwrt/pull/1813) works I have no idea if it's 100% correct.
1 Like
Could be, but I am not sure that all commercial software is actually developed in the proposed structural engineering way.
That seems to ignore that in proprietary software project one mostly encounters (potentially stripped) executables (or scrambled code for interpreted languages) so documentation is literally the only way to understand the program, while for ubus, you have access to the full repository including commit messages. Sure that is not as convenient and structured as proper documentation and or a specification* but it certainly puts a dent into the "Risks to the Public" qualification, at least in my opinion.
Sure, anybody but me 
Again, if you can read code there is nothing really hidden as you have access to source and development history.
I am not sure whether big software companies make their developers/coder write the documentation, at least not without help from documentation editors. Have you tried offering editorial help to the authors, or even to write ubus documentation yourself and just quizz the developers for all questions you might have? In FOSS if you have an itch, you better scratch it yourself, or be prepared to pay somebody to do it for you
3 Likes
Nicely said
2 Likes
So we are back to the "payed-for-docs". Which would be OK for me, as it might also help to increase software quality.
I understand, that software packages like apache, nginx etc. most likely have good docs because of quite a few paying users. May be, something similar possible for openwrt, too.
BTW: In the good old times, sometimes comments, extracted from the source code (read: from the author), were used as basic docs. As it was good practice, to have input/output/functionality to be included as comments, in top of the source file. Seems to be old, forgotten tradition
Well, that was one of two alternatives. The other was start writing the documentation yourself (I assume it would be much easier to get the ubus developers to comment upon a well written piece of documentation compared to expecting them to write that from scratch first).
Now, a quick googling revealed https://openwrt.org/docs/techref/ubus which at least looks like a decent starting point for more extensive documentation...
The projects also have, as far as I can tell, money to pay full time developers who can live from their project work. I am not sure whether anybody directly get full time employment for open/free OpenWrt development.
That certainly helps, it also makes the the source is the documentation argument, that is brought up occasionally a bit stronger.
This is cargo culting at best. OpenWrt isn't Windows XP.
5 Likes
The wiki is written by volunteers already. It's not like there is anyone paying me for my role.
2 Likes
It's always been a question of "payment", but never a question of "money"...
Have a look at Maslow's Hierarchy of Needs. Most OSS developers have the bottom layers on that pyramid all covered, they are not here because they need money to cover their basic needs.
Most OSS developers are here because they are seeking completion for the upper layers of that pyramid. They already have a paying job, but it does not fulfills them.
You can try to support developers who are willing to do a task, but no money will convince developers into a task they do not want to do. Paying for something puts pressure on the person who receives it, and that is the last thing developers want.
3 Likes