Web lists-archives.com

free business idea : groupware, opensource, free to use commercially, couchdb and IMAP based to bypass the high costs associated with SQL server-clusters. Then offer paid cloud services for startups with growing pains.




this is not an advertisement.
it's a free business idea that i can offer you,
and a sequel to the old question : how do you make serious money with open source development?

i've thought about it some more, have looked at the demo of Martin's ember (https://github.com/broerse/ember-cli-blog), and i'm currently leaning in the direction of something like Horde groupware (which is LGPL), which supports among many other things, full IMAP email.
and i've found (from the 90s, so no doubt better organized these days) a solution to scale up IMAP using an LDAP server, see https://www.horde.org/papers/Scalable_webmail_HOWTO.html

however. Horde uses sql, and i know that mysql cluster version costs 10 grand per year(!), so that's a no-no for me. 
i aim to keep costs, especially recurring costs, as low as possible for my pretty CMS seductiveapps.com.

and i feel that once again i'm ahead of the curve when it comes to my functionality and performance desires, and the state of the open source world.

i'd like to announce the real opportunity for anyone who loves couchdb, to build a non-GPL, LGPL/MIT/Apache-licensed, truly free, groupware solution (just expose it via HTTP somehow, so that it can be loaded in an iframe hosted on the same domain as whatever it's embedded into) that uses the above scalable LDAP + IMAP setup to facilitate email to the outside world. you could turn this into a cloud-business much like tiny.cloud does for the free and very useful and cool tinymce rich texteditor which i use in my CMS, saving a guy like me the hassle and especially the learning and testing curves of hosting the groupware part of my CMS myself.
personally, i'm probably going to research all of this myself, but since my CMS is my only hope to get out of relative poverty, i'm going to publish whatever i write under my own http://seductiveapps.com/LICENSE.txt to fetch 1% of revenue earned *in commercial operations*, (or less for really large revenue creators) and which sticks to terminology very similar to the MIT license for all other legal matters. In other words, you can use my stuff, add value to it in the form of code or artwork, and add your own license terms to any client you want to sell your seductiveapps based product to.

i say this, not to generate clients for myself. i say this, because ever since "the cathedral and the bazaar" was published (as a book, which i read and have), which deals with how to actually make money with open source, few have shown publicly (to my knowledge), how to do this.

what i write above here, is part of the solution i think. stick to opensource that may be used commercially and which may be modified without legal problems, and keep your costs for running your (web-)software, especially recurring costs, as low as possible at all times, while making sure your software *can scale* to many machines spread intelligently out over the world (for more info, see my README files at https://gitlab.com/seductiveapps/seductiveapps/blob/master/README-001-setup.txt and https://gitlab.com/seductiveapps/seductiveapps/tree/master/__README__INSTALLATION_INSTRUCTIONS ), with the easiest and best-supported or best-proven stack of opensource software, to keep the learning curve and operating complexity of your stuff as low as possible.

you do all that, then here's your real chance to fill a big hole in the market : groupware, starting with email that scales (probably close to how that article from 1999 listed above here specifies, and ... basically a bunch of installer scripts for ubuntu would do that trick nicely these days, it *can* all be run on one server (important for startups growing a clientele), and you wouldn't have to support other operating systems unless you easily know how to and want to), 
followed by live chat between users with the option of having an email log of any chat sent to an IMAP server,
and moving on to things like agenda features that can sync to any smartphone.

this is a moving market, you wouldn't have to write everything yourself (for your treeview needs, look no further than jstree, and for your rich text editing needs the latest tinymce is great even on smartphones),
and for people with more money than time or ability to find technical talents, you could make decent money providing all of this as a package that can be loaded up in an iframe specified Access-Control-Origin to that site that is your client.

the advantages of going LGPL or MIT or Apache license with new groupware that solves the very expensive SQL server clustering (scalability) problem in Horde groupware (the only commerically-free-to-use opensource groupware that i could find yesterday by the way)?
you'd gain more clients and if you are smart and build simple to read code that uses plugins for specific functions, then you'd have the biggest chance for others to write you free bugfixes and feature enhancements created and donated back to you and your project via your license.
i'd recommend strongly you host yourself on github or gitlab and enable the "issues" tab for your project, as well as provide an email list (which would be useful as a feature of the groupware you're building, but which can be based on standard and well-tested, well-supported, ubuntu software packages).

