Kinkade, first off, I'm not sure any of us will be able to answer all of your questions to the detail or accuracy you seek and in a reasonable time I deem worthy of my day right now. And, I don't want us to chase tails on this with huge emails that just stay in email land rather than become part of a FAQ or something useful (although, I think FAQ are result of something that is too complicated, like the CC FAQ to explain CC...really the license should explain themselves, and I hope aiki can explain itself too).
However, out of respect to you, I will say that I knew that in working with you closer, that you were going to get into any of these hornet nests like aiki like the critical skeptical and sometimes annoying friend we love :) So, I'm doing my best to reply to your answers. I honestly believe that aiki is not where we want it to be, and that even needing to answer so many questions in depth about aiki is a problem with the design and building of the software. I am though committed to making it work, which I will detail at the end of this email with my irrational reasons for working on this. On Thu, Jan 5, 2012 at 10:43 PM, Nathan Kinkade <[email protected]> wrote: > Aiki is a platform for building CMSs? In what way? I keep hearing > and reading about how Aiki is a "framework", but can someone please > define "framework" for me? Are you saying that Aiki is a drop-in > replacement for things like Django in python or Kohana in PHP? Can > someone show me and example of how this is achieved, and even better a > live example, and tell me how it differs from Drupal, Joomla and > WordPress in terms of functionality (not details)? I haven't attempted to define this in detail. If you would like to help us by comparing these and finding the strengths and weaknesses, that would be useful: http://www.aikiframework.org/wiki/FAQ#How_is_Aiki_Framework_different_from____.3F Man, this entire wiki is out of date: http://www.aikiframework.org/wiki/FAQ Its a framework in this way: http://en.wikipedia.org/wiki/Web_application_framework That would be great to put on the FAQ. Please read over the wiki, there are some examples of ways to build apps with aiki, although they might not all be current. http://en.wikipedia.org/wiki/ > What good does a widget ID do me? As far as I know you can't lookup > anything by a widget ID in the admin interface? You need to know the > widget name, and even them it's still ridiculously hard to find it > because it may be buried under some other meta-widget, or whatever you > call it. What speed benefit? Consolidating all CSS is old news for > websites. Sure, the admin interface is substandard. We could just delete it and use purely mysql commandline to edit a site, but that might be harder. Easier is to find out what we don't like and use new energy to make something better. Sure, there are lot of things like CSS consolidation and other features that are not invented here. We learn from others. > All this stuff about not having to touch PHP seems crazy to me. All > you've done is reimplemented a pseudo-language in some very limited > markup. This makes me think of the Smarty template language, or even > wiki markup. In both cases the object was to make things simpler for > the user, but in reality it's just one more markup language that > someone has to learn to do anything and it would have been more useful > for the user to just learn the basics of the original languages, like > PHP or HTML markup. And to make matters worse, you then need to write > a parser to parse all this newly invented markup, only to turn it back > into PHP and HTML and SQL, or whatever. It's a terrible line of > indirection that is unnecessary. These are all your opinions. I personally like to just use git + vim + text files where possible, but aiki is a bit different. I agree that the current markup is wonky and silly. Ideally, aiki would require no markup to make simple sites IMO, but let me get to some higher level thoughts before we get into nitpicking. > But as much as anything, can someone please explain to me why Aiki was > written? What specific problem is Aiki trying to solve? The best > software out there was written because someone perceived a serious > lacking in the existing available tools, so they wrote some code to > fill this gap or go beyond existing tools. If the answer is that > "it's all in the database!", then that is no answer to me, because I > view the fact that it's all in the database a strike against Aiki. > It's a pain in the ass because you are cut off from using decades > worth of amazing tools meant to work on binary and text files, and are > limited to grubbing around with SQL, which is a relatively weak > language. If the answer is that having things in the database makes > Aiki vastly faster, then I'd need to see some hard data and tests. I > read the performance comparisons in the wiki, and they don't tell me > anything that seems legitimate. I mean, how fast can Aiki handle a > document with 10 million links compared to Mediawiki? Come on, that > is not test, and it is designed specifically to hobble Mediawiki > because you know it has to parse all links with the Linker. > Additionally, no document will ever have 10,000,000 links. Sure, call bullshit on that. Bassel ran those tests before, and the information is surely out of date marketing words at this point. Aiki was written by Bassel originally (and he can speak to this better) to: * make openclipart work ** PROS *** openclipart obviously works way better now...better than the original custom solution I wrote, and way better than the hype of the overbloated ccHost software *** the goal of getting more people helping totally happened ** CONS *** also introduced some bad coding practices that I didn't realize were happening at the beginning because I was more hands off, like the code was forked from the trunk of aiki *** also, permissions were given out too easily, but amazingly the site never went down or no one deleted the site! * allow for multiple people to collaborate on building a website, with varying levels of permissions/access control to different parts (widgets) of a site ** PROS *** Totally this happened! Now we have pullled back, but it happened *** There were/are levels of control ** CONS *** In all honesty, its way too complicated to create permission groups and so the system really became users, and root-level sysGODs, who could do anything *** I think while workable, aiki's permission system needs to be re-architected to fall in line with unix permissions system * allow for hijacking/using other CMS/blog engines databases easily ** PROS *** Yes, this works! openclipart cchost database you can still see in the openclipart database tables *** There is/was some custom code for importing drupal, cchost and more ** CONS *** Its not so transparent how this process happens *** There is no simple way to do this without digging into mysql commandline really. The run query feature helps to discover what's inside the database, but still we often find going back to the commandline often * have a simple web-based interface for collaboration ** PROS *** Bassel and Michi started work on the current aiki admin interface and it is basically workable. *** It has allowed several websites to be developed *** Uses the aiki widget system to build the admin interface, which is cool to dogfood the system ** CONS *** It was not completed totally IMO. There were features we removed that totally did not work, and were halfway put together *** There are still many bugs in the admin interface like the widgets not showing up under each path/route in the left-sidebar *** Ideally, there would be a brand new admin interface, jakub is working on this. Really would be great if there were more people working on ths * be faster than wordpress, drupal, mediawiki, and the other aging software packages relying upon a database ** PROS *** It seems simple that having less code and interface directly with the database would make a site faster with aiki rather than the code in some other engines *** apparent speed is faster *** bassel showed me tests before of the code working faster on mediawiki and wordpress ** CONS *** I don't trust the tests at all now. *** Really there needs to be better benchmarking regularly, and sample tests against latest wordpress, mediawiki, and drupal for comparison sake (but, we have limited resources to do new development, let alone tests, we need help in doing!) * allow for managing multiple sites with one installation ** PROS *** There is code for this by bassel. *** rg1024 really rewrote/updated this code to make it work, but I have not used it. ** CONS *** Without a simple user interface, this feature is really nonexistent to most users * allow for multiple languages out of the box, and simple translation ** PROS *** Before it worked in a kludgy manner, but rg1024 rewrote it to industry standard *** Jakub wrote a great tool with javascript to allow for translation of terms in the database, with a simple UI *** This is totally working super well now! *** rg1024 has code on the way to extract these strings and use standard PO for when there isn't a db connection, and so others can participate in translation process *** removed the somewhat arcane and nerdy PO/gettext system that many use, with a simple interface for translation. The goal is to get more people, even normal people to help translate in a community. ** CONS *** It took us a while to get here, but shows that we are making progress *** Still not simple to translate in the admin interface...jakbub is packaing up his tool and we hope to get that into an upcoming release so simple for others to translate sites. This is actually something that is not so easy to do on other database-backed systems. *** standard PO/gettext is not accessible right now, which is bad for nerds, who are most of the developers :) Ok, good to type these out. Before we relied upon community support only for Aiki, but now there is some investment into developing and fixing features which is great. I think we should definitely redefine and cleanup the statement from the homepage which is my marketing attempt to capture what aiki does: Agile. Teams Work Together. Community with Teams. Web-based Development. Secure. Battle Tested. Built-in Permissions. Pluggable Security. Fast. 25x Faster than Drupal. 5x Faster than Mediawiki. 3x Faster than Wordpress. Free. Open Source Software. Saves Electricity. Database Scaling. All the above need to be updated and bullshit removed. My take from Bassel's christmas eve radicalized statement is that: Aiki should be easy for normal people to build web apps. Can we simplify the statement above more? * Easy for people to build web apps (on the marketing side I would say now: Easy for people to build html5 apps) * Easy to use interface * Easy for people to develop collaboratively securely * Easy for people to communicate * Easy to deploy, maintain and update a site * Easy to scale sites up ### If those above could be new criteria, then we have a ways to go. But, what isn't a worthy challenge! I'll take them apart: * Easy to use interface Aiki is totally not easy to use! Its totally hard to use and you know that from the wiki bloating up with instructions. The best products/projects don't need a wiki or a manual, the interface should show how to make a site quickly and easily. I want early coders like Spencer and Pete or Bassel's girlfriend to be able to make a site with our default interface. FIX: Analyze problems in current admin interface and file (mostly done). Define what an ideal admin interface is and build it. Jakub is working on this. Thoughts? * Easy for people to develop collaboratively securely There were tests done before on security. Nicky from before also did an audit on aiki and we fixed some problems from it before. FIX: The permissions system really needs a hardcore update. Jcubic has been looking at this. Do an updated security audit on the site. Fabricatorz has some upcoming projects which are going to need super secure aiki installations. This is important. * Easy for people to communicate This is an extension on the idea that it should be easy to translate the site into multiple languages and easy to use the site. I want to even has some simple google translate-like features built-in so its simple to get rough translations, but get community members for a project to help out too. FIX: We have great language support now in aiki, we just need jcubic's translation editor included by default in my opinion into aiki as well as simple way to create more standard iso languages in the interface. also think making widgets with default languages could be cool way to make it simple for others to make a site translated. Thoughts? * Easy to deploy, maintain and update a site Ok, Bassel thought the build system was too complicated before, so he hacksawed it. I agree with this approach. So now its easy for a normal person to install a site. FIX: However, maintaining and updating a site, as I said before are the HIGHEST PRIORITIES to be audited, broken down and completed right now. This is really really important for client work, and for the health of aiki projects. This really needs to be completed. Nathan, could you help fix this? Other thoughts on this? * Easy to scale sites up The theory is that being based heavily on a database, database scalability will help aiki-based sites. However, as we seen from openclipart, yes, its possible that some convulated database upgrade could help, but real database clusters have not been super tested on a geographic scale outside of one datacenter. Also, the group level access to openclipart introduced tons of super slow queries, which have mostly been fixed by you and jcubic, and then a bigger linode. A FIX: define some goals for scalability, and analyze current aiki, then rollout some torture tests to see how it performs, then fix. .However, if there is no demand for this feature, I would delay this. > Again, I don't mean all this questioning to be a criticism of the > people who have spent a lot of time developing Aiki. They are just > natural questions that are coming up for me as I thinking about > working with Aiki. You all need a viable story for Aiki, one that > will pass someone who knows anything about computers and technology, > not just someone reading it for buzz words and hype and is impressed > because they don't know any better. Has anyone else other than > Fabricatorz or a Fab affiliate or friend used Aiki for anything? If > not, why is that? I enjoy your criticism as long as its constructive, but I don't always have the time to answer thoroughly. But, this email I want to make sure to address now. There has been in the past, but most of the sites are totally powered by Fabricatorz and Aiki Lab, and are from our investment in the technology. I hope that we can work together to make it better and to make our platform stronger. More answer below... > 2012/1/5 Jakub Jankiewicz <[email protected]>: >> Aiki is more then CMS is a platform for developing CMSes. The good >> thing about it, is that you can manipulate Database and use CSS HTML, >> and JavaScript without touching php. This is somewhat true. The goal of a framework is to accelerate develop with some prebuilt components. Aiki core is what needs the most work right now. However, the component building systems: extensions and plugins are quite good now thanks to Bassel and rg1024. Aiki Apps concept needs some love. >> And all CSS content should have this /* widget (id) */ comments so you >> can easily find where to change that CSS. It's not like inline style, >> it's more like you want modularize CSS to put in different files, but >> you have speed benefit because they are all combined together. This is when in debug mode that one can see the comments in HTML and CSS to find out where the content is coming from. >> And Aiki Markup I propose on the Wiki is more like the language, so you >> can do everything you need in it, and don't need to touch extensions >> which are pure php code. Jakub's proposal is a big advancement over the current shitty (but somewhat workable) aiki markup: http://www.aikiframework.org/wiki/Aiki_markup_2 >> The best thing in any language is the ability to put your code into >> functions/modules/classes to split it up and make abstraction. But the >> Admin Panel should be better to allow to do this things easily. >> >> I have this mental picture of new Admin Panel I want to build, I work >> on it after we release Aiki 0.9 Great! Would love to see plans for this. I have several as well for what I would like to see, but haven't had the time to submit them :) >> I think Aiki is great but not as it look right now, because it's mess, >> but how it should/will look like. Good attitude! Yes, the admin interface really doesn't sell it very well. Overall, the irrational reasons I want to make aiki work better and continue working on it: * Bassel is my/our best friend and I want to support him and his original project * I believe the point to life is working with people, so I view working on a project like this as working together very closely to make something we can be proud of as a team * Its fun * We are all learning :) * I want a software platform we can use for client projects that we control the destiny of... * We have invested in the project, and I still haven't seen a workable solution that is faster than nuking the current codebase (and I have learned this well from Inkscape and the people who often rally for nuking a codebase, flake out the fastest...its hard!) * we have sites running upon the software now, so the investment has paid off, and continues to pay. That being said, if there is a better option or a better updated design, that is always great to see. I would love to see more features removed from aiki, and problems fixed where possible. I would also like to see the website and wiki cleaned up, hype and bullshit removed, and the plans updated so we can make something we are even more proud of... For Fabricatorz, Christopher and myself thought about this a lot and we don't want Fabricatorz to get locked into one technology, however Aiki is preferred web app/html5 solution. I view Aiki Lab as the parent project creating software platform aiki framework. I have another tool I've been working on called make static which takes the concepts of aiki inside of a makefile and then generates static webpages, which I will also push over to Aiki Lab as another software tool at some point when ready. If there is a better path to accomplish goals of aiki, and replace our client software (like an aiki rewrite), I would not be against this. Its simple to rm -Rf * aiki codebase, and just rename another piece of code aiki and jump the version to aiki 2.0. In my experience, this usually fails. One, it fails from the community standpoint because those of us building the current software have some familiarity even with a nasty codebase. It also fails because unless directly funded with cash money, often community contributors vanish like fosdevel (stephen has). Casual community contributions often come from social reputation benefit and desire to learn, so bugs and necessary need for new features encourages contributions. Fabricatorz or Aiki Lab as a company doesn't have enough money to invest to replace the software and then replace it on client servers. In fact, that would be really bad because spending more time to redevelop the software and then more time and money to replace the software because one or more people think its shit internally, would not work at this point because it would just cost more money, not make money. We are scraping all hours out of the day to complete our paying projects, and then to spend more on projects that cost us money is too expensive right now. I haven't sat down and done the math on it, but the growth of our income and fixes to aiki are increasing faster than what I perceive a rewrite, rebrand and/or doing a "find some random piece of software we don't control to build website" on. Yet again, I'll try to be open minded. Overall, we don't have enough money to rewrite from scratch in my opinion, but enough to fix bugs and add features where we can. Refocusing development though is a good thing. Cleaning up and updating, great! This is how we did Inkscape, and it worked well. There are similar demands for this on the qi hardware/milkymist project, but there the money/investment is even greater and insane to see these requests when there has been 200-300K USD dropped...invest through the problems, but try to get sales to outpace investment is the goal. As for the future of Aiki, I want to make it easier for people and fix problems over time. I would like your help too Nathan. Your skepticism and criticism is good to ground a project, but also you have to remember that we have to make decisions which make sense to the company in terms of cost, time, and resources. Software projects are not just virtual simulation. They are not people, but they are the products of our labor. I value aiki as an artwork, software, and something to be proud of as it gets better. I view it as a poem or book we are writing together. The better aiki gets at this point, the better it gets for our clients we built sites on with this technology. Also, ideally, the better the software gets, the less expensive it is for us to build sites in this manner, and thus we can make more profit, and spend less time developing sites. So, let's make aiki better for normal people to use. Let's simplify it, the website, the wiki and more. Jon PS: This is the longest email I have ever written. It took me 2 hours. I mean what I say! -- Jon Phillips 王✳爻气 http://fabricatorz.com ✳ skype: kidproto ✳ irc: rejon +1.415.830.3884 (global) ✳ +86-187-1003-9974 (beijing) _______________________________________________ Mailing list: https://launchpad.net/~aikiframework-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~aikiframework-devel More help : https://help.launchpad.net/ListHelp
