It looks like you're new here. If you want to get involved, click one of these buttons!
For many years, website scripts have had their official and off site communities. Many such communities have either been in separation due to a technicality, or simply have cancelled development over time due to support limitations of one kind or another. If money is a motivation for some scripts, then their developers may, at times, choose to sell their product to an interested buyer, who would then take charge of on-going development and support of it, leaving the original founder or development team to do their own thing. Essentially boycotting their own product either as a registered Patent or released on terms of necessity.
In many cases, black mail hardly ever enters into the project. Unless fear is a motivator to dislike ones competitors in a specific field of interest, many people have often felt the separation from software communities and their developers is something one has to support because of their loyalty to how a software package works for them. In the case of Social Engine and PHPFox, the category of social networking platforms, much like that of the forum and blog platforms remains similar. People use what works best for them, not because of what they don't wish to use, but because of what meets their requirements. Unfortunately, the harsher truth of such a concept, leaves us scratching our heads in confusion, if such a quality of product (s) in question are based on who is developing them and or it and whether or not active development is something the entire community can truly appreciate. If so, the version of which clarity represents itself therefore, is met with a unique eye for criticism as we test each others products to see whether or not things change. Time understands what true intentions are currently present during such windows of opportunity for such changes to happen, and if in a timely manner, we find a way to support what works for us, we are therefore loyal to it, because we invest for it to be loyal to us. Essentially completing software support full circle.
The issue now becomes, who is loyal to what, and why? IF what we love, is built by who we love, the question is a simple answer. Where we go is based on all we love, not why or who we love to go there to continue our love. The problem with such a simple idea, is it discontinues business support for what we used to love if the ideas exchange levels of quality or personnel. OF any capacity, we are only faced with a problem if we are a part of it, in other words, allowing it to be a problem concerning us. For example, switching from one product to another because of a technicality or other reason to need a requirement to do so, may leave us wondering why it should help us if our solution to what we wish to change towards, is not an ideal one which understands the needs of why we wish to do so anyways. Having said that, all can be overcome if we set aside our differences and treat each other with both a sense of equality and open mind, as we realize one important difference between the things we love, and the things we need. IF we love because we care about where we are at right now, we are safe from incurring problems which can happen if we love because of where we are at right now, therefore putting unnecessary conditions on why we love and what we love. Who, and other such details are irrelevant here, because we see ourselves for all we are, if we love our needs first. To put such into perspective, what works for us, is what needs to continue working for us, regardless of all we have to do to insure it either does or does not suit our requirements for why it works for us. In other words, how we can make something work based on what it is capable of doing as it is still an option we can consider which is relative to what we require to work in the position we find ourselves and our community networks in on a daily basis.
To make a practical understanding out of what I've just described, what I'm interested in doing, is uniting developers from different areas of the software distribution marketplace to work or find ways to support development of each others fields of interest to see if we can create a common set of best practices among other things, for each product, so that its development can work off of a common goal. Which isn't just to serve users, but to serve users based on common accessible and documented technologies using real scripts as best practices for examples of working code. Essentially, bringing both third party and official developers together to make something which is not in competition with something concurrently going on, but to support a common alliance for the continuation of individual updates for products, so as to encourage people to use them. Therefore, we can help each other find things which does and does not respectively work for each product we have, and if we are excepting of the idea to try something new, we can progress as a community of people wanting to network for the common goal of both business and support of all web space virtual communication needs. For it is not our job to ensure we keep up with technology, as much as it is to ensure technology keeps up with what we intend to use it for collectively. Which is what and where our differences truly become our own creations within a co-creative atmosphere of personal ideals coming to life one site at a time.
In order to make this happen, we need to bring together developers from as many different products as we can with one common goal. Who have actively developed something in the past few years, and who is interested in sharing certain examples of technology which they use to power their creation, not the full disclosure of their creation itself, if at all possible. What we don't want is unless otherwise specified, a duplication of what someone else has made, but a common interest of how they made it, so that such technology can be used for existing and new creations we make together, for respective purposes of like minded interest. AS companies enter the shared customer stage, and exit the start up phase, we need to drive innovation based on what people are already interested in. We can't predict what people wish to do all at once, but what we can do is ensure technology we use to empower our creations, is effective in bringing our own unique perspective within what we develop, to light. This requires an in depth understanding of how we build what we code, for each product developer interested, to be able to make our own with it. IT is the same idea as gathering 30 musicians in a room, and asking them to construct a musical instrument they can feel comfortable playing. The same principle can and should apply to modern web communities, so there is a playing field of standard opportunity for everyone to enjoy here.