heuroci

@fowlie Have you taken a look at Maltron[1] yet?

1.https://www.maltron.com

I enjoyed this post. I hope something good came out of the struggle for you.

I think it depends a bit on the real intention. If the author intends to grow their project to a business and is upfront about it, there is nothing wrong with that. After all a sustainable business would imply sustainable project. The misfortune happens when the concealed and public intentions are not aligned.

One simple solution to the asymmetry is to abolish it. Instead of releasing open source project touted as a "general solution", why not adopt release it as "here is some reference code, it works for my use case. YMMV"

This is a complex and topical issue. It can be viewed in multiple ways, as a philosophy/ideology, a sustainability/societal risk, a degree of freedom and as a socio-economic system. There is also the business of it all.

My memory of open source in the early days is that it was a mixture of rebellion and passion interweaved with leftist/anarchist stance. A lot of the freedoms we enjoy today were unthinkable back then. What you could do with software, even if you bought it, was highly restricted. If you read about the history back then, you may come to the conclusion that was totally bizarre. Not only were we restricted on what we can do or how we use software, writing software and making it open could subject the author to legal battles and liability. you know what was the next linux?BSD! but the legal procedures complicated its spread and Linus released the kernel at just the right time. I thank everyone who fought for those freedoms.

At that time, most source code that was released under open source licenses(there weren't nearly as many as we have today) was work of passion. I made a few presentations around the world mostly to university students far removed from the bay area to inform them of what is available to them (and secretly convince them to not join the armies developing on a particular platform).

Those days are long gone. And that is ok. If "price" and "freedom of expression" were the 2 dimensions the battle was being fought over, then open source won.

Things changed from "well..uhmm..there is an open source tool.." -> "It is open source" -> "We are open source!" --> "are you open source?"

The open source ecosystem had evolved. I believe in many ways to the better(choice, accessibility, cost) and in some-not-insignificant-ways worse. The accounts of the abuse and hardships maintainers endure are numerous. The bait-and-switch strategy is well documented now. The cloud-eats-opensource is self-evident. The knowledge of the craft, paradoxically, seems more centralized. Certain domains are pretty much proprietary software. Not a bad thing in itself, more like a necessity till economic incentives are better aligned.

There are also a few things which I believe we as a community of practitioners maybe conditioned to overlook or only recognise subconsciously:

1- At some point , open source became a marketing ploy, for individuals or organizations. Open source consumers are not blind or oblivious to this, so they may feel they are indeed paying by giving their attention.

2- The price "$0.0" maybe considered the fair price considering the risks("No warranty, etc.")

3- Substitutes, existing or almost-guaranteed to materialize, are in no short supply.

4- Even though the customer(open source consumer) may not expend a monetary sum, they do expend in kind. We all know the efforts required to get most open source software to work, and to make them work together.

5- There is a mutual, likely unconscious, alienation: one group pointing to the other as the one to blame for not making this ecosystem sustainable. It doesn't help the cause to refer to open source consumers as "vultures". It doesn't help to blame corporations(many of which are responsible for massive open source efforts which would not be feasible without those corporate funds). It doesn't help for consumers to exhibit symptoms of entitlement or subject maintainers to outbursts of anger. This doesn't mean to be apologists or ignore unacceptable behavior. More that I believe focusing on the behavior is more productive than focusing on the actors. One group's apathy to the other doesn't help either one.

So we have mythos and ethos challenges to deal with. Add globalization and they become far more challenging.

In short:

1- We have an economic model that is skewed, on supply side as well as on value capture side.

2- We have an erosion of trust that has been slowly and steadily accumulating over the years.

3- The expectations of the participants are at best ill defined and likely misaligned.

4- Licenses define one type of contract. We are missing "Social" and "Economic" contracts.

5- Speaking of contracts: it can be prohibitively expensive for individual or small teams to consult a lawyer on how to find a balance between open source mythos and economic participation. It can be even more expensive to do that in hindsight. So here FOSS bodies and volunteers could help.

We can simulate what happens from here easily. If nothing changes, it doesn't look good. The rising awareness, however, presents some hope and reason for optimism.

We could try to exert agency and find mechanisms to correct. more decentralised manners could be better fit and easier to customise.

As for a business model, I can't reference any that I believe can be sustainable and result in a viable business.

I also did not get this from the OP article. I would say he could have articulated things better.

It is imperative to note that what constitutes minimum and viable had generally changed since 2010.

We should also keep in mind that those terms are relative terms, depending on the domain.

For me, I think one should know a lot or experienced personally the problem(domain expertise) and be open to the form of the solution(the product). For practical reasons, if nothing else, learning any sufficiently complex domain while trying to build a business is expensive.

I have an intuition that there are multiple classes of ideas: ideas that are linear interpolation of the present into the future: Those are intuitive, either for domain experts or the general public. A little voice that says "Next we do this..."

ideas that form a gravitational force: these are ideas that pull many, uncoordinated efforts. It is a bit hard to describe, but I think of this as ideas that are "necessary" in a grander emergence that needs the ideas to cement its existence.

Ideas that are not ready to be hatched: "the too early" class. Sometimes because a missing ingredient has not been identified or not sufficiently widely available. When those ideas fail, and a decade or so later new thinkers think them again and realise they failed, sometimes they go back and figure out the prerequisites weren't there and now they are or they build the prerequisites themselves.

Ideas that are non linear: those are the rarest to come by. I believe they require extreme tolerance for counter-factual thinking either naturally or otherwise-inhibition-reducing aids.

Reporting for duty...

This depends a bit on what you aim to get out of reading them? I liked both of the books you mentioned for different reasons personally. Do you have a set of goals you wish for as an outcome? could you say a bit more about your background as well, please?

@jakobnissen you have a typo in the first section: "Among Julians, latiency is" - Sorry, I would have nudged elsewhere but could not find an alternative venue to contact you.

Excellent article!

Very similar. ZX-48 at 11 years of age. First some graphics programs, then a chess program. The first program I "invented" was a guessing game. I graduated to pascal a couple of years after on a PC. The class was for professional adults, most of them engineers by training so I was the only kid. I did not have a PC, so I wrote pascal long hand through the week and then typed when in class. Fun times!

I bought some 10+ years ago, and they are in storage, and I am also feeling that urge to go dust them off and power them up. If memory serves, I think I ran netbsd on them.

Thank you for writing this. you brought back some good young adulthood memories of VMS, OSF/1 and Tru64. All seemed like alien technologies at the time :). Thank you for your service and hard work

