Weighing in on Drab and reflections on longevity of software libraries

Continuing the discussion from Drab and Liveview community oddities:

Everything else aside, this kind of off-the-cuff declaration alone would make me wary of ever using this library. I develop Elixir/Phoenix applications professionally, which means that when I choose a technology or library I need to be confident that what I am building will have some degree of continuity.

For me if a library’s author is ready to jump ship on his library based on a vaporware feature shown in a demo during a conference talk, there is no way I can trust that the library is taking itself and its existence seriously. I cannot professionally justify a decision to get behind a library that could be abandoned on a whim.

There will always be other options, as @josevalim says. A free market does not mean that the things we do are insignificant or useless just because someone else comes along and tries a different approach. That mentality shows a severe lack of marketing understanding.

So it seems to me, not having looked at the Drab library at all, that the two greatest challenges that this library faces are: (1) a dedicated core team that believes in the mission, (2) a lack of marketing understanding about how to stand out and create something remarkable.

Being first to market is not enough. Creating something that is useful is not enough either. In a world is filled with a million choices and the question we are left asking ourselves is, “Why would anyone choose me”.

For example, I don’t love the Ruby-approach to web development that I get with Phoenix, but I love the team’s dedication to the project and so I choose make a compromise for a product that offers extremely intelligent and highly motivated individuals building something that they love and believe in. And if LiveView is released I will use if because I know that it is built by the same people with the values that I trust to ensure that the software that I build my products upon is continually supported and of the highest quality.

While it is totally your choice to not use a library because of the discussions in this forum, note it is open source. It comes with no warranties and you can always maintain it if you have to.

Furthermore, going back to the closing argument of the thread you linked to, don’t forget maintainers are humans too. Authors will have good ideas and bad ideas. It is the job of the community to step in and support authors and their teams or change their mind. Saying you are not going to use a library because of a statement an author said in a thread and later retracted it, gives the impression you are expecting authors of open source libraries to be flawless and make no mistakes. This attitude may actually have a negative effect and cause authors to avoid joining discussions, as their words might be taken as final instead of being part of an on-going conversation.

So I recommend you to reconsider your position. And if there is a project you consider to be essential to you, ask yourself what you can do to help its longevity, as open source comes with no guarantees.

13 Likes

I develop Elixir/Phoenix applications professionally, which means that when I choose a technology or library I need to be confident that what I am building will have some degree of continuity.

If you’re using open source professionally you have a few options to minimise risk.

  1. Pay for its ongoing development
  2. Use a version of it that is feature complete for you so that updates are bonuses not requirements
  3. Develop the competency to maintain it internally.

Ideally you have #3 in all cases since you never know when disaster will strike a maintainer regardless of how committed they are.

I cannot professionally justify a decision to get behind a library that could be abandoned on a whim.

All software can be abandoned on a whim, even ones with expensive maintenance contracts. External dependencies are inherently risky in that way but are usually still worth it to avoid NIH.

3 Likes

I see my post as part of the ongoing discussion, and I do not believe that authors are flawless robots that do everything perfect.

I realize that the reflection that I bring may come off as blunt, and that is because it is meant to be direct, but in no way is it meant to discourage. The reason that I wrote the last two paragraphs was to illicit a sense of what could be possible for the author,

  • What if there are two competing libraries?
  • How could one differentiate in a crowded marketplace?
  • What makes the work that they are doing different?

Those are non-technical questions from a perspective that is decidedly not meant to be technical, but just as important.

So to be clear this is me, supporting by opening a dialogue which I have clearly seen is needed from what I read on the previous thread. This is me saying,

  • “Hey, some people are thinking about your product like this.”
  • Some people have these needs
  • Some people see the world this way
  • Some people who need this library professionally might be wary of reading a statement like that from the author as a response. And, it is perfectly okay for them to feel that way.

The attitude may also have the effect of reflecting that the work that the author is doing is useful to people and needed, and that it might be worth restraining statements that may need to be retracted later and instead explore what opportunities this opens.

If someone wrote a new functional programming language that compiled to beam bytecode and your response was, well I guess Elixir is doomed, I would feel very uneasy about the future of Elixir.

One thing that is happening here is that someone in the community (me) is providing feedback about the experience that they had when reading these words. That might be valuable to some people. Sometimes it is worth listening to what makes people feel uncomfortable.

I do understand your point. You are saying that others could think the same as you did and such could be detrimental to the project. Therefore, it is important for him to know about such feedback. However, I believe that whoever sees projects under those perspectives should change, and not the author.

Tomek has put months of work in Drab, writing code, helping people, fixing issues, listening to feedback, etc. Why is something that he said during a period he was probably uncertain about the future of the project (and that he later retracted) taints all of the work he has done so far?

Finally, I did not meant to imply that you believe all authors to be robots. Written communication is hard. :slight_smile: Could Drab improve its marketing message? Probably yes. Even Elixir itself could improve on this area. But there is likely better ways to start this conversation instead of building on top of a previously closed topic (as in @AstonJ’s comment earlier). Feedback is important and how we give this feedback is equally important. If you believe the feedback may make people uncomfortable, then you have even more reasons to consider different ways to approach the topic.

1 Like

Continuing discussion of a closed thread.