Homepage Update

[tombh]

When I read about Rosehub (Google's auto-PR bot for patching vulnerabilities) on Hacker News and saw how well received it was, I thought, "but libraries.io is all that and more". Yet a newcomer to the homepage would know that neither from a glance, nor a longer read.

So updating a homepage is a big thing, it's the primary symbolic totem expressing and conserving the vision and essence of a project. Its success is therefore dictated by a preexisting expression of those values -- the homepage does not create them. So discussion about this issue is more than just logistics, it's an exploration of what's most meaningful about libraries.io to you.

Personally I would argue there are some easy and obvious changes that could be made, all based around the fact that libraries.io is not just an, "Open Source Discovery Service". For example:

• "be notified of new releases" -- should be an independent statement, its own sentence.
• The API, license compatibility checking, "Help Wanted/First Pull Request" and Bus Factor features should all be above the fold.
• Make lib2issues a toggleable service for every repo and advertise this above the fold. (There's a bigger, but separate, conversation here about doing what Rosehub does but on a much more comprehensive scale, personally I think auto-PRs should be opt-in, not opt-out.)

But there are some bigger questions that I might venture to propose, namely regarding its prevailing identity as a discovery service. To give a concrete suggestion, what if libraries.io strapline was, "Open Source's Immune System" (I don't think this is actually a good idea, it's just something to work with). From it we get more of an immediate view into the grander and altruistic vision of maintaining and improving the overall health of open source software. However it leaves out the discovery features, so perhaps a strapline in between would work.

Here's a reminder of the vision from the About page:

Our goal is to raise the quality of all software, by raising the quality and frequency of contributions to free and open source software; the services, frameworks, plugins and tools we collectively refer to as libraries.

So anyway, the point is, yes there are some quick wins to improving the homepage, but there is also the fact that libraries.io could possibly benefit from shifting the centre of gravity of its brand identity. Let me suggest some actionable tasks:

• Identify consensus on strapline/core vision, does it need changing?
• If so, to what?
• Identify the minimal core features that should be above the fold.

[andrew]

@tombh agreed, Libraries.io does a lot of things and the homepage fails to highlight most of those.

This issue probably needs breaking out into a few separate things too, lib2issues and lib2slack should probably be pulled into the core service as you said, I've pulled that out into an issue here: #1251

The bigger question around what Libraries.io is and should be is a tricky one, for me there's a few layers to it, some of which the name "Libraries.io" doesn't really match:

• At the bottom of it all you have the dependency graph of all of open source, connecting the dots between source code repositories and projects published on package managers, this is the enabler to everything else
• Search and Discovery services so can find useful open source code to help you solve a problem, no-one else is doing a good job of this for software (not just open source libraries)
• Tools for reviewing and managing dependencies of your software project, this is something that Dependency CI was designed to do on top of the Libraries.io API as it's got a much clearer enterprise business model
• The data in Libraries.io is also really good for helping to build sustainable Open source infrastructure, which is what drew @BenJam into the project

The could all be separately named things that are heavily linked but individually described but the discovery aspect which is how Libraries.io was originally designed, is what brings in the majority of the people to the project right now, and is personally the area most interesting to me.

Part of me thinks the whole thing needs a new name and overview but another part feels like all the tooling should be pulled out into Dependency CI.

I'm going off on a tangent here, but yeah we should burn the homepage to the ground and have a better overview of the things it currently does and is starting to do.

[BenJam]

@tombh these are all excellent points and (to my own fault) I have not been forward enough with some of the changes that I would like to make to the homepage.

That said I generally prefer to start from base principles thus issues #1127 and #1177. I've also been gathering a little more data regarding the use of the homepage and the project pages in #1241. All of this is basically to provide evidence to support or contradict my views. But I might as well share them as they are today:

Name and Strapline

I think we're too far in to do a name change at this point, but we're not beyond separating concerns and rebranding part of the service if need be. Of course there's a balance there about audience, marketing and promotion but we should not forget we also have DependencyCI.com too.

I think "Open Source's Immune System" is very forward, to the point of arrogance, but understand you're just trying to stimulate debate. Elsewhere (inc. the About page I recently updated) I've used "Helping you make more informed decisions about the software you use" as this encompasses the discoverability and maintainability angles covered in the strategy.

By the by, I think that the 'sustainability' side from the strategy doesn't need to be obvious, it should be a bi-product of the services that Libraries.io/DependencyCI et al provide. Sustainability is the goal, discoverability and maintainability get us there IMO. Experiments (using Libraries.io data to do things like #1019 and #1135) will highlight just how valuable the data can be. IMO there are only a handful of organisations working on this across the whole of open source and I would prefer to speak with them to ensure we can establish a working group.

What is Libraries.io

I'm very glad that @andrew has said:

another part feels like all the tooling should be pulled out into Dependency CI.

To me, Libraries.io is a 'discovery' service first and foremost. It's about gathering data on projects from multiple sources, combining it in useful ways and making some assertions (i.e. sourcerank) about which projects are best avoided.

For users it's about finding a project, vetting it and (perhaps) marking it somehow for consideration in a later project. #20 and #76 could be very valuable for individuals and other users alike and I prefer this sort of interaction rather than maintainer-type interactions on Libraries.io

What is DependencyCI.com

To me DependencyCI.com is a more logical home for many of the maintainer-type features. I also think that adding the features from Libraries.io for maintainers to DependencyCI.com for free will help lift paid-for tiers on private repos, the revenue from which supports Libraries.io. There is the issue that DependencyCI.com is (currently) a closed-source system. Personally I don't think this is a massive issue if the features are basically utilising the Libraries.io API and it supports FOSS for free.

The reality of the situation

@andrew and myself are committed to delivering a fair whack of features to our supporters and as such we don't have the runway to embark upon a large refactor of two codebases to move features across. That said, I am spending March doing some groundwork on DependencyCI.com and that might turn into an opportunity to do this.

If that doesn't amount to anything then I think we should put some time into the homepage to be clearer about the features available to maintainers while we rely on Google et al to bring people to individual project pages (see stats in #1183).

[tombh]

Wow, so many thoughts and links. I have a better idea of what's going on, thanks. Let me see if just summarising what's been said, rather than adding any new ideas, helps.

I think the personas issue (#1127) is the most illuminating context to all this. So we have;

• Google: exposing libraries.io to the world through the most popular search engine.
• Searcher (the one Andrew finds most interesting) : what library/framework should I use!?
• Producer: is my project using the latest dependencies, are there any vulnerabilities, are the licenses ok?
• Maintainer (crosses over with producer I think): who's using my library/framework?
• Extender: using the huge trove of libraries.io data for perhaps completely new ideas.
• Overlord: has a big company perhaps and does a lot of the above at the same time.

To add my personal opinion, it seems there are 2 centres of gravity: searcher and producer. All the others seem to be flavours of these 2.

So the the idea of completely changing libraries.io name is up in the air. That seems like a big thing. However, unlike traditional name changes, there is a sibling in the ranks: dependencyci.com Ideally, if time wasn't a factor, then the more dependencyci.com-orientated features would migrate there, leaving libraries.io's name less encumbered with less libraries.io-esque features.

Edit: It occurs to me that searcher and producer are like libraries.io and dependencyci.com personas respectively.

[BenJam]

nodding

[tombh]

So the theme that's been going round my head is: why are libraries.io and dependencyci.com separate sites? I'm not fully aware of the specific details, so I'm sure many of my musings here might be obviously irrelevant. Nevertheless, for the sake of discussion, here's my outsiders perspective.

My immediate answer to the above question is simply that libraries' identity is firmly non-profit, such that its financial status (as a donor recipient) requires it to not engage in profiteering. This is a hard line in the sand. However, by the same token, libraries.io data and code is open and public, so dependencyci.com, as a separate entity, can conveniently piggy pack off the existing knowledge base cultivated by libraries' developers to bring extra, supporting funds back into libraries.io. Please correct me on this, as what follows is based on this assumption.

Money in open source is big topic. I'm not employing a literary gimmick by saying: money is a dependency in the same way a project's packages are. This inextricable relationship is relevant for 2 reasons; developer's time and corrupting influence. The first reason: developer's need to eat and pay the rent, if a company isn't paying them to work on open source, then they must do so in their, frequently brief, free time. This should be a concern to all those leaning on open source software -- therefore most of us and especially libraries.io with its vision of improving the quality of open source software. Unfortunately, even when ample incoming finances are
available, the cost to the software is heavy-handed conditions, often at odds with the direction of the project. Infamously, even with the best intentions, money's primary concern eventually comes to bear -- namely the desire for more money. It is largely for this latter reason that I suspect libraries.io is understandably non-profit.

So dependencyci.com exists as a hermetic layer, separating the distinct concerns of money for food and money for profit. However this abstraction comes with the cost --both technically and symbolically-- of a strain on the DRY principle. As any seasoned developer will know
the occurrence of the second (third, fourth or tenth!) repetition of non DRY code is not always obvious. Clearly dependencyci.com time distracts from time that could be spent on libraries.io, that's a given. But what of the more subtle dilutions of efficiency? How often do thought processes need to be prefaced with, "does this apply to the other project?" Or to personify the personas; searcher and producer: how much harder is it to engage in 2 distinct by connected conversations with 2 people rather than one?

Of course patterns, like DRY, are not hard and fast -- with explicit, and hopefully evidence-based justifications then pragmatic exceptions are actually better than painfully principled and convoluted attempts to follow rules to the letter.

So would it be useful to revisit these 3 points:

1. libraries.io should make every effort to avoid the influence of profit. Is this absolutely a 100% uncrossable line in the sand? To add yet another perspective, would it not contribute to the wider conversation if the libraries.io brand publicised its process around money -- setting a precedent for a realistic and healthy relationship to money?
2. dependencyci.com is a manageable and impermeable barrier separating libraries.io from the potentially corrupting influence of profit. This is just a conversation, so purely hypothetically, how would it feel to just have one brand, one code base and one thought process?
3. The DRY pattern can be ignored in clear and unambiguous circumstances. Specifically how much money does dependencyci.com need to make? Or is it just a matter of, "it's nice to have some money on the side just in case."

[BenJam]

These are all incredibly pertinent and important points which I am acutely aware of (as I wrote about in this blog post). I have answered the questions below but in response to some of the context:

Libraries' identity is firmly non-profit, such that its financial status (as a donor recipient) requires it to not engage in profiteering. This is a hard line in the sand [...] Please correct me on this.

This is correct, but it does not stop Libraries.io as a 'project' having a trading arm that is a registered legal entity for the purpose of generating revenue and donating it to the the project (currently through Brave New Software but in the future directly).

Money in open source is big topic.

Indeed, and it is something that we are actively exploring and engaging with, in order to better understand how these influences exert themselves, and how projects can insulate themselves against those influences. Libraries.io (and by extension Dependency CI) is a type of practical experiment in this way. It is no secret that one of my goals is to establish a solution or number of solutions to help solve the 'tragedy of the commons' effect on open source and address some of the issues in @nayafia's report for the ford foundation.

So dependencyci.com exists as a hermetic layer, separating the distinct concerns of money for food and money for profit.

Almost. I see Dependency CI as a commercial service that can sustain a free utility. How it does so and what exactly that utility service should be are up for debate but in principle both services will be free for open source projects as they share the same over-arching goal.

Clearly dependencyci.com time distracts from time that could be spent on libraries.io, that's a given.

Under the terms of our funding we are not permitted to work on DependencyCI. However we believe we are able to use some of the unrestricted support from Ads to do a small amount of work on this. Mainly looking for partner(s) to incubate it.

How often do thought processes need to be prefaced with, "does this apply to the other project?"

Currently very little. But as per my previous comment it is in the back of our minds whether a truer reflection of the goals we have set ourselves (and that we have from funders) would be better served by porting maintainer features to Dependency CI.

And now onto your questions:

1. libraries.io should make every effort to avoid the influence of profit. Is this absolutely a 100% uncrossable line in the sand?

It's naive for us to imply that we can remove the influence of money and perhaps by abstraction 'profit' too.

Principally Libraries.io is a free utility service, and it will stay that way, but we must also appreciate that we are a microcosm of the wider issue in open source. Some will profit from the hard work of others without contributing anything in return. Where this causes undue strain on the project I am not beyond putting in place measures to ensure something is contributed back.

2. hypothetically, how would it feel to just have one brand, one code base and one thought process?

Personally I think separating the concerns of the maintainer and the searcher will allow each to better focus on those things but in principle there's nothing stopping us operating one code base, one 'brand' and still having two entities for the purpose of running a charitable organisation and another organisation that is a considerable donor, a la Mozilla Foundation and Mozilla Corp.

3. Specifically how much money does dependencyci.com need to make? Or is it just a matter of, "it's nice to have some money on the side just in case."

Here's an actual line in the sand: Libraries.io will not be sustainable at its current level if it is dependent upon grants, donations or sponsorships 'in kind' (hosting etc). For me, the goal is that Dependency CI can pay its own way and the costs of Libraries.io. These costs will not necessarily include @andrew or myself. I suspect there will be a point where it can be put into maintenance-mode, but not for another 1-2 years.

[andrew]

Fun fact, both Dependency CI and Libraries.io are generating enough to pay for their own hosting costs atm so they could go into maintenance-mode right now

[BenJam]

Moving this into May milestone as I'd like to make modifications alongside tickets like #1366