« Changelog History


go-micro v3.0.0 Release Notes

Release Date: 2020-10-20 // over 3 years ago

  • Overview

    🚚 Go Micro v2 (Apache 2.0) interfaces have now been pulled into Micro and Go Micro is now moving back to being a personal project under the import path github.com/asim/go-micro. Go Micro will no longer be supported by a company or paid maintainers. As a solo maintained (bootstrapped) effort for the majority of its lifetime, it moves back to that and v3 will introduce stricter licensing which you can read about below.

    📄 For a further explanation on the direction of Micro 3.0 from an upcoming post (read here)

    We will now be ending support for go-micro. Having personally spent 6 years since 
inception on go-micro I feel as though its time to finally let it go. What started as a 
tiny library to help write Kubernetes-as-a-Service back in 2014 turned into a widely 
used open source framework for Go microservices development. Having now amassed 
more than 14k stars you might wonder why we leave it behind. The truth is, while it 
solved a problem for many it never became what I had expected it to be.

Go Micro was built on the premise that developers need a simpler way to build 
distributed systems. With strongly defined abstractions and a pluggable architecture 
it did that well but that became really unweidly to manage. With an MxN matrix of 
complexity, Go Micro became the thing it was trying to fight against. As we attempted 
to hone on this platform effort, it just became very clear that to do that we'd need to start 
fresh.

Go Micro will live on as an independent library under my own personal account on 
GitHub but it will no longer be supported as an official Micro project. Hopefully it finds 
second life in some other ways but for now we say goodbye.

    Licensing

    👀 Go Micro is now licensed using Polyform Strict. After seeing what AWS has done to other projects, its clear as a library Go Micro needs to be more strictly licensed. All implementations of external infrastructure dependencies exist in go-plugins still licensed as Apache 2.0 but the interfaces will now be less permissive. Go Micro v1 and v2 are still defined by an Apache 2.0 license and the majority of users can choose to remain on those interfaces and associated plugins. I anticipate some hard forks but am also open to a discussion on the right type of licensing here that might allow Go Micro v3 to have a second life.

    Rationale

    🚅 Go Micro was a solo effort and attempt to introduce a standard for Go based microservices development much like Rails and Spring achieved for web apps and enterprise Java. Go Micro and the related project Micro however became complex to manage and separately were a constant confusion for people. Micro became a real company in 2019 and since then it was far more apparent that we needed to consolidate that effort. Micro focuses on being a platform. Go Micro was simply a framework that had broader ambitions and tried to do too much. Having worked this long and hard on something like Go Micro, its hard to let go, but I also do not wish for large entities like AWS to come and copy that effort to reap the benefits without contributing back for all that time. I think open source is about to have its music industry moment and I think licensing will deem a more appropriate path.

    🏗 If you're a user of Go Micro to build unrelated software, you have no issue. If you use it to offer some sort of commercial packaged distributed systems or cloud services then it may require you to pay a license fee for that. This is dual licensing. Its fairly standard practice and I believe the future of Go Micro.