Okay I’m not sure where to put this and that’s why I’m leaving it uncatorgized. Something I’ve noticed with high security systems that try to get rid of “humans” and replace them with A.I. is they often end up having horrible technical support. What I’m concerned with is in our rush to decentralize and automate functions that we don’t create something that will break and bugs and issues for both apps and the network at large won’t be speedily reported and remedied. That is keep in mind the technical support aspect. There is nothing more annoying than dialing a number and dealing with a robocall or dealing with an automated service that’s malfunctioning and you can’t find the technical problem or talk to a human to fix it.
Hmm… Perhaps some way of ppl getting paid for p2p helping each other learn the software in question, in SafeCoin?
Where there is an incentive, there will be progress…
Actually that isn’t entirely accurate.
What an excellent fear-mongering post @Blindsite2k
Contrary to your vague (incorrect) assumptions, this development is more analogous to the linux kernel development vs userspace programs. If the level of responsiveness that our very own Linus Torvalds (@dirvine) and the rest of the brilliant core devs have maintained throughout their own involvement is any indicator, any core aspect of the network will be addressed quickly and thoroughly.
When’s the last time that you called to get “The Internet” fixed?
The App devs will be responsible for their own creations and subsequently their interoperability with the network… Who do you call when your SMTP server goes down? Your SMTP provider, or do you call “the guys in charge of the internet”. Who do you call when your online bank account won’t accept a transaction? “The guys in charge of the internet” or your bank? When there’s something strange in your neighborhood, who you gunna call? Ghostbusters.
And as far as the individual projects’ technical support goes, I assume that it would be along the lines of any other open source project. Some good some bad.
I don’t know what you assume a “…high security system…” to be, but you are definitely not talking about open source software solutions, and in specific this network we are currently building.
There is absolutely no A.I. in this network. There is no machine learning. Autonomous Systems are notably different than Artificial Intelligence. In case you don’t actually follow the Autonomous Systems link - the Wikipedia page it links to has “(Internet)” appended to the topic name. To offer a tangible suggestion of what an autonomous system is, because they thought it was such an obvious association.
Please take the time to educate yourself before making accusations and assumptions. Good day.
lol i don’t understand this thread anymore… help?
@Blindsite2k is acting like he’s dealing with a company like AMEX instead of taking the time to stop and consider that he’s dealing with an open source program.
Apply that exact same argument to any core open source protocol over the internet. It falls flat on it’s face. Open source succeeds with mailing lists and forums. It succeeds with more talented individuals taking the time to learn how the network works and designing stuff on top of it.
If the network breaks, the first people who will be screaming bloody murder is the app devs. This is exactly analogous to the development of the linux kernel vs the development of userspace programs. They’d be the ones, though, that took the time to learn how the network interfaces with userspace programs (apps) and they will be in the position to provide quality bug reports and work towards a solution.
The network will never stop development. Look at the kernel! Did Linus ever once come close to saying “Alright guys, that’s it, we’re done!”. Not a chance in hell.
@Blindsite2k’s reasoning is unfounded because his analogies are completely and utterly wrong.
For instance:
He thinks he’s talking about the network here, but he’s really talking about an app. @Blindsite2k, I encourage you to attempt to differentiate between the two.
1 Like
ok i understand. Thanks! Let’s all cool off tho 
@smacz Honestly I don’t know where to start with this. You ASSUME I’m talking about the network. Then you go off on a long rant about how the network will never stop developing or how app developers will always stay on top of things. I’m well aware of how open source works. I’m quite confident in the network. Though apps come in many shapes and sizes, even open source apps. And as the network and subsequent apps grow there is bound to be less oversight. Look on sourceforge sometime, there are plenty of projects on there that aren’t maintained or are only functional to a point yet they’re open source. Open source doesn’t equate to being actively maintained or updated. Sure the main network will be maintained but will some app be maintained?
Before I moved? Quite a few times actually.
Very colourful but what’s your point. I’m not saying the maidsafe foundation is responsible for every app produced. (Again another assumption on your part.) I’m just trying to raise awareness about the importance of technical support and not relying too heavily on automation. Or when coding automation to keep it simple and have a feed back feature of some kind to allow one to contact an actual human being for support.
No? Ya think?
I’m not talking about open source? Wow because if one publishes the code that automatically means one is going to maintain the project. I’ll be sure to tell that to the next abandoned open source project I find that I wish was being maintained. And was I talking about this network we’re building? Obviously no as it has good feedback options.
Did I say there was? Again check yourself and ask questions before you get up on your soapbox.
Perhaps you should do the same. Fear mongering? Honestly dude, fear of what? The deadly robocalls and tech support issues.
Dude again perhaps you should ASK before you open your mouth. There’s already been several suggestions by several people to make closed source programs on the safe network. And even open source programs can be coded in a very restrictive fashion for security purposes. Say an online bitcoin wallet for example with two factor identifcation. Or say you’re a corporation and use an open source robotic answering service. The program IS open source but the data isn’t and again you need to be aware of the need to be able to communicate with humans because you’re essentially writing a script.
Again you assume I’m talking about the network. It could be the network, could be an app, could be anything. All I’m saying is there needs to be awareness.
So what the end user that uses the software be damned? Just leave it up to the app developers and network core devs they’ll fix everything and are bound to notice everything because they’re in a position to have the most impact? Forget about bug reporting because obviously devs know everything.
Did I say the network would? No but some random app maker might. He might just make his app to his own satisfaction and then quit there.
No YOU ASSUMED I was talking about the network. I was simply stating a bloody tech issue. Good Goddess you’re dense.
Jeez guys, Cmon now…
We’re all SAFE lovers here…
Sorry but I do not appreciate being flamed repeatedly over the course of two long posts without even being asked what I meant in the initial post. Forgive me for being a bit miffed after having to slog through that.
@Blindsite2k I apologize for the flaming that I put you through, and would like to clarify your point of view before I haphazardly spout off accusations.
I hope that I’m safe in assuming that if the network succeeds, that you have no fear of the core devs abandoning the project. So that leaves the apps. Both closed source and open source.
###Open source apps
If an app is abandoned, regardless of it’s oversight, it is worthless. So that is the first issue to address: the abandonment of a given app.
With open source apps, one could argue that there is more of a chance that developer will abandon the project than there is with closed source apps. What’s there to prevent that? Well, nothing much. So yes, there is the chance that it will be abandoned. This increases significantly if the project is poorly governed, poorly written, and/or it has a poor community surrounding it. We will explore in greater detail the environment which open source projects create, but for now I’ll assume that you, same as me, have a general understanding thereof.
So yes, there’s always the chance that a situation like that might occur. I would not say, however, that it is inevitable, only that the existance of a functioning project is uncertain.
###Closed source
Closed source programs are another beast entirely. Unfortunately, closed source projects are typically sold on a per-usage basis. Fortunately those selling point of these programs are that they come with warranties and service contracts. In that case, the user is guaranteed that the program will stay updated and active for as long as the warranty and the service contract is active.
However, after the time period of the warranty and/or the service contract, there is no guarantee that the project will be continued. This differs from open source in the sense that you are assured that for the given time frame that there will undoubtedly be an actively maintained program.
To sum up this point, would you agree that even though the timing may be different, there is always uncertainty as to the continuation of any given piece of software?
True. But aren’t you just highlighting my point about the need for good communication between end users and developers via tech support and contact info of some kind?
I wanted to touch on the early adoption phase of software before diving into tech support if I may. Putting aside bug fixes and troubleshooting for a moment, I wanted to explore how a project can reach a critical mass such that there are users whose implementations are critical enough for them to be motivated to submit use-case bug reports and request assistance for troubleshooting.
###Open source
Eric S Raymond wrote that a successful open source software development philosophy is to “Release early, release often.” This opens up the development process to the individuals who are interested in the program. However, one could argue that early adopters are not the ones who would benefit from tech support. Instead, the early adopters are the ones who are, for one reason or another, interested in the program because they are interested in the technology itself, and the potential that it has.
These early adopters typically form a close-knit community, big or small, and trade their own understanding and visions of the program with like-minded people for discussion. By this route they expand their own knowledge base about the program on a number of technical levels. This leads to a development of quality documentation.
However this documentation has an annoying habit of being spread out all over the internet, in small, personal blogs and wikis, along with threads on various forums. Actual “official” documentation in this stage is growing but relatively sparse.
###Closed source
Now a closed source implementation of a project typically does not follow the “release early, release often” mantra. Their distribution strategy is more centered around the need to release a polished, bug-free project every so often. Even though “bug-free” is relatively impossible to achieve (and we’ll look into why that is later) for arguments sake, let’s assume that they release a bug-free polished closed-source program.
Now the early adopters are a bit more varied, as some fears are mitigated by the promise of a warranty. They are not, on average, as technically interested in the program as they are that it works they way they want it to. The early adopters of a closed-source project are, however, pound-for-pound as passionate as their counterparts in the open source environment. Users however need not necessarily worry about the technical aspects, as documentation is more substantial right from the get-go.
However this tends to lead to documentation, as it is typically centralized and less technical, that is functional and more complete in the beginning than is open source software’s documentation. The relative lack of expertise of these users and their experimentation of the program being restricted to the use, not the source thereof leads towards a more use-centered style of community and therefore a different type of documentation that is produced by the users.
Would you then agree that in the early stages of a project, the communities established in the beginning are both passionate and knowledgeable about the program in one way or another, and this leads to documentation evolving and being expanded upon?
This might be true of stand alone applications but is not always true of web apps. Though in general yes what you propose is true. Assuming that adaquate documentation gets written in the first place. However documentation is not a two way communication channel. And unless you have very active and participatory devs like you do here forums and mailing lists aren’t very efficient either. If I have a technical issue that isn’t addressed by the documentation I’ll need to talk to a tech for help, be that a dev or just someone that knows the software better than I do. In the early stages yes this shouldn’t be an issue since as you say devs are very involved and in a tight knit group or provide a lot of docs. However having a “contact us” option is still nessesary even with lots of docs. Incidently what you describe is much the same way organizations form regardless of code.