And now, for a break to start to tie together the whole Ecosystem picture
Start the Ecosystem Discussion!
My dear guests. I'm Jonathan, your host. Welcome to Open Source Monday!
It feels like that, a little bit. Open Source is one part code, one part idealism, one part friendliness, and one part getting out the door. Mix all that up with different people, who need different things, and have different ways to release it and different goals.
It's a little like herding cats.
But it's also great, because when it works, everyone gets what they want. Even better, we usually get more than we put in. And so, welcome to Fantasy Island!
Big, small, and off-property
in the previous blog posts, I have discussed
UI5,
Chevrotain, and the
Eclipse jGit projects. Each one of these are great projects, and I could write entire blog posts about each one, how they work, and what they do.
Of course, we already have many blog posts about just that, and I would be repeating myself.
So, my goal was a little more circumspect. I am using each of these to demonstrate a different aspect of our Open Source commitment at SAP. These three each represent a different part of the total package:
- Big projects, with lots of independent support, and a large organization
- Smaller toolsets, run by a dedicated group at SAP, to help solve specific problems
- Third-party contributions, as part of a greater whole project to move the industry forward
And there are more different flavors. To make my life interesting, the flavors often mix together, and therefore they aren't easy to categorize. Here are a few we haven't discussed yet:
- Different size projects, from full frameworks down to small pieces of functional code
- Samples that support blog posts and other presentations
- Templates for jump starting development by our customers
- Add-ons or plug-ins that enable other tools to use SAP software
- Offshoots from our internal research - often released to see what and where the idea could go
And on, and on, and on
Here is the important thing about everything we are publishing: it's because we believe in giving back. And so we publish large, small, influential, and not. Some try, some fail.
In some cases, some just die.
That's OK. That's how the entire thing works. There are no one-size-fits-all strategies, and no one-size-fits-all ways to do anything in our Open Source system. And so we have a very complex, overlapping set of strategies and systems we use to support this entire ecosystem.
Which goes back to something I said before. It's an ecosystem. Not a monoculture. That's because ecosystems thrive when monocultures die off. Just like our friends in environmental science, we are doing something very similar here.
So let's take an introductory look around at what that means.
Planting the Seeds
The first thing that we are doing at SAP is encouraging our internal developers to think about publishing. Blog posts, classes at Sapphire and TechEd, or just some stuff they talked about in a workshop.
Along with that, we have a group of dedicated individuals here at SAP who focus on helping Open Source in the company. This group has a focus on helping open source projects - especially the larger stuff - be considered in planning, learn about working the world of Open Source, releasing, and maintaining.
That team, by the way, isn't just doing that. Open Source is a two-way street. The very same people also think about how we bring Open Source in to our organization - and how we can use it effectively inside SAP.
I think, in two paragraphs, I just made it sound easy. If only it were. We just download the source and start to use it, or upload it and publish it, right? No way.
We spend a lot of time thinking about the details. Can we use the software? Is it safe? Does the license even allow us to use it? What if we want to include it in our for-sale software? (And that's just the tip of the iceberg. Know what CopyLeft is? What's the difference between GNU and Apache 2.0? Oh, yes, it's always the details.)
On the outbound side, it's also complex. Before the software even goes out the door, and then after it does as well.
Getting ready to release
Before we publish anything at SAP, we want to make sure it's ready to go. Our open-source has the same problem. It's similar to our everyday publication release cycle - lots of testing, lots of bug fixes.
There are, however, a number of new things that happen when we release Open Source. Because it's not the same as our commercial channels. And so each piece of Open Source code goes through a team at SAP who helps clear up those quality, legal, and procedural issues that need to be covered before we give it an official "OK" and send it to you.
For example: Does the code have any testing built in to it? If so, we need to document that. Using any other open-source libraries? We need to check those licenses, and see if we can publish them again in our new repository. What about the documentation? Is it up to date? (Does it even exist? If you are laughing, you are a software engineer.
🙂 ) And so on, and so on.
I'll cover this entire process, in further detail, in a few weeks.
Let's just say, it would be much easier to just hit the button on Github and say "publish"! But if we did that, we wouldn't be doing a great job for you, the end users. And so we take the time to do it right.
Keeping it healthy
Once we release a piece of software, we also need to keep it healthy. Open Source doesn't have anyone paying us to do support, so we need to think carefully about how support is provided, and why.
Some open source is provided "as-is". Sorry, no fixes. While other projects have a team behind them, who want feedback and respond to bug reports and answer questions both here (and on StackOverflow, for sure). Both are OK. The key is to tell the developer exactly what they are getting in advance, and so they know what to expect.
The other thing is that software is always changing. A lot of our projects need to update themselves to keep current with the latest technology. Now, the projects might be fully staffed. Or they might be volunteer, in spare time. Or some other combination. We talk with the projects to ask them "what are your plans?" There are no forced timelines, just an open dialog.
And that brings it to the most important part (which I already mentioned in the "what support" section)? We help the projects
communicate with the users. Because open source, even more so than our for-sale projects, needs good information.
And yes, if you are thinking "you have to push engineers to write documentation" you are EXACTLY correct. What fun, right?
Letting it die
And sometimes, it just doesn't work out.
Open Source can, and does, eventually fall static. It could be that the project isn't necessary anymore, or the technology has outgrown it. Or, it could be that the developers don't have time, or have left to go do other things.
In a lot of cases, we have to plan for that too. What happens when it all goes dark? Do we leave the project on the site, as an archive, or do we take it down?
And, if the project is suddenly found to be unsafe (but has no more developers), what then?
Planning is key - and we think about it all.
Growing the Garden
In a lot of ways, running Open Source is like growing a garden. Plant seeds, help make flowers, fruits, and vegetables, and then harvest and plow everything under for the next season.
It's a whole world of stuff. And for many, who just use the software, they see only the the most important part: they get to use it. Just like my friends come over and eat my vegetables. They always like them.
If you are a regular user, the rest isn't very exciting. But it's important to know it's all going on, and that people are paying attention. Because the end result is more than just the effort of writing some code and hitting "Publish".
Thanks for stopping by Open Source Monday. Looking forward to seeing you next week!