I would not worry so much about that.Not for a while.

The actually concerning aspects about AI safety in my opinion are more about misuse/abuse as well as critical processes/decisions without human oversight. To be deliberately malicious, AI has to be strong, if not general. Both are very difficult. It is good to think about those things though

Perhaps you will enjoy this: https://heurolabs.atlassian.net/wiki/spaces/AIS/overview

I share your view on category theory and perhaps lattice theory as well. What I was trying to say is that before you can draw that analogy, regardless of what "shape" means to you , you have to construct the base shape.

Analogy to me comes after you have stabilized "shapes" where you can draw comparison between a new input a set of stable patterns at which point you can point out the analogy. Syllogism may be closely related/involved.

I am not disputing that being able to draw parallels and employ analogies are related to intelligence. I am just not so sure that this is how you can synthesize intelligence. It is all very complex of course, and there is a school of thought that cognition is very closely related to sensory and embodiment (i.e.: embodied cognition ).

I think Aubrey de grey switched from AI to longevity because he figured he will need a long life to understand intelligence :)

Personally, I am still working on it but had adjusted the scope a bit.

I personally designed and participated in the implementation of a hybrid cognitive architecture which combined both NNs and GOFAI.

We (http://www.heurolabs.com) are contemplating open sourcing it, or at least publish the design documents

I am reading the same book. I think analogy is interesting but it doesn’t make sense that it would be the foundation. analogy is a heuristic to reason and communicate. It necessarily comes after intelligence.

Are you familiar with quad keys and quad tiles? If not definitely read up. Could simplify a lot of routing and tracking: https://wiki.openstreetmap.org/wiki/QuadTiles

I don’t know know your stack so take this with a grain of salt:

It may be very tempting at times to skip normalizing data and to just throw stuff in a document store. The downside will be code complexity and runtime that is less than performant.

I am sure you are familiar but the patterns “adapter” “strategy” and “interpreter” can be very valuable here

I am sure you also use dependency injection as appropriate . I wish you all the best. I will keep an eye on and think good thoughts

The domain is also ripe with algorithmically interesting problems.

One issue I have seen though is the mindset of the business user may not be very tolerant of probabilistic results.

This is indeed a great model that works well when the problems one client has can scale to others without a ton of customization.

What has been the most challenging aspects technically and business wise for you so far? What has been the most exciting/rewarding?

This looks good! Complex industry with archaic tools so it is great to hear you had done some business already! Can you elaborate how much of the business you generated was more like consulting vs the customer using the packaged solution?

This is an excellent approach that I wish was more well known/common. We use this first before going to a complete service, which becomes easier anyway once you have a few libraries that had been in use and tested by then. Works great for our clojure code and other languages.

I was thinking the same thing. Funny how full circles come about in this industry sometimes isn't it ;)

Architecting systems is a dance around tradeoffs: What weight do you you assign to each of the 'ilities'. Some products/services are inherently complex. For those, complexity can not be destroyed.Just transformed from one form to another. I agree that there in many cases people jump on the micro services architecture too soon, without first developing a mature understanding of the domains involved in the application as well as data flow and state transitions. Some years ago I was involved in re-architecting a monolith. This was a team that cherished testing, had modules and layers in the monolith , swore by DRY and so on. There were a few problems: * Adding features was an expensive exercise. For all the layers in place, the abstractions and interfaces were evolved over 5 years and not necessarily with enough design upfront. * Performance was poor: The monolithic architecture was not necessarily to blame here, but rather using a document oriented data store and doing all the marshalling/unmarshalling in the application code. The reasoning was that 'we can store anything. we can interpret it any way we like'. In practice, the code was re-inventing what relational databases were designed for.

I proposed and designed a micro services architecture with the team. I had done that sort of thing a few times even before they were called micro services. There were a few advantages: * The product team had the freedom to re-think the value proposition, the packaging, the features. It was critical for the business in order to remain competitive. * The development team could organize in small sub teams with natural affinity to the subdomains they had more experience/expertise in. * Each domain could progress at the pace that fits, with versioned APIs ensuring compatibility. Not necessarily a unique micro service success prerequisite. One can argue versioning APIs is a good best practices even for internal APIs but the reality is that versioning internal APIs is often less prioritized or addressed to begin with.

There are technical pros and cons for monolith/MS. Additional data that can augment this decision is the org structure , the teams dynamic and the skillsets available. In the case of that project, the team had excellent discipline around testing and CI/CD. Of course there are challenges. Integration testing becomes de-facto impossible locally. Debugging is not super difficult with the right logging, but still harder. One challenge I saw with that project and other projects that adopt microservices is that the way of thinking switch to 'ok so this should be a new service'. I think this is a dangerous mindset, because it trivializes the overhead of what introducing a new service means. I have developed some patterns that I call hybrid architecture patterns, and they have served me well.

One thing to consider when deciding what road to take, is how does the presentation layer interact with the micro services. When it is possible to map the presentation to a domain or a small subset of the domains, the micro services approach suffers less from the cons. A monolithic presentation ---> Micro services backend could severely reduce benefits.

2 good references here: 'Pattern oriented software architectures' 'Evaluating software architecture'

Pretty excellent series. Kudos to the author.

All the best to the metamind team in their new adventure. For users of the metamind, Heuro Labs GmbH (Disclosure: I am the founder) offers a unified api for data mining supporting multiple modalities, streaming input directly from Social Media, etc. and built from the ground up to be a data fusion pipeline http://api.cognitio.heurolabs.com/#/signup Swagger docs: http://api.cognitio.heurolabs.com/assets/docs.html Wiki: https://heurolabs.atlassian.net/wiki/display/CogniDoc/Overvi... Demo: http://web.cognitio.heurolabs.com/