Hello everyone,
The TIIME meeting kickstarted some very interesting discussions. One
of the topics on the "Open Source Identity and Access Management "
track was "Open Source Business models and cooperations for IAM". I
was there on part of the discussions that started the 2nd day and
expanded over the next days. The topic is dense and while it was
directed to the domain of IAM, I think that comes later in the
picture, after we've discussed and agreed how Open Source works, why
it is important for us and technology, and how one can benefit from
(using or investing in) it. Being upfront and clear on why we support
Open Source is key to understanding how Open Source can support us.
Trying to not repeat what others have said better and before me, I
will stay short, and I'll leave you with references to people,
conferences and organizations that are dedicated to this, to analyze
in detail the different aspects of the subject.
IMHO, there are two things that prevent us from reasoning how we can
benefit (financially among other forms of "benefit") from Open Source:
1. the fact that when we talk about Open Source, we usually think
about software,
2. and, that we don't talk about what we mean with terms like
"success" and "sustainability"
(1) But, software is about people: We build and create software to
make certain aspects of people's life easier; it is always about
adding value to other people. Open Source empowers the users to take
part on the decisions made for the evolution of the software. This is
the big differentiator between closed-source and open-source projects.
Closed-source projects have users, while open-source projects have
communities.
The foundation on top of which a successful open source project
builds, is not the service or product, it is the community. In
closed-source companies, what has value is either the product, or the
(almost always, private) data that the product has collected. In
open-source companies the value is not on the product itself, but on
the relations between the company and the users. The investment should
be in maintaining this relationship, building trust, while the product
evolves both from the core-dev team and the community, with respect to
the community.
Now, this is a hard goal. People are difficult, and in the modern
world even more. Competition is high, deals will almost always benefit
the closed-source companies and the risk of working in the open is
higher, precisely because control is not in your hands. However, it is
not impossible. There are many organizations out there, big (some very
big) and small, that have succeeded. And this is where (2) comes in.
Taking into account (1), expectations must be adjusted to the
difficulties of the reality of Open Source. It is not about marketing
and selling the product anymore; it is about managing communities and
continuously delivering value. It takes time and effort to create a
robust, high quality codebase and userbase, it takes time and effort
to convince people you are serious about what you do, and it takes
time and effort to create and maintain relations (not just deals.)
Time is a very important factor, because it is a limiting factor that
you cannot avoid. It has direct implications on the scale an Open
Source business can have. It is unreasonable to compare Open Source
companies to companies like Microsoft, Google, Facebook, Amazon or any
other giant out there (not just because of the different business
models, but also because a big part of the value comes from the data
collection as well as the data control these companies can exercise.)
So, we must define what "benefit" and "success" mean in the context of
an Open Source business. What is a healthy growth rate, and what
indicators do we use to measure it?
I won't go more into this, as this email is getting bigger than the
small paragraph I had in mind when I started writing. I'll close with
some links to related content:
The economics of software
by Bryan Cantrill (CTO of Joyent)
http://dtrace.org/blogs/bmc/2004/08/28/the-economics-of-software/http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-software-redux/
Sustain (un)conference - an event about the sustainability of open
source projects
https://sustainoss.org/about/https://github.com/sustainers
The community-compact - a social contract for open-source businesses
and communities
by Adam Jacob (CTO of Chef)
https://medium.com/@adamhjk/introducing-the-community-compact-431c61ab978fhttps://github.com/adamhjk/community-compact
Sustainable Free and Open Source Communities (SFOSC) - a project and
book (in the making) about building healthy, sustainable open source
communities and businesses - guiding principles, business model
definitions and social contracts (like the community-compact above.)
https://medium.com/sustainable-free-and-open-source-communities/we-need-sus…https://sfosc.orghttps://github.com/sfosc
Finally, some notes on the recent discussions on some open-source
projects re-licensing as a way to make money (see Redis, MongoDB,
CockroachDB, etc):
The tragedy of the commons clause
https://redmonk.com/sogrady/2018/09/10/tragedy-of-the-commons-clause/
Open source confronts its midlife crisis
http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-its-midlife-cr…
A EULA in FOSS clothing?
http://dtrace.org/blogs/bmc/2018/12/16/a-eula-in-foss-clothing/
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hello everyone,
Going forward, one of the things we need to do is to revisit how
micro-services are structured. This is a big task, for which there
have been previous discussions on the mailing list and related github
issues. Those discussions mainly focused on splitting the
micro-services out, into a separate repository. While, this was given
a shot, it didn't work quite smooth.
With this email, I want to set the high-level requirements for a
plugin architecture which will help with separating the
micro-services, but also frontends and backends, to their own
packages, and make it easy to plug-in more micro-services, frontends,
backends (or other types of plugins).
Currently, the Satosa repository contains the core of satosa, the
supported backends, the supported frontends, and some micro-services.
Ideally, the satosa repository would contain only the core component.
What I want to do, is have each backend, frontend and micro-service be
its own package. These packages can then specify the desired
dependencies, their example configurations, documentation, as well as
installation and deployment instructions. Finally, the individual
plugins, can be developed and updated without the need to change the
core.
And, we can almost do that. We can separate backends, frontends, and
the micro-services out - not to a grouped repository (ie
"micro-services repository"), but each of those plugins to its own
repository and python package. There is little work that needs to be
done to enable this, mainly to decouple the core from two
micro-services (the CMservice and AccountLinking, that have special
requirements hardcoded).
But there is more than separating the plugins out. Separating the
plugins enables us to specify the control we want to have over the
provided functionality, the way certain aspects of the flow take
place, how state is managed, etc. By defining what a plugin is, we can
treat frontends, backends and micro-services in a uniform way.
A plugin is an external component, that will be invoked by Satosa at
certain points of an authentication flow. We need to _name_ those
points, and have plugins declare those in their configuration, thus
deciding when they should be invoked (and if they should be invoked in
multiple points). At different points in the flow, different
information is available. Plugins should be provided most of the
available information in a structured manner (the internal
representation).
Right now, we have four kinds of plugins (which can be though of as
roles), invoked at specific points of the flow:
- frontends: invoked when an authentication request is received
- backends: invoked when an authentication response is received
- request micro-services: invoked before the authentication request is
converted to the appropriate protocol
- response micro-services: invoked before the authentication response
is converted to the appropriate protocol
I'm not certain that this separation is the best; I can see the need
by some micro-services to know more than just the internal
representation of the available information. This can be solved in two
ways: introduce more points in the flow where a plugin will be invoked
and hope this point is better suited for the intended purpose, or,
enumerate what that needed information is and provide it in a safe way
- the example I have in mind, is a situation where a micro-service
needs to select certain SAML attributes to generate an id, but the
available information is limited to the internal attribute names,
which introduces an indirect coupling.
When talking about invoking external components, we usually think in
blocking terms. This, however, may not always be the case. Examples
include the need to do heavy IO operations, or invoke another service
over the network from which we do not expect a response (ie, send
logs, stats or crash reports to a monitoring service). For such cases,
we may want to set a certain plugin to work in async mode.
There are also cases, where we do expect an answer from an external
service, but this may come at an undefined time in the future and does
not interfere with the current flow. For these cases, we need to keep
some kind of state. This is now done in the form of a frontend channel
(ie, a cookie). What I'd like is to make this explicit and available
to the plugins as a module/function that handles state in a uniform
way.
Moving over to this structure will allow plugins to be much more
flexible. But there is still an issue hidden there. If we have plugins
as separate packages, developed and updated independently from the
core of Satosa, we also need a way to signal Satosa that such a
package has been installed, or updated and should be reloaded. This
will affect how all plugins are initialized and loaded internally, and
most probably it will affect how Satosa itself is initialized.
Along with that work, intrusive work needs to be done in error
handling and logging. At the moment, errors end up as plain text
messages (usually not that helpful) in the browser (which wraps the
text into basic html) and the logs. This needs to be change in the
direction of structured error messages. Logging will also change
towards that direction. Since, the logs will contain this information
in a structured manner, the same payload can be returned as the error
message. I would like to have messages structured in JSON format (most
probably), with context, data and a backtrace included among other
information (such as timestamp, hostname, process-id, src-map,
request-id, and more.) Provided this information, another process (a
frontend/error-handling service) can parse it and present the user
with the appropriate error message.
The structured logger and the error-handling service should be part of
the parameters that initiaze a plugin. The plugins should make use of
them, in order for the service to have a uniform way of handling these
cross-cutting concerns.
The library I'm looking into, to take care of the log format is structlog:
https://github.com/hynek/structlog
Other things to look for in the future, is grouping and high-level
coordination work between plugins in the form of invocation
strategies. Given three plugins, I want to invoke them in order, until
one succeeds with returning a result. Or, I want to invoke them in
parallel and get an array of results. Or, I want to invoke this plugin
that does a network operation, and if it fails, I want to retry 3
times with an exponential backoff.
To sum up, this was an (non-technical) overview of the things that I'd
like to do in relation to the "plugins". For some of the above, the
technical parts are still under consideration. There are more things
to be done for Satosa, both technical and not which I hope to write
down, discuss and do with everyone's help and suggestions.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