lastly, you need to write test-scripts that solve the question : how much computing power do i have to buy, what is that going to cost me, and the same for bandwidth (a simple ADSL contract of 50 bucks a month supports all of my home browsing *and* my server hosting costs, try beating that; i'd love to hear how you did it :).... to support how many clients that are this or that much active per percentage of simulated users.
i know. that's a real bitch to write, a real distraction from developing features, but i'm going to have to do the same for my CMS. You can't build features these days without the ability to prove how many users, active users, and very active users, you can support with how much hardware, organized specifically in this or that way.

you have to explain and document all these variables not just in your documentation, but in test-scripts as well.
test-scripts that at least note the CPU type, CPU GHz count, CPU core count, operating system version, all version numbers of your other critical software (like couchdb), and of course how much RAM the machine has in total, and how much free RAM at start of the test.

you can then publish these test-results on your homepage, and by having specific test-scripts (that actually send back their results to your server automatically), others can test on their hardware how many daily users they would support.
you have to specify, per any of multiple time-ranges, total time-range being flexible as well, the : total number of users, the number of normal users and all the counts of operations such a normal user would make in the specified time-range (executed as a web-browser would execute it, but always starting with a high-level operation like requesting all the emails in a certain inbox for a certain user. yes, you'll need to build tests for each feature that is often used, at least) (and these numbers can be measured as well in the real world, make sure you keep logs of that somewhere where they can be found by the site operator too), and the same for 'active users' and 'very active users'. you'll probably need to specify a random timelength (from a specified time range again) between requests made by these users, and it wouldnt hurt to make your performance tests in a way a user would use the site. for email, that is : how long to request the list of emails in an IMAP inbox of a certain size (and whether you pull all IMAP data into couchdb is up to you : IMAP + LDAP does scale already), then how long to store and send an email (to a test IMAP bucket of course) with or without smartphone pictures, then how long to "read" (request the contents of) several emails in such an inbox.

this may seem like a lot of work and hard work. but actually it's just accountancy level math : add, subtract, multiply, divide. that's it.

it's a real chance for your own successful opensource + cloud company, and i'll offer anyone interested the deal that if if their stuff meets all of these requirements i list above here, you can use my seductiveapps.com for free on your site, forever, if you like.
but the GUI part of your HTTP iframe-able application, must include theme abilities.
once you're all done, and then after a long rest get bored, you can always add a theme editor, like i've done and am doing for my CMS.
this way you can enable non-technical artists to create some free cool-looking themes for you, which will add much value to your groupware product, and provide the many who can't afford to pay big bucks for software, to do something in return for you.
i'd be delighted to share back a good-looking semi-transparent theme for your groupware, and all your users/clients..

over the next few days, i'll decide how far to take this. i can do this, but i'd have to stick to my custom license that's not entirely free for commercial use (1% of your revenue made on a site that uses my CMS please), and work on it for about a year, maybe 2 years even, 
or i can focus on the rest of my CMS' functionality, and just wait for someone or some group to fill this hole in the market. so i'm sending this email to the 2 groups i know to hold people who might be up for this challenge : the couchdb user, and php-general, mailinglists.
once again, MySQL cluster version costs frigging 10 grand USD per year! that would kill my entire project and company. so would using Horde Groupware with just one MySQL server. and i didn't spend years building my stuff just to step into a comfy pitfall like Horde is today.

and i'm far from the only CMS builder out there. there's a real market for this solution.
if you'd keep your solution easy to install (and all it's components too ofcourse), then guys like me *will* be interested in your commercial cloud-hosting offerings (provided they dont scale up in cost as usage increases, like Amazon S3 does), to save ourselves headaches and growing pains as we deal with increasing numbers of real customers.

feel free to email me to pick my brain some more, if that's what you feel you need.
or just reply to this list.