Announcing Rome Tools, Inc.(rome.tools)
rome.tools
Announcing Rome Tools, Inc.
https://rome.tools/blog/announcing-rome-tools-inc/
89 comments
Healthy skepticism is good. Dev tools are hard.
There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out.
JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.
There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out.
JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.
> There are hundreds of open source companies - many making gobs of money.
[citation needed]
It seems there may be many open source companies with tons of users, but they seem to struggle with monetization and turning those users into paying users.
Redhat which used to be the epitome of a company making money from open source got acquired by IBM.
A lot of other open source companies are switching to non-open source licenses.
[citation needed]
It seems there may be many open source companies with tons of users, but they seem to struggle with monetization and turning those users into paying users.
Redhat which used to be the epitome of a company making money from open source got acquired by IBM.
A lot of other open source companies are switching to non-open source licenses.
Even though a company's software might be open source, the company does own the intellectual property of the open source project. It chooses what license under which the software should be offered and has the freedom to commercially exploit the software in ways that nobody else can.
That being said, a compiler toolchain is not so easily monetized as something like Grafana, which has obvious enterprise features that need filling in and which can be hosted as a cloud service, generating revenue that way.
I imagine the team has ideas for monetization, otherwise they would not have raised $4.5M from some top shelf venture capitalists. I would like to know what those ideas are.
That being said, a compiler toolchain is not so easily monetized as something like Grafana, which has obvious enterprise features that need filling in and which can be hosted as a cloud service, generating revenue that way.
I imagine the team has ideas for monetization, otherwise they would not have raised $4.5M from some top shelf venture capitalists. I would like to know what those ideas are.
34 billion dollars doesn't count as gobs of money?
OSS Capital, which participated in the Rome Tools, Inc round, has compiled a list which includes commercial open source companies, revenue estimates, and how much VC raised: https://docs.google.com/spreadsheets/d/17nKMpi_Dh5slCqzLSFBo...
this team also has had at least one example of unilateral non-open source decisionmaking https://www.vice.com/en/article/pawnwv/open-source-devs-reve...
Is it a given that because the software is open-source, the decision-making will be, too? Almost seems there should be a separate set of claims for what the decision-making process will be (like how there are various software licenses).
From the article:
> Eric Raymond, the founder of the Open Source Initiative and one of the authors of the standard-bearing Open Source Definition, said Kyle’s decision violated the fifth clause of the definition, which prohibits discrimination against people or groups.
> Eric Raymond, the founder of the Open Source Initiative and one of the authors of the standard-bearing Open Source Definition, said Kyle’s decision violated the fifth clause of the definition, which prohibits discrimination against people or groups.
Okay, so the issue wasn't decision-making, then, and you agree with the parent comment that open source need not have open decision-making?
The Rome license will stay MIT.
Linus is probably a tie-breaker, and thus a unilateral decision maker for Linux when necessary too. What's the problem?
> Dev tools are hard.
That's true. The market is small and price-sensitive.
That's true. The market is small and price-sensitive.
Over at r/javascript, Sebastian mentioned the business model would be based on providing services. He mentioned things like code quality monitoring and remote cache, so it sounds like it's up the alley of CI/CD cloud platform offerings.
Does seem like quite a departure from the original premise of Rome, but it seems like a sensible strategy. FWIW many companies easily spend 6-7 figures on CI/CD per year, so there's definitely room to carve out a niche there.
Does seem like quite a departure from the original premise of Rome, but it seems like a sensible strategy. FWIW many companies easily spend 6-7 figures on CI/CD per year, so there's definitely room to carve out a niche there.
It's not a "JavaScript library" it's an entire toolchain. In the same way that `git` generated billions of dollars worth of value in the form of companies and productivity, Rome will do the same. Possibly even bigger.
I have no doubt that Rome will massively increase the producitvity of thousands of companies and developers. But the hard thing in open source is how will you capture some portion of that value. The vast majority of libraries, toolchains and other open source projects out there which has massively increased the developer producitivty are underfunded let alone generate millions of dollars in sales. Rome not only has to find a sustainable way for funding the project as well as figure out a way to 100x the returns of VCs? How is Rome planning to do that?
> I have no doubt that Rome will massively increase the producitvity of thousands of companies and developers
I would like to see that measured.
My suspicion is that many developers are already too reliant on tooling and that reliance harms productivity rather than improves it. Bundling those tooling concerns eliminates some operational costs associated with a plurality of tools but increases dependency upon the tool.
This problem is not a technical problem (as in how do I solve a problem), but a cultural problem (as in what is the proper way to solve a problem). It comes down to the difference between a product focus (what do we ship) versus an operational focus (what do we work on).
I would like to see that measured.
My suspicion is that many developers are already too reliant on tooling and that reliance harms productivity rather than improves it. Bundling those tooling concerns eliminates some operational costs associated with a plurality of tools but increases dependency upon the tool.
This problem is not a technical problem (as in how do I solve a problem), but a cultural problem (as in what is the proper way to solve a problem). It comes down to the difference between a product focus (what do we ship) versus an operational focus (what do we work on).
I think you're being very selective with what you call "tooling" here. I understand where it's coming from though, and I agree that in some circumstances people are adhering too much to what might be perceived as "standards" instead of building or using something more fit to the task.
On the contrary I would also say that I see a lot of developers not being reliant enough on tooling. A simple example is getting very acquainted with the debugger in your language of choice. It's very common to sprinkle logs everywhere instead of properly learning how to step through code.
On the contrary I would also say that I see a lot of developers not being reliant enough on tooling. A simple example is getting very acquainted with the debugger in your language of choice. It's very common to sprinkle logs everywhere instead of properly learning how to step through code.
I mean tooling as generally as possible, everything outside your application's execution runtime and the shell it runs in. Of course developer's will benefit from a code editor and a language compiler (assuming there aren't many), but how much tooling do you really need to deliver a product?
> How is Rome planning to do that?
Clearly they have a vision that investors thought was compelling enough to buy into.
Perhaps be patient and see what they announce in the future? This is their day one (zero?)..
If there was an easy answer here, someone else would have already done it.
edit: they (sort of) answer in another thread https://news.ycombinator.com/item?id=27039330
Clearly they have a vision that investors thought was compelling enough to buy into.
Perhaps be patient and see what they announce in the future? This is their day one (zero?)..
If there was an easy answer here, someone else would have already done it.
edit: they (sort of) answer in another thread https://news.ycombinator.com/item?id=27039330
Yeah. I geuinely hope they work it out. And hopefully more open source projects can follow their playbook.
git doesn't make linus torvalds money though.
People used git because it was mandated for linux kernel work.
People used git because it was mandated for linux kernel work.
To your second point, I remember when git was announced. I remember it was such a breath of conceptual fresh air over what I had been using (svn, mercurial) for me. I use it because it makes a lot more sense to me and how I work, and I've never worked on the linux kernel.
never used it, but afaik mercurial is basically git's doppelgannger - functionally they are identical. Am I wrong here?
No, doppelganger seems like a pretty incorrect term to choose here.
http://www.rockstarprogrammer.org/post/2008/apr/06/differenc...
http://www.rockstarprogrammer.org/post/2008/apr/06/differenc...
Who is getting rich off "git"?
GitHub, yeah absolutely, but git makes no money because noone pays for git.
Likewise, noone pays for command line package managers (in fact I doubt anyone pays for a command-line tool at all). So its ok to say it generates value, but if you can't caputre that value its not a sound business model.
GitHub, yeah absolutely, but git makes no money because noone pays for git.
Likewise, noone pays for command line package managers (in fact I doubt anyone pays for a command-line tool at all). So its ok to say it generates value, but if you can't caputre that value its not a sound business model.
> In order to support the open source project, we’ll be building supplemental products and services. This aligns our incentives with the community and our open source users, with a focus on interoperability, performance, and usability.
like every open source company, they will sell additional services to companies. When you have millions of users you always find a way to monetize it, even if you think you are just a "javascript library". Redis is just a database, Word is just a text processor, ...
like every open source company, they will sell additional services to companies. When you have millions of users you always find a way to monetize it, even if you think you are just a "javascript library". Redis is just a database, Word is just a text processor, ...
Compiler As A Service obviously. I'm half joking.
I really hope they don't start charging $1 for every time I install Babel through npm.....
After using esbuild and experiencing fast builds, I'll never go back to tools written in javascript/typescript again.
[deleted]
FWIW, sucrase (written in TypeScript) has done a great job of being in the same ordinal of perf as esbuild: https://github.com/alangpierce/sucrase#sucrase
Sucrase "cheats" though[0]:
> Sucrase bypasses most of these steps, and works like this: Tokenize the input source code into a token stream using a trimmed-down fork of the Babel parser. This fork does not produce a full AST, but still produces meaningful token metadata specifically designed for the later transforms.
While this is fine for simple transformations like transpiling JSX, it's not very suitable for full-on AST analysis like some eslint plugins do. Most notoriously, Sucrase is specifically designed to be garbage-in-garbage-out, whereas Babel will throw proper errors on things like early errors.
Tools written in lower level languages like esbuild can take advantage of facilities that aren't well supported in Node, such as cheap concurrent coroutines and greater control over memory layout (Babel ASTs are notoriously megamorphic and can silently fall off perf cliffs depending on how you manipulate them). These caveats are not reflected in Sucrase's benchmark.
[0] https://github.com/alangpierce/sucrase#motivation
> Sucrase bypasses most of these steps, and works like this: Tokenize the input source code into a token stream using a trimmed-down fork of the Babel parser. This fork does not produce a full AST, but still produces meaningful token metadata specifically designed for the later transforms.
While this is fine for simple transformations like transpiling JSX, it's not very suitable for full-on AST analysis like some eslint plugins do. Most notoriously, Sucrase is specifically designed to be garbage-in-garbage-out, whereas Babel will throw proper errors on things like early errors.
Tools written in lower level languages like esbuild can take advantage of facilities that aren't well supported in Node, such as cheap concurrent coroutines and greater control over memory layout (Babel ASTs are notoriously megamorphic and can silently fall off perf cliffs depending on how you manipulate them). These caveats are not reflected in Sucrase's benchmark.
[0] https://github.com/alangpierce/sucrase#motivation
That's single threaded perf, so takes away a huge advantage of Go. Also doesn't include startup time (node is slow to start)
And memory usage.
This feels like a new version of Brunch.
Did anyone use Brunch to build and bundle JS projects and manage dependencies? It seemed like the best thing since slice-bread at the time.
I recently had to go back and update a 6-year-old project that had been written using Brunch. It took several days of painful work to extract it all out of the framework and built it using Babel.
All I'd want to know with Rome is, if and when I abandon it or it gets abandoned (whichever happens first), how annoyed am I going to be that I had chosen this framework? How seamless will it be to extract my project?
Did anyone use Brunch to build and bundle JS projects and manage dependencies? It seemed like the best thing since slice-bread at the time.
I recently had to go back and update a 6-year-old project that had been written using Brunch. It took several days of painful work to extract it all out of the framework and built it using Babel.
All I'd want to know with Rome is, if and when I abandon it or it gets abandoned (whichever happens first), how annoyed am I going to be that I had chosen this framework? How seamless will it be to extract my project?
It’s a difficult, painful problem - meaning there’s an opportunity. Sebastian has the grit to deliver. What’s the business model?
Supplemental services that integrate with the tool. Think code quality monitoring, error reporting, and core enhancements like a remote cache. There's a lot we're going to be experimenting with.
I'd pay for fast remote builds that integrate into my source control (GitHub and Azure DevOps) and creates production builds fast.
I think the future of JavaScript tooling is esbuild and SWC, written in fast compiled languages like Go and Rust. I don't see the value proposition in a brand new toolchain written in slow and memory hungry TypeScript/JavaScript.
you are right but the most common tools are still made with these. I think people don't worry about performance that much. or worry, but they don't make an effort to change that.
You're correct on this to some extent. Teams in our company are so fed up with webpack for local development that they are willing to skip some features it provides to use vitejs.dev for local dev. We fully couldnt avoid webpack 5 because Module federation is very very valuable.
Being written in TypeScript and not Rust seems quite a big liability that might see Rome never be popular or lose out quickly due to inferior performance.
There is already RSLint and SWC as JavaScript tools written in Rust and I would expect such tools to take over, with a good choice of it happening before Rome is ready.
There is already RSLint and SWC as JavaScript tools written in Rust and I would expect such tools to take over, with a good choice of it happening before Rome is ready.
I don't see the relevancy of rust here, but you're right that at this point any language that compiles directly to machine code will blow any javascript tool out of the water any time.
Of course, perf is only one reason to use a tool, I expect javascript based tooling to stick around for much longer because developers are used to them now. And, of course, if all you know is frontend, everything starts to look like a javascript job.
Of course, perf is only one reason to use a tool, I expect javascript based tooling to stick around for much longer because developers are used to them now. And, of course, if all you know is frontend, everything starts to look like a javascript job.
I'd prefer my tools to use languages that are compiled + memory safe. Basically that just leaves rust or go.
But rust also has other features that can help prevent bugs regarding concurrency and more. So rust is a feature in my book and not just an implementation detail.
But rust also has other features that can help prevent bugs regarding concurrency and more. So rust is a feature in my book and not just an implementation detail.
I agree, but there's still plenty of alternatives. Pre-compiling languages like C# and Java will already provide a speed bonus, and with stuff like GraalVM's native images and Kotlin native you can squeeze even more performance out of these GC'd languages.
At this point in time, improvement comes from "anything faster than node". Hell, you might even manage to get a performance benefit out of PHP with the way things are right now.
At this point in time, improvement comes from "anything faster than node". Hell, you might even manage to get a performance benefit out of PHP with the way things are right now.
no, much worse. they might actually win by overspending on marketing and feature-bloat, and we’ll be stuck working with slow tools
Yeah, I'm over here going, "oof, I hope they don't do too well by burning VC cash, or they might stifle esbuild and deno and similar efforts, and we'll remain stuck at this embarrassingly-low local maximum even longer"
what else would VC money be for other than a sweet vendor lock-in?
The JavaScript tooling ecosystem is fragmented, bloated and slow. Rome is the best - and currently only - bet to fix this. I’m excited!
How will Rome be faster than the other tools when its also written in Typescript? I see that unification will be an advantage but I dont think it will be faster than others. Especially when native code/wasm based tools are already available. (esbuild/swc/rslint)
The positives I see are: - No fighting with different versions of different tools when upgrading - Simpler configurations
But I dont see any other reasons to convince people to use Rome.
The positives I see are: - No fighting with different versions of different tools when upgrading - Simpler configurations
But I dont see any other reasons to convince people to use Rome.
Why do you think this is the only bet? What about things like Snowpack, Vite, and Esbuild?
Those are all great bundlers/dev servers but they aren’t as ambitious as Rome. Rome aims to be the one tool that handles everything: compiling, bundling, testing, linting and everything else.
You can also do that with Deno:
- Built in testing library
- Lint with `deno lint`
- Bundle with `deno bundle`
- Format with `deno fmt`
And it will be the one tool that handles everything poorly. Linting (eslint) and testing (jest) are solved problems, there's no way I'll migrate to Rome for these. They should focus on bundling which is the current pain point (although my bet is more on esbuild).
bad examples - the better one is Deno.
I'm a senior eng in Typescript at a tech company. I will always advocate against adopting this project. Jamie is a perfect example of the toxic attitudes and activism destroying OSS and tech. Lerna or Babel are fine, but then again, they are purely OSS projects, not companies expressly designed to enrich him and reward his toxic activism.
What kind of activism are you referring to?
He's well known for almost torpedoing Lerna by committing an insane proprietary license where he called ICE and Palantir fascists who aren't allowed to use Lerna, and included into that any companies who ever do work for ICE or Palantir, which included Microsoft. Microsoft in response had to get to work dropping Lerna from all of its repositories, but instead managed to convince a different maintainer to boot Jamie off the Lerna team. While he was doing all of this he had the gall to call Babel and Lerna HIS personal projects. He wrote stuff like (paraphrasing) "I will not allow Palantir to use my projects." Multiple other maintainers of these projects had to point out to him that these were, literally, not his projects. At the time that he did this he wasn't even the maintainer or core contributor to Lerna. Long story short I will never support anything this guy does. It is incredibly irresponsible to put him anywhere near the levers of power of any significant project or to give him power over employees in a company.
Disclaimer: I know the foundation of Rome was largely written by Sebastian. This question still applies to Rome though, but more so to “open source companies” in general.
https://rome.tools/credits/
How many of these people are going to receive an employment opportunity from this company? How many will receive equity?
I suppose the same questions can be asked if any big project, like React, though that had FB’s backing from the get-go.
I understand that OSS needs funding from somewhere, and I am incredibly optimistic about Rome, but I’d think it a bit disheartening to be surprised by this announcement as a contributor.
https://rome.tools/credits/
How many of these people are going to receive an employment opportunity from this company? How many will receive equity?
I suppose the same questions can be asked if any big project, like React, though that had FB’s backing from the get-go.
I understand that OSS needs funding from somewhere, and I am incredibly optimistic about Rome, but I’d think it a bit disheartening to be surprised by this announcement as a contributor.
I've been keeping the core contributor team updated on the funding process since December. We've also been publicly speaking about it in the Rome Discord server too. I posted about securing funding in early April in #general.
Emanuele and Yasser both approached us during this period to offer their interest in joining and have stayed actively involved in development.
It's a good question around how to compensate the shoulders of the giants you're standing on, and I don't think anyone has a good answer for that. I think it's important to note that the credits page is meant to be as exhaustive as possible. I am not aware of many other projects that have something similar, and theirs are likely to be even longer.
In the end the community is getting value because we'll now be able to do more to improve the project than we otherwise would have. Babel most notably has struggled for funding and is even currently undergoing a serious funding shortage. It has been used as one of the poster children for the JS community and it's clear that donation-based funding isn't effective, at least on the order of magnitude required to support a team.
Emanuele and Yasser both approached us during this period to offer their interest in joining and have stayed actively involved in development.
It's a good question around how to compensate the shoulders of the giants you're standing on, and I don't think anyone has a good answer for that. I think it's important to note that the credits page is meant to be as exhaustive as possible. I am not aware of many other projects that have something similar, and theirs are likely to be even longer.
In the end the community is getting value because we'll now be able to do more to improve the project than we otherwise would have. Babel most notably has struggled for funding and is even currently undergoing a serious funding shortage. It has been used as one of the poster children for the JS community and it's clear that donation-based funding isn't effective, at least on the order of magnitude required to support a team.
I appreciate the thoughtful reply. I should’ve added that I’ve seen your commitment to transparency through the whole process, so the info about Discord doesn’t really come as a surprise. Thanks and good luck!
[deleted]
thats not how OSS contributions work. you contribute of your own free will, they don't owe you any equity or employment. of course you'd have a leg up on hiring but they don't owe you a thing.
I know how OSS works. I just think the transition from being a community-oriented project, to one that will create a lot of value for a small group of people, will be interesting to watch.
They certainly deserve any and all success, I just wonder how those decisions will be made.
They certainly deserve any and all success, I just wonder how those decisions will be made.
Where is the company incorporated? In most countries, companies act for profits first. Especially if you raise funding from a few selected ones instead of the wider community.
This statement reads weird too
> We don’t believe in placing artificial constraints on the tool or having functionality behind a paywall. In order to support the open source project, we’ll be building supplemental products and services. This aligns our incentives with the community and our open source users, with a focus on interoperability, performance, and usability.
Supplemental products and services on top of open source projects often require (down the line) the open source project to adapt because it might hurt the bottom line of these supplemental products and services. Since there is no guarantee this won't happen, if the stake is between the company surviving or a feature being open-source vs "supplemental", the people working at the company might have to chose the option against the wishes of their open source users. I don't see how creating a for-profit company is at all in alignment with open source users. Better would have been a Co-op, a non-profit, OpenCollective, or leverage an existing entity like the Linux foundation, that can actually guarantee it for you in contracts and laws.
This statement reads weird too
> We don’t believe in placing artificial constraints on the tool or having functionality behind a paywall. In order to support the open source project, we’ll be building supplemental products and services. This aligns our incentives with the community and our open source users, with a focus on interoperability, performance, and usability.
Supplemental products and services on top of open source projects often require (down the line) the open source project to adapt because it might hurt the bottom line of these supplemental products and services. Since there is no guarantee this won't happen, if the stake is between the company surviving or a feature being open-source vs "supplemental", the people working at the company might have to chose the option against the wishes of their open source users. I don't see how creating a for-profit company is at all in alignment with open source users. Better would have been a Co-op, a non-profit, OpenCollective, or leverage an existing entity like the Linux foundation, that can actually guarantee it for you in contracts and laws.
Sebastian actually tried fundraising, but I think the campaign got stuck at about 36k of the 100k goal. https://rome.tools/funding/
VC money is just on another level, although as you said it comes with its own difficulties.
VC money is just on another level, although as you said it comes with its own difficulties.
This is pretty exciting! I'm glad to see more investment going into the JavaScript developer tooling ecosystem.
Some of the open source companies have had an easier time monetizing than others. Databases, for example, have a somewhat obvious path nowadays of offering a hosted version. NPM and Docker, on the other hand, developed incredibly popular tools but struggled to monetize. So I'm curious to see what Rome will do.
The other interesting question to me is what Rome will focus on. There's a really wide array of things in the JS toolchain and it's tempting to boil the ocean. How much of it can you really boil? Running a nice JS browser stack of course. Supporting TypeScript I presume. How about Node on the backend? An Electron app? All of those in the same codebase?
Some tough decisions here but I'm glad the team working on them is set to grow and attack this problem. Good luck Romans ;-)
Some of the open source companies have had an easier time monetizing than others. Databases, for example, have a somewhat obvious path nowadays of offering a hosted version. NPM and Docker, on the other hand, developed incredibly popular tools but struggled to monetize. So I'm curious to see what Rome will do.
The other interesting question to me is what Rome will focus on. There's a really wide array of things in the JS toolchain and it's tempting to boil the ocean. How much of it can you really boil? Running a nice JS browser stack of course. Supporting TypeScript I presume. How about Node on the backend? An Electron app? All of those in the same codebase?
Some tough decisions here but I'm glad the team working on them is set to grow and attack this problem. Good luck Romans ;-)
I thought Rome was a Facebook internal project. Am I missing something here?
It's also a java framework for parsing RSS and Atom. I bet that there are more ways that lead to Rome :-)
Parent comment was talking about this specific Rome project. And he is indeed right, it was a Facebook project at the earliest stage, but moved out of it when Seb left FB.
This is that facebook project though (not just the same name), see here: https://github.com/rome/tools/blob/main/website/src/blog/pos...
Seems like the author could take it with him when leaving facebook, which is nice.
Seems like the author could take it with him when leaving facebook, which is nice.
I had a quick look at how they are set up and I like what they are doing from the point of view of actually creating an OSS community. I don't actually know much about what they do as I'm not one of their users. Judging this purely from a "does this make sense as an OSS company" point of view.
- License: MIT. Great pragmatic choice. Generally a good fit for not obstructing your users to actually use, copying, modifying, etc. your code. Too many OSS startups play games with this and end up going for something too restrictive. IMHO not having copyright transfers is the key to longevity for any OSS community. It basically progressively removes re-licensing as an option as more contributors would have to agree to such a thing. Most long lived oss projects have long lists of contributors and no history of license changes past an early stage of their development. Also, MIT is very compatible with just about anything in the ecosystem. Given their stated goal of being good OSS citizens, that's a hard requirement.
- Contributing.md: no mention of copyright transfers. Also they have close to twenty contributors. I assume this means the license will stay as it is and there are no plans to change that. Great! This is key to building a successful open source community with people actually contributing as well as using the code. It also ensures the code can survive acquisitions, bankruptcies, mismanagement of the company, etc. Committing to this upfront is important and a big step.
- Community: There are seventeen contributors, most of which are not employees (I assume). And they probably integrate a lot of other libraries/tools.
- Explicit stated goal that affirms the above: "The company exists to support the open source project, not the other way around.".
That does raise a few question marks around valuation and ways to profit from this. I'm curious about their plans for adding value in the form of services on top of this. I assume this means some cloud based services and/or support contracts with consultancy. But then, it's good to remove the nuclear option (relicensing) from the table early on to create clarity for developers and investors that this is just not that sort of company.
It's smart from a business point of view as well because most of what they do will come from outside the company anyway. The nature of the javascript community is people rapidly iterating on tools, libraries, etc. and forking left right and center as needed. So, a lot of value is going to be added through people doing exactly that. You can work with them or against them. With them is the smarter option.
- License: MIT. Great pragmatic choice. Generally a good fit for not obstructing your users to actually use, copying, modifying, etc. your code. Too many OSS startups play games with this and end up going for something too restrictive. IMHO not having copyright transfers is the key to longevity for any OSS community. It basically progressively removes re-licensing as an option as more contributors would have to agree to such a thing. Most long lived oss projects have long lists of contributors and no history of license changes past an early stage of their development. Also, MIT is very compatible with just about anything in the ecosystem. Given their stated goal of being good OSS citizens, that's a hard requirement.
- Contributing.md: no mention of copyright transfers. Also they have close to twenty contributors. I assume this means the license will stay as it is and there are no plans to change that. Great! This is key to building a successful open source community with people actually contributing as well as using the code. It also ensures the code can survive acquisitions, bankruptcies, mismanagement of the company, etc. Committing to this upfront is important and a big step.
- Community: There are seventeen contributors, most of which are not employees (I assume). And they probably integrate a lot of other libraries/tools.
- Explicit stated goal that affirms the above: "The company exists to support the open source project, not the other way around.".
That does raise a few question marks around valuation and ways to profit from this. I'm curious about their plans for adding value in the form of services on top of this. I assume this means some cloud based services and/or support contracts with consultancy. But then, it's good to remove the nuclear option (relicensing) from the table early on to create clarity for developers and investors that this is just not that sort of company.
It's smart from a business point of view as well because most of what they do will come from outside the company anyway. The nature of the javascript community is people rapidly iterating on tools, libraries, etc. and forking left right and center as needed. So, a lot of value is going to be added through people doing exactly that. You can work with them or against them. With them is the smarter option.
> License: MIT.
Virtually all open source projects in the web dev community are MIT licensed, especially when it comes tooling. Choosing any other license would cause a lot of friction and prevent adoption.
Virtually all open source projects in the web dev community are MIT licensed, especially when it comes tooling. Choosing any other license would cause a lot of friction and prevent adoption.
Rome sounds awesome but the branding confused me for a second...
I was trying to find out how this relates to https://roamresearch.com/
I guess phonetically my mind was flipping things around.
I was trying to find out how this relates to https://roamresearch.com/
I guess phonetically my mind was flipping things around.
possibly sensitive question - i recall Sebastian and Kyle had their differences during the ICE issue of 2018 https://www.vice.com/en/article/pawnwv/open-source-devs-reve...
what are Rome's intended policies on OSS licensing and usage by ICE?
what are Rome's intended policies on OSS licensing and usage by ICE?
I think there’s a difference between “objectionable organizations” using what is available as OSS, and them being allowed on the platform that the company intends to develop.
Any news on plugin support (eg: Svelte)?
This was my first thought as well. More and more devs are beginning to discover Svelte as a milestone in the evolution of Javascript. I would be surprised if it wasn’t already on the roadmap.
second vote for Svelte support here - i'd hate for a next-gen tool like Rome to only support React when there are other great frameworks that it could handle
[deleted]
VCs fund startups which has the potential to 100x their returns right? How is that going to work here? How will they monetize a javascript library? Will we have an IPO for a javascript library? Or are they betting on a big tech company to acquire a Javascript library for 100s of millions of dollars? I am confused.