ASLO-2 Post Mortem

So ages ago, I decided that I would embark rewriting the Sugar Labs activity library (or ASLO, named after the web address). But this did not ever get to the stage where it replaced the original ASLO. There are lots of reasons that this project never worked, many of them social:

• An activity library is only as good as the activities that it holds. There was never a plan on how to migrate activities, other than that it would need to be done. I should have really started this project with thinking, how do I get the data out of ASLO?
• Nobody needed a new activity library that much. Maybe some of the features that I added were nice for developers (auto rebuilding from GitHub), but it was not important. People choose to share things in places where others will find them, and the ASLO1 was that place, not the ASLO2.
• Assuming that old=bad and new therefore meant good. Really, I could have used it as an opportunity to fix issues with packaging a sugar activity (like moving to rpm to get dependency management). But I did not. Instead, I made the same software, but slightly different. It was an evolution that I thought of as a revolution, which did not help adoption

I would also say I made many experimental (in reference to my experience, defiantly not experimental on the whole) technical decisions. Some of them seemed to turn out well; for example, separating the backend and the front end helped ensure reliability despite a very unreliable backend. However there were many which were not too great. Mainly, I suffered from stack overflow; as in there were too many unknown technologies that I used to build it. Probably the nail in the coffin of this project was refactoring it to use a message queue. First, I used fedmsg (why not, Fedora uses it and they are cool), which I did not invest enough time to understand. I then migrated to Apache Kafka (because if one thing is complex, use a different complex thing), which yet again was more complex than my needs, leading to lots and lots of issues.

Also the GitHub integration was comical. I must a been under a wave of fanboy at the time. I believed that storing the activity metadata versioned in git was a good idea, even when every activity commit caused a metadata change. Thank god I never got this deployed into production.

So I made some mistakes. But I would totally give it another shot! How would ASLO2v2 look like?

• Automatically making RPMs from activity git repositories when the dev wants to publish a new version.
• Don't let devs specify the whole spec file (we are installing the rpm as root remember)
• Let the devs specify dependencies; real dependencies are way better than random binaries for the wrong architecture stuffed in an XO file
• Have a nice front end that uses all the same tricks as the beautiful gnome-software app
• Let users install things from this repo automatically via a polkit policy